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.bec...@oracle.com Phone: (650) 506-8127 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils