Re: BTRFS file clone support for cp

[Joel Becker <Joel.Becker@oracle.com>]

On Thu, Jul 30, 2009 at 12:54:16PM +0200, Andi Kleen wrote:
> > With classic cp, if I copy a 1GB non-sparse file and there's less
> > space than that available, cp fails with ENOSPC.
> > With this new feature, it succeeds even if there are
> > just a few blocks available.
> > 
> > Also, consider (buggy!) code that then depends on being able to modify
> > that file in-place, and that "knows" it doesn't need to check for ENOSPC.
> > Sure, they should always check for write failure, but still.  It is
> > a change.
> 
> Fair point, although I suspect there are cases where ENOSPC
> on non extending write can already happen on specific file systems. e.g. on 
> btrfs it might happen when the tree gets rebalanced? Or perhaps on nilfs2
> when the garbage collector doesn't run in time. Wouldn't surprise 
> me if there weren't more cases already.

	In some sense, using btrfs, nilfs2i, ocfs2 with refcount trees
enabled, or any other CoW-ish filesystem is a tacit approval of the
delayed ENOSPC.  The same can be said of "thin provisioning" LUNs.
However, the other concerns are still valid.  A user invoking vanilla
cp(1) expects two independent storage regions for the data.
	(Oh, and what about future support of de-duping in filesystems?
:-)

Joel

-- 

"Anything that is too stupid to be spoken is sung."  
        - Voltaire

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127