2019-04-04 04:48, Jeff Mahoney:
On 3/31/19 2:44 PM, bt...@avgustinov.eu wrote:
Dear all,
I am a big fan of btrfs, and I am using it since 2013 - in the meantime
on at least four different computers. During this time, I suffered at
least four bad btrfs-failures leading to unmountable, unreadable and
unrecoverable file system. Since in three of the cases I did not manage
to recover even a single file, I am beginning to lose my confidence in
btrfs: for 35-years working with different computers no other file
system was so bad at recovering files!
Considering the importance of btrfs and keeping in mind the number of
similar failures, described in countless forums on the net, I have got
an idea: to donate my last two damaged filesystems for investigation
purposes and thus hopefully contribute to the improvement of btrfs. One
condition: any recovered personal data (mostly pictures and audio files)
should remain undisclosed and be deleted.
Should anybody be interested in this - feel free to contact me
personally (I am not reading the list regularly!), otherwise I am going
to reformat and reuse both systems in two weeks from today.
Some more info:
- The smaller system is 83.6GB, I could either send you an image of
this system on an unneeded hard drive or put it into a dedicated
computer and give you root rights and ssh-access to it (the network lin
is 100Mb down, 50Mb up, so it should be acceptable).
- The used space on the other file system is about 3 TB (4 TB
capacity) and it is distributed among 5 drives, so I can only offer
remote access to this, but I will need time to organize it.
If you need additional information - please ask, but keep in mind that I
have almost no "free time" and the answer could need a day or two.
My team is always interested in images of broken file systems. This is
how --repair evolves. Images with failed --repair operations are still
valuable. That's the first step most users take and why wouldn't they?
If --repair is misbehaving, the end result shouldn't be "I hope you
have backups."
I absolutely agree!
It's not the size of the file system that matters so much. The data on
it doesn't matter from a debugging perspective and, in any event, it's
not written to the image file anyway. I do want a btrfs-image file from
the file system, and if btrfs-image fails to create a usable image,
that's also valuable to know and fix.
The larger filesystem gives me the following output (kernel
5.0.6-050006-generic, btrfs-progs v4.20.2):
# btrfs-image -c 9 /dev/md0 /mnt/b/md.img
incorrect offsets 15003 146075
ERROR: open ctree failed
ERROR: create failed: Success
Last line is funny.
The smaller system let me create an image, but the size of the file,
resulting from "btrfs-image -c 9 /dev/sdXY ...", is surprisingly small -
only 536576B. I guess this is conform with the man-page: "All data will
be zeroed, but metadata and the like is preserved. Mainly used for
debugging purposes."
I shall send you a link to the image (in a private mail) as soon as
possible. Please, respect any private data in case you manage to recover
something.
Kind regards,
Nik.
--
Thanks,
-Jeff
