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: [email protected]
Phone: (650) 506-8127
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
