On Tuesday, January 9, 2018 8:59:06 AM CET Paul Eggert wrote:
> Pavel Raiskup wrote:
> > So what about special casing that filesystem, where we can lseek() for
> > holes anyway?
>
> If we can lseek for holes, then why not just do that?
Checking whether lseek() actu
On Monday, January 8, 2018 3:29:17 AM CET Mark H Weaver wrote:
> I propose that we revisit this bug and fix it. We clearly cannot assume that
> st_blocks == 0 implies that the file contains only zeroes.
. only on btrfs, as far as we know, because of some race condition. So
what about special
On Monday, July 4, 2016 1:35:25 PM CEST Andreas Dilger wrote:
> I think in addition to fixing btrfs (because it needs to work with existing
> tar/rsync/etc. tools) it makes sense to *also* fix the heuristics of tar to
> handle this situation more robustly.
What I was rather thinking about is to
There are optimizations in archivers (tar, rsync, ...) that rely on up2date
st_blocks info. For example, in GNU tar there is optimization check [1]
whether the 'st_size' reports more data than the 'st_blocks' can hold --> then
tar considers that file is sparse (and does additional steps).
It
