Currently, if _fuse_atomic_open receives an -ENOSYS error, the
no_open_atomic flag is set, preventing further use of atomic_open.
However, even with the no_open feature enabled, atomic_open can still
provide performance benefits when creating new files due to its
ability to combine FUSE lookup and FUSE create operations into a
single atomic request. Therefore, I think it would be advantageous to
allow these two features to coexist.
Thanks,
Yuan
On Tue, Oct 24, 2023 at 9:36 PM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
>
>
>
> On 10/24/23 12:12, Yuan Yao wrote:
> > Thank you for addressing the symbolic link problems!
> > Additionally, I found an incompatibility with the no_open feature.
> > When the FUSE server has the no_open feature enabled, the atomic_open
> > FUSE request returns a d_entry with an empty file handler and open
> > option FOPEN_KEEP_CACHE (for files) or FOPEN_CACHE_DIR (for
> > directories). With this situation, if we can set fc->no_open = 1 or
> > fc->no_opendir = 1 after receiving the such FUSE reply, as follows,
> > will make the atomic_open compatible with no_open feature:
> > + if (!inode) {
> > + flags &= ~(O_CREAT | O_EXCL | O_TRUNC);
> > + fuse_sync_release(NULL, ff, flags);
> > + fuse_queue_forget(fm->fc, forget, outentry.nodeid, 1);
> > + err = -ENOMEM;
> > + goto out_err;
> > + }
> > +
> > + if(ff->fh == 0) {
> > + if(ff->open_flags & FOPEN_KEEP_CACHE)
> > + fc->no_open = 1;
> > + if(ff->open_flags & FOPEN_CACHE_DIR)
> > + fc->no_opendir = 1;
> > + }
> > +
> > + /* prevent racing/parallel lookup on a negative hashed */
> >
>
> Thanks again for your review!
>
> Hmm, are you sure atomic open needs to handle no-open? fuse_file_open
> sets no-open / no-opendir on -ENOSYS. _fuse_atomic_open has a handler
> for -ENOSYS and falls back to the existing create_open. So why does
> atomic open need a no-open handling?
>
>
> Thanks,
> Bernd
>
>
>
>
