Re: interest in post-mortem examination of a BTRFS system and improving the btrfs-code?

[Chris Murphy <lists@colorremedies.com>]

On Thu, Apr 4, 2019 at 9:58 AM Nik. <btrfs@avgustinov.eu> wrote:
>
>
> 2019-04-04 04:48, Jeff Mahoney:
> > On 3/31/19 2:44 PM, btrfs@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.

I've complained about that nonsense for a while and yet it remains. A
successful failure is an ERROR. I still don't know what it means but I
suspect it's an incomplete image.


> 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.

You should use -ss option for this reason.


-- 
Chris Murphy