On Sat, Jun 9, 2018 at 6:22 AM, Simon Kaiser <[email protected]> wrote:
> Hi all,
>
> I'm having trouble with my btrfs volume on a Samsung SSD 840 pro.  On
> startup I immediately get the error
>
> BTRFS critical (device sda5): corrupt leaf: root=1 block=73263579136
> slot=105, unaligned key offset for csum item, have 1271496708 should be
> aligned to 4096
>
> I used to make regular backups, but slacked off recently.  Fixing the
> filesystem isn't essential in any way, but would save me quite some time
> on config tinkering and weeding out vacation photos.  The second of
> which I don't enjoy at all...
>
> On similar issues faulty RAM seemed to be the most prominent cause.  I
> added a third memory module quite recently which could have caused this,
> but I couldn't run memtest long enough yet to verify.
>
> Here's the trimmed dmesg output (full output at
> https://pastebin.com/7XF9i09K)
>
> [    4.062748] BTRFS critical (device sda5): corrupt leaf: root=1 
> block=73263579136 slot=105, unaligned key offset for csum item, have 
> 1271496708 should be aligned to 4096
> [    4.063806] BTRFS info (device sda5): no csum found for inode 7810710 
> start 0
> [    4.064260] BTRFS warning (device sda5): csum failed root 257 ino 7810710 
> off 109201939968 csum 0x5307fa6f expected csum 0x00000000 mirror 1
> [    4.075834] BTRFS info (device sdb3): use lzo compression, level 0
> [    4.075836] BTRFS info (device sdb3): enabling auto defrag
> [    4.075837] BTRFS info (device sdb3): disk space caching is enabled


What are your mount options?

I suggest removing the suspected bad ram first, and then boot off
alternate media:

btrfs insp dump-s -f <dev>

Try to mount with -o ro, and if that doesn't work try -o
ro,norecovery. Read only mount is more tolerant of problems than rw
mount. If either work, then update your backups while you have a
chance. It's easier to backup from ro mount than it is to use 'btrfs
restore'

If neither -o ro nor -o ro,norecovery work try:

-o usebackuproot

There might be some recent changes data loss using that option. But if
you're using the discard mount option, it probably will fail.

If -o ro does not work, but -o ro,norecovery did work, it's a
candidate for 'btrfs rescue zero-log' again there might be some recent
change data loss if you zero the log.

btrfs check --repair is a last resort so I don't recommend it until
you've got a backup some other way.



-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to