On Thu, Mar 12, 2015 at 3:58 PM, Chris Murphy <li...@colorremedies.com> wrote:
> Anyway, seeing as this happens on an fsck, that means filesystem > metadata is affected and if e2fsck -f doesn't fix it then, the fs is > toast. I honestly would just immediately remount it ro, and back it up > though before forcing an fsck. An fsck ought to fail gracefully and > not make things worse, but... For what it's worth, in the same scenario, by default Btrfs on an HDD use duplicate metadata on a single drive. So the same read error would get reported, but then there'd be something like this: [48466.824770] BTRFS: checksum error at logical 20971520 on dev /dev/sdb, sector 57344: metadata leaf (level 0) in tree 3 [48466.829900] BTRFS: checksum error at logical 20971520 on dev /dev/sdb, sector 57344: metadata leaf (level 0) in tree 3 [48466.834944] BTRFS: bdev /dev/sdb errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 [48466.853589] BTRFS: fixed up error at logical 20971520 on dev /dev/sdb That's actually a corrupt sector, rather than read error, but the result is the same. Btrfs uses the duplicate copy and fixes the bad one automatically. Life continues. The same thing for data if there's a mirror copy (or raid56 parity, since kernel 3.19). For single copy data, it'll show a path to the affected file. For single copy of fs metadata, well, bad things happen too, chances are the fs will abruptly go forced read only. For the most part Btrfs has been decently graceful lately if it successfully mounts read only. I still keep multiple backups though. Ultimately I trust nothing but many copies. -- Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
