Chris Murphy posted on Sat, 12 Dec 2015 13:16:41 -0700 as excerpted: > On Sat, Dec 12, 2015 at 3:34 AM, Ivan Sizov <sivan606@xxxxxxxxx> wrote: >> 2015-12-11 21:24 GMT+03:00 Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: >>> I would not repair it if the risk of it getting worse is bad for your >>> data. >>> >>> Note the wiki says this feature is not well tested and is reported to >>> not work reliably. >>> https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3 >>> >>> Qu is working on patches to fix some of these problems, I don't know >>> the status of any of that. I just did a conversion myself the other >>> day with kernel 4.4.0rc3 and btrfs-progs 4.3.1 and that worked without >>> error. But there were also no big files at all (it was just a clean OS >>> installation). I immediately took a snapshot of that, and btrfs >>> send/receive it to a new Btrfs volume, and then discarded the >>> converted one entirely. >>> >>> The trace looks like it's mounting read-only? If it can be mounted >>> read only, get the important data off the volume if it's not already >>> backed up, and then blow it away. I personally wouldn't bother with >>> repairing it. >> >> What is the better way to get data? send/receive works only with RO >> snapshots. Is there another way to preserve subvolumes and CoW >> structure (a lot of files was copied between subvols using "cp >> --reflink=always")? Or just rsync'ing files is all what I can do? > > cp -a or rsync -a is all I can think of. To start to get it back to > normal, you can use duperemove. While that doesn't create subvolumes, > it'll at least find duplicate extents and use reflinks for those. So > it's in effect the same thing you have now, just lacking the subvolume > structure. I can also suggest btrfs restore, on the /unmounted/ btrfs, to get data off it to some other normally mounted filesystem (btrfs or other). Note that it has options for subvolume restore or not, metadata restore or not, restore by path regex... some reasonably advanced stuff. It's designed for use when the filesystem won't mount at all, but it can even be used on a healthy btrfs, as long as it is unmounted. I've not used the restore subvolume functionality at all as my use-case doesn't involve subvolumes, but between that and the path-regex options, it should be possible to restore from subvolumes separately, altho as normal files in normal subdirs, since it's designed to restore to other filesystems as well as to btrfs. And if the damage is mostly in subvolumes, it's very possible you can restore the data from more of them than you could otherwise access without crashing the filesystem and possibly the system, since restore works from userspace on an unmounted filesystem and thus should at least not have as high a risk of taking the entire system down when it hits those errors, as operating on a mounted filesystem could do due to triggering the error in kernelspace. No it won't get you the subvolume structure on the restore-to destination, so it's not /too/ much better than cp -a or rsync -a, but if those end up crashing without restoring what you want, restore just might get you more of that otherwise inaccessible due to crashes, data, including what's on the subvolumes if you want it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
