Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

Joerg Schilling writes: > Mark H Weaver wrote: > >> Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written, >> mostly sparse file with size > 8G, using linux-libre-4.14.14. More >> specifically, the "storing sparse files > 8G"

Re: [Bug-tar] Detection of sparse files is broken on btrfs

On Jan 22, 2018, at 10:47 AM, Joerg Schilling wrote: > >> On Jan 22, 2018, at 3:28 AM, Joerg Schilling >> wrote: >>> If you still don't understand this, I recommend you to try to write an in >>> kernel filesystem

Re: [Bug-tar] Detection of sparse files is broken on btrfs

On 01/22/2018 09:47 AM, Joerg Schilling wrote: we are talking about files that do not change while something like TAR is reading them. It's reasonable for a file system to reorganize itself while 'tar' is reading files. Even if a file's contents do not change, its space utilization might

Re: [Bug-tar] Detection of sparse files is broken on btrfs

Paul Eggert wrote: > The implementation that you suggest requires the file system to remember > how much reserved space that it initially allocated to the file, even if > that number changes as a result of file system reorganization. This can > place an undue burden on

Re: [Bug-tar] Detection of sparse files is broken on btrfs

On 01/22/2018 02:28 AM, Joerg Schilling wrote: Since you need to reserve space on the background storage before you can even write to the cached data for a file, you need to make stat() return the related state that includes the reserved space. The implementation that you suggest requires the

Re: [Bug-tar] [PATCH] Remove nonportable check for files containing only zeroes

Mark H Weaver wrote: > Yes, on Btrfs I reliably see (st_blocks == 0) on a recently written, > mostly sparse file with size > 8G, using linux-libre-4.14.14. More > specifically, the "storing sparse files > 8G" test in tar's test suite > reliably fails on my system: Now many

Re: [Bug-tar] Detection of sparse files is broken on btrfs

Andreas Dilger wrote: > So, what you're saying is that filesystem resizing is forbidden by POSIX, > background data compression and data deduplication is forbidden by POSIX, > migration across storage tiers is forbidden by POSIX? All modifications > to the filesystem need to