Am Samstag, 2. Januar 2016, 18:27:16 CET schrieb John Center: > 😂Hi Martin, > > > On Jan 2, 2016, at 6:41 AM, Martin Steigerwald <mar...@lichtvoll.de> > > wrote: > > Am Samstag, 2. Januar 2016, 11:35:51 CET schrieb Martin Steigerwald: > >> Am Freitag, 1. Januar 2016, 20:04:43 CET schrieb John Center: > >>> Hi Duncan, > >>> > >>>> On Fri, Jan 1, 2016 at 12:05 PM, Duncan <1i5t5.dun...@cox.net> wrote: > >>> > >>>> John Center posted on Fri, 01 Jan 2016 11:41:20 -0500 as excerpted: > >>> Where do I go from here? > >> > >> These and the other errors point at an issue with the filesystem > > structure. > > >> As I never had to deal with that, I can only give generic advice: > >> > >> 1) Use latest stable btrfs-progs. > > I'm in the process of creating a live USB to boot with. Since I'm running > mdadm (imsm) I need to purge dmraid & install mdadm to assemble the drives > first. I also need to put the latest version of btrfs-progs on it, too. > (As a side note, things have been getting flaky with my workstation, so I > guess I'm either going to fix this or rebuild it. I have the data files > backed up, it's just a pain to have to recreate the system again.)
I think you could even just run a GRML from USB stick and grab the sources via git clone and compile them there. Shouldn´t take long. I use: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git which has 4.3.1. > >> 2) Umount the filesystem and run > >> > >> btrfs check (maybe with -p) > >> > >> When it finds some errors, proceed with the following steps: > >> > >> Without --repair or some of the other options that modify things it is > > read > > >> only. > >> > >> 3) If you can still access all the files, first thing to do is: rsync or > >> otherwise backup them all to a different location, before attempting > >> anything to repair the issue. > >> > >> 4) If you can´t access some files, you may try to use btrfs restore for > >> restoring them. > >> > >> 5) Then, if you made sure you have an up-to-date backup run > >> > >> btrfs --repair > > > > Before doing that, review: > > > > https://btrfs.wiki.kernel.org/index.php/Btrfsck > > > > to learn about other options. > > Ok, so "btrfs check -p" first to understand how bad the filesystem is > corrupted. > Should I then try to do a recovery mount, or should I run "btrfs check > --repair -p" to try & fix it? I'm not sure what a "mount -o ro,recovery" > does. Well, if "btrfs check -p" confirms that something needs fixing, you make sure you have a working backup *first*, either by rsync or btrfs restore if some files are inaccesible, but from what I remember you are able to access all files? Then I´d say give btrfs check --repair a try. I don´t know much about that mount -o ro,recovery does but from what I gathered so far I thought it is only needed when you *can´t* mount the filesystem anymore. > If I have to reformat & reinstall Ubuntu, are there any recommended > mkfs.btrfs options I should use? Something that might help prevent > problems in the future? 😂 Lol. :) As far as I see mkfs.btrfs from btrfs-tools 4.3.1 already sets extref and skinny-metadata as well as 16 KiB node and leaf size by default, so as I recreated my /daten BTRFS filesystem due to the extent type mismatch errors (see other thread) I used use mkfs.btrfs -L daten to set a label. Thanks, -- Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
