Re: btrfs-convert on 24Gb image corrupts files.

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2024/5/5 10:04, jordan.j@mail.bg 写道:
[...]
> *******
>
> on ext4:
>
> ilefrag -v
> m/root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite
> Filesystem type is: ef53
> File size of
> m/root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite is 49152 (12 blocks of 4096 bytes)
>   ext:     logical_offset:        physical_offset: length:   expected:
> flags:
>     0:        0..       1:    2217003..   2217004:      2:
>     1:        2..      10:    2217019..   2217027:      9:    2217005:
>     2:       11..      11:    2217028..   2217028:      1:
> last,unwritten,eof
> m/root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite: 2 extents found
>
> on btrfs:
>
> filefrag -v
> k/root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite
> Filesystem type is: 9123683e
> File size of
> k/root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite is 49152 (12 blocks of 4096 bytes)
>   ext:     logical_offset:        physical_offset: length:   expected:
> flags:
>     0:        0..       1:    2217003..   2217004:      2:
> shared
>     1:        2..      11:    2217019..   2217028:     10:    2217005:
> last,shared,eof
> k/root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite: 2 extents found
>

This is exactly the problem of unwritten (preallocated) extents.

Considering all corrupted files are from sqlite, it's highly possible
related to that.

> *********
>
> Tried the four patches from:
> https://lore.kernel.org/linux-btrfs/6d2a19ced4551bfcf2a5d841921af7f84c4ea950.1714722726.git.anand.jain@oracle.com/
>
> on the https://github.com/kdave/btrfs-progs.git tree - no change.

Unfortunately this means the fix is not working.

Mind to provide the "filefrag -v" output after conversion using Anand's
fixes?

I'm afraid there is something wrong for the fix.

For the worst case, I can go a simpler solution by just converting
preallocated extents to holes as a hot fix.

To me, there is no chance we can utilize the preallocated space anyway,
since the extent is shared with the ext4 image, thus we have to do COW.
So focusing on creating the same preallocated data extents in conversion
makes no sense.

Thanks,
Qu