On Mon, Dec 29, 2014 at 01:00:47AM +0500, Roman Mamedov wrote:
> > Will btrfs scrub, even if it takes about 24H to run for me, tell me
> > which FS is affected and if so do I run btrfs repair?
>
> I had this: http://www.spinics.net/lists/linux-btrfs/msg40586.html
>
> 1) I determined which btrfs of the multiple ones that I have is the culprit,
> by
> unmounting them one by one and seeing if the dmesg spam disappears;
And of course it's the root filesystem on a remote server which I can't
service remotely :-/
> 3) After that, I ran btrfsck (it did found some errors that looked like this,
> repeated dozens of times, with different "root nnnnn" numbers):
For the archives, one should use btrfs check --repair directly, btrfsck is
dead.
> 6) Surprisingly(#2), despite apparently not all of the errors having been
> fixed, the btrfs_assert_delayed_root_empty messages no longer appear in dmesg.
>
> The current versions of files mentioned (xfce4-panel.xml and parts of the
> Chromium profile)
> were of course corrupted, but I already noticed that and restored them from
> an earlier snapshot
> even before starting the fsck (yes I also had backups, but didn't need them
> as snapshotted versions
> were fine).
Thanks for the info. I think for now I'll be forced to leave the broken
FS run as is and will deal with it when I get home.
Dear btrfs-devs: this is one more example of btrfs having a problem with
a non consistent state that ended up on disk.
I got there this way:
- btrfs on top of dmcrypt on top of md raid1 (sorry too many raid bugs
in btrfs, so I went back to mdadm at the time)
- kernel bug in a serial driver was causing a loop, so I was forced to
cycle power remotely
- btrfs got broken as per this mail.
- please please please, all warnings and bugs should still be fixed to
output what device they happened on. Making the admin guess by trying
filesystem one by one isn't really a good way.
Anyway, assuming there isn't a core bug in the btrfs "always consistent
state on disk" code, dmcrypt or mdadm prevented a consistent state from
reaching the disks.
Separately, I wish I could just fix this while the filesystem is online.
btrfs scrub ran totally clean with no errors :(
scrub device /dev/mapper/cryptroot (id 1) done
scrub started at Sun Dec 28 12:07:55 2014 and finished after 512 seconds
total bytes scrubbed: 25.95GiB with 0 errors
Thankfully the filesystem is still running for now, so it could be worse.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
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
