[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in

From: Pavel Raiskup
Subject: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)
Date: Sat, 02 Jul 2016 09:18:07 +0200
User-agent: KMail/5.1.3 (Linux/4.5.7-300.fc24.x86_64; KDE/5.22.0; x86_64; ; )

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 looks like btrfs doesn't show correct value in 'st_blocks' until the data
are synced.  ATM, there happens that:

    a) some "tool" creates sparse file
    b) that tool does not sync explicitly and exits ..
    c) tar is called immediately after that to archive the sparse file
    d) tar considers [2] the file is completely sparse (because st_blocks is
       zero) and archives no data.  Here comes data loss.

Because we fixed 'btrfs' to report non-zero 'st_blocks' when the file data is
small and is in-lined (no real data blocks) -- I consider this is too bug in
btrfs worth fixing.


Tested on kernel:

Originally reported here, reproducer available there:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]