lkml.org 
[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] ocfs2 changes for 2.6.32


On Thu, 17 Sep 2009, Roland Dreier wrote:
> > > I guess one bit of semantics to figure out is what happens if copyfile()
> > > does the async case but then copyfile_ctrl() returns an error halfway
> > > through... is the state of the dest file just undefined?
>
> > I think that's the one that most filesystems would prefer. Maybe the file
> > is there, it's just that it's only half copied because the filesystem
> > filled up.
>
> Makes sense... and even having the state of having the file half-copied
> is not really well-defined since a filesystem may want to optimize
> things by copying out of order etc.

Yeah.

The thing to remember is that where you'd use a non-atomic 'copyfile()'
system call is as a replacement for just doing the same thing by hand in
user space, so any users of this system call would basically have to
handle the "oops, it failed with ENOSPC in the middle" _anyway_.

So there is no downside to saying "ok, it failed in the middle, you clean
up the result", because the user needs to support that anyway.

The ones that use copyfile for filesystem-specific snapshots and use the
ATOMIC bit to say so obviously don't have this issue. But they aren't
looking for a "faster 'cp'" thing - they're looking for very specific
semantics, and for the ATOMIC case we can provide those kinds of nice
atomic "everything or nothing" semantics.

So the fact that some random server-side copy over CIFS/NFS may need
cleanup by the user after failing at half-point is not actually a
downside. It doesn't affect Joel's kind of fancy use.

Linus


\
 
 \ /
  Last update: 2009-10-18 23:28    [W:0.091 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site