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