Re: [GIT PULL] ocfs2 changes for 2.6.32

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 17 Sep 2009, Joel Becker wrote:
>
> 	I have to say, adding 'undefined behavior' things isn't fun in a
> call that is already potentially confusing.  We have a bunch of flags
> and behaviors we're covering.

I don't think it's "undefined". It's just not complete.

>From a user standpoint, there is no difference between such a system call 
and doing the thing as a library routine (which has to be the fallback 
anyway for something like 'cp').

> 	Note that "cleaning up after an error" and "atomic" are not the
> same.  Atomicity implies that not only do you see all or none, but that
> the contents are a point-in-time of the source file.  A non-atomic
> implementation may be affected by writes that happen during the copy
> (like any read-write-loop copy would be).

Sure. There are middle grounds that may not need the cleanup. I was more 
looking at the two extreme ends.

> > Of course, if the filesystem can do the copy entirely atomically (ie by 
> > just incrementing a refcount), then it can give atomicity guarantees, but 
> > then you'd never see the async case either.
> 
> 	Even the atomic copy might take a little time (say, to bump up
> and write out the metadata structures).  Do you want to define that as
> not being async?  I was figuring COPYFILE_ATOMIC and COPYFILE_WAIT to be
> separate flags.

I don't think that's wrong, and yeah, you could decide that you actually 
want to be able to support the "ten outstanding 'copy' commands from user 
space" model too. So yeah, separate COPYFILE_ATOMIC (only succeed if you 
can do it as an atomic op in the filesystem) and COPYFILE_WAIT (only 
return when fully done) bits sounds conceptually fine to me.

Whether it's worth it for a filesystem that effectively only needs a 
couple of writes (that can be buffered too), I dunno. But it's certainly 
not something I'd object to on an interface level.

		Linus