Re: [PATCH] copy: adjust fiemap handling of sparse files

[Mike Frysinger]

On Wednesday, March 16, 2011 11:26:40 Pádraig Brady wrote:
> On 14/02/11 06:05, Jim Meyering wrote:
> > Pádraig Brady wrote:
> >> For my own reference, I can probably skip performance
> >> tests on (older) btrfs by checking `filefrag` output.
> >> Also in `cp`, if we see an "unwritten extent" we should
> >> probably create a hole rather than an empty allocation
> >> by default.  It's better to decrease file allocation
> >> than increase it.
> > 
> > Makes sense.
> 
> Thinking a bit more about it, I'm not sure I should do the above,
> as one would be more surprised if cp by default introduced holes into
> a copy of a fully allocated file.
> 
> The previously applied patch changes behavior on BTRFS on Fedora 14,
> in that it will convert a file with holes to a fully allocated one
> with zeros. But that is due to an already fixed bug in BTRFS
> where it reports holes as empty extents.
> 
> I'm inclined to leave this as is, because this stuff is tricky enough,
> without introducing work arounds for buggy file systems.
> There is no data loss in this case, just bigger files
> (which one can avoid with cp --sparse=always).
> Also it will not be common to overlap future coreutils releases,
> with older BTRFS implementations.

well, in the bug report i was working with, we were seeing data loss.  i 
wonder if it'd be possible to detect the fs/kernel version and error out when 
versions are found that are known to be broken ?
-mike

signature.asc
Description: This is a digitally signed message part.