From: jordan.j@mail.bg
To: linux-btrfs@vger.kernel.org
Subject: btrfs-convert on 24Gb image corrupts files.
Date: Sun, 5 May 2024 02:34:37 +0200 [thread overview]
Message-ID: <d34c7d77a7f00c93bea6a4d6e83c7caf.mailbg@mail.bg> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 8717 bytes --]
cat /dev/sda3 >sda3.img
fsck.ext4 -fyv sda3.img
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
246589 inodes used (15.68%, out of 1572864)
191 non-contiguous files (0.1%)
116 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 235622/51/1
2219268 blocks used (35.27%, out of 6291456)
0 bad blocks
1 large file
220831 regular files
14688 directories
174 character device files
97 block device files
0 fifos
1641 links
10790 symbolic links (10636 fast symbolic links)
0 sockets
------------
248221 files
mkdir k
mount -o ro sda3.img k/
cd k
find -type f -print0 | xargs -0 md5sum >sda3_files.md5
cd ..
umount k
btrfs-convert sda3.img
btrfs-convert from btrfs-progs v6.7.1
Source filesystem:
Type: ext2
Label:
Blocksize: 4096
UUID: b3a78a9f-37e7-4ccb-bedb-1f800a6a5a19
Target filesystem:
Label:
Blocksize: 4096
Nodesize: 16384
UUID: 8e9b57b4-92cd-466f-9c02-c081a768bf40
Checksum: crc32c
Features: extref, skinny-metadata, no-holes, free-space-tree (default)
Data csum: yes
Inline data: yes
Copy xattr: yes
Reported stats:
Total space: 25769803776
Free space: 8862961664 (34.39%)
Inode count: 1572864
Free inodes: 1326275
Block count: 6291456
Create initial btrfs filesystem
Create ext2 image file
Create btrfs metadata
Copy inodes [.] [ 386128/ 246589]
Free space cache cleared
Conversion complete
mount -o ro sda3.img k/
cd k
md5sum -c sda3_files.md5 | grep -v OK
./root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite:
FAILED
./root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/1657114595AmcateirvtiSty.sqlite:
FAILED
./root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/2823318777ntouromlalnodry--naod.sqlite:
FAILED
./root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/2918063365piupsah.sqlite:
FAILED
./root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/1451318868ntouromlalnodry--epcr.sqlite:
FAILED
./root/.mozilla/firefox/s554srh9.default-release/favicons.sqlite: FAILED
./root/.mozilla/firefox/s554srh9.default-release/places.sqlite: FAILED
md5sum: WARNING: 7 computed checksums did NOT match
cd ..
umount k
btrfs-convert -r sda3.img
btrfs-convert from btrfs-progs v6.7.1
Open filesystem for rollback:
Label:
UUID: 8e9b57b4-92cd-466f-9c02-c081a768bf40
Restoring from: ext2_saved/image
Rollback succeeded
mount -o ro sda3.img k/
cd k
md5sum -c sda3_files.md5 | grep -v OK
*******
Few times did the same with exactly the same corruption on exactly the same
7 files.
Then transferred sda3.img to another machine, and did the same with exactly
the same result, to be sure it is not hardware related.
Corrupted files on both machines are exactly the same, with exactly the
same contents - their md5sums match.
Corrupt part of the filles is at the end of all 7 files - piece from
another file each of them - linux kernel source particularly, except the
last - some binary data.
The size of sda3.img file is 24G, 8G used, ext4 , md5sum of sda3.img and
/dev/sda3 matched until the conversion, but not after the rollback.
*******
On the first machine:
Linux livecd 6.6.21-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Sun Apr 28
18:15:06 UTC 2024 x86_64 Intel(R) Xeon(R) CPU X5670 @ 2.93GHz GenuineIntel
GNU/Linux
btrfs-progs v6.7.1 (tried with 6.8.1 - all the same)
btrfs fi show
Label: none uuid: 62c086a7-e96e-414d-9c21-e5d1e310fae1
Total devices 1 FS bytes used 8.81GiB
devid 1 size 24.00GiB used 16.25GiB path /dev/loop1
btrfs fi df k
Data, single: total=15.74GiB, used=8.47GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=512.00MiB, used=352.00MiB
GlobalReserve, single: total=18.88MiB, used=0.00B
second machine:
Linux le 6.8.8-gentoo #2 SMP PREEMPT_DYNAMIC Sat May 4 19:39:02 EEST 2024
x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
btrfs-progs v6.7.1
btrfs fi show
Label: none uuid: ac30b8a1-a671-4743-aa98-b9dd7b0fd9fc
Total devices 1 FS bytes used 9.17GiB
devid 1 size 24.00GiB used 16.44GiB path /dev/loop0
btrfs fi df m
Data, single: total=15.94GiB, used=8.82GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=512.00MiB, used=354.08MiB
GlobalReserve, single: total=19.30MiB, used=0.00B
*******
no errors in dmesgs
*******
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
*********
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.
**********
Attached file 1st is the original file from the ext4 image, 2nd is the
corrupted file(with some linux source code "injected"), from btrfs.
**********
How looks a corrupted file on the boundary between the non-corrupted(1st
part) and corrupted(2nd part) of the file, seen in less:
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@*vdev,
struct virtio_shm_region *region, u8 id);
};
/* If driver didn't advertise the feature, it will never appear. */
void virtio_check_driver_offered_feature(const struct virtio_device *vdev,
unsigned int fbit);
/**
* __virtio_test_bit - helper to test feature bits. For use by transports.
* Devices should normally use virtio_has_feature,
* which includes more checks.
* @vdev: the device
* @fbit: the feature bit
*/
static inline bool __virtio_test_bit(const struct virtio_device *vdev,
unsigned int fbit)
{
/* Did you forget to fix assumptions on max features? */
if (__builtin_constant_p(fbit))
BUILD_BUG_ON(fbit >= 64);
else
BUG_ON(fbit >= 64);
return vdev->features
}
/**
* __virtio_set_bit - helper to set feature bits. For use by transports.
./root/.mozilla/firefox/s554srh9.default-release/storage/permanent/chrome/idb/3561288849sdhlie.sqlite
lines 10-38/162 93%
Regards.
Jordan.
[-- Attachment #1.2: Type: text/html, Size: 16624 bytes --]
[-- Attachment #2: 3561288849sdhlie.sqlite --]
[-- Type: application/octet-stream, Size: 49152 bytes --]
[-- Attachment #3: 3561288849sdhlie.sqlite --]
[-- Type: application/octet-stream, Size: 49152 bytes --]
next reply other threads:[~2024-05-05 0:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-05 0:34 jordan.j [this message]
2024-05-05 0:50 ` btrfs-convert on 24Gb image corrupts files Qu Wenruo
2024-05-05 0:56 ` Anand Jain
2024-05-05 5:54 ` Qu Wenruo
2024-05-06 0:33 ` Anand Jain
-- strict thread matches above, loose matches on Subject: below --
2024-05-05 15:05 Yordan
2024-05-05 22:31 ` Qu Wenruo
2024-05-05 22:30 You can reproduce it yourself now Yordan
2024-05-06 10:53 ` btrfs-convert on 24Gb image corrupts files Yordan
2024-05-06 13:17 ` Anand Jain
2024-05-06 13:35 ` Yordan
2024-05-06 13:43 ` Anand Jain
2024-05-06 14:57 ` Yordan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d34c7d77a7f00c93bea6a4d6e83c7caf.mailbg@mail.bg \
--to=jordan.j@mail.bg \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).