Re: [RFC] atomic open(..., O_CREAT | ...)

[Trond Myklebust <trond.myklebust@fys.uio.no>]

ty den 09.08.2005 Klokka 08:47 (-0700) skreiv Bryan Henderson:
> >Intents are meant as optimisations, not replacements for existing
> >operations. I'm therefore not really comfortable about having them
> >return errors at all.
> 
> That's true of normal intents, but not what are called intents here.  A 
> normal intent merely expresses an intent, and it can be totally ignored 
> without harm to correctness.  But these "intents" were designed to be 
> responded to by actually performing the foreshadowed operation now - 
> irreversibly.
> 
> Linux needs an atomic lookup/open/create in order to participate in a 
> shared filesystem and provide a POSIX interface (where shared filesystem 
> means a filesystem that is simultaneously accessed by something besides 
> the Linux system in question).  Some operating systems do this simply with 
> a VFS lookup/open/create function.  Linux does it with this intents 
> interface.
> 
> It's hard to merge the concepts in code or in one's mind, which is why 
> we're here now.  A filesystem driver that needs to do atomic 
> lookup/open/create has to bend over backwards to split the operation 
> across the three filesystem driver calls that Linux wants to make.
> 
> I've always preferred just to have a new inode operation for 
> lookup/open/create (mirroring the POSIX open operation, used for all opens 
> if available), but if enough arguments to lookup can do it, that's 
> practically as good.  But that means returning final status from lookup, 
> and not under any circumstance proceeding to create or open when the 
> filesystem driver has said the entire operation is complete.

Have you looked at how we're dealing with this in NFSv4?

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/