All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Leung <sjleung@shaw.ca>
To: linux-btrfs@vger.kernel.org
Subject: off-by-one uncompressed invalid ram_bytes corruptions
Date: Thu, 17 May 2018 23:23:26 -0600	[thread overview]
Message-ID: <b262fdfc-16b2-21d0-4d7b-745ef106b555@shaw.ca> (raw)

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

Hi list,

I've got 3-device raid1 btrfs filesystem that's throwing up some
"corrupt leaf" errors in dmesg.  This is a uniquified list I've
observed lately:

   BTRFS critical (device sda1): corrupt leaf: root=1 
block=4970196795392 slot=307 ino=206231 file_offset=0, invalid ram_bytes 
for uncompressed inline extent, have 3468 expect 3469
   BTRFS critical (device sda1): corrupt leaf: root=1 
block=4970552426496 slot=91 ino=209736 file_offset=0, invalid ram_bytes 
for uncompressed inline extent, have 3496 expect 3497
   BTRFS critical (device sda1): corrupt leaf: root=1 
block=4970712399872 slot=221 ino=205230 file_offset=0, invalid ram_bytes 
for uncompressed inline extent, have 1790 expect 1791
   BTRFS critical (device sda1): corrupt leaf: root=1 
block=4970803920896 slot=368 ino=205732 file_offset=0, invalid ram_bytes 
for uncompressed inline extent, have 2475 expect 2476
   BTRFS critical (device sda1): corrupt leaf: root=1 
block=4970987945984 slot=236 ino=208896 file_offset=0, invalid ram_bytes 
for uncompressed inline extent, have 490 expect 491

All of them seem to be 1 short of the expected value.

Some files do seem to be inaccessible on the filesystem, and btrfs
inspect-internal on any of those inode numbers fails with:

  ERROR: ino paths ioctl: Input/output error

and another message for that inode appears.

'btrfs check' (output attached) seems to notice these corruptions (among 
a few others, some of which seem to be related to a problematic attempt 
to build Android I posted about some months ago).

Other information:

Arch Linux x86-64, kernel 4.16.6, btrfs-progs 4.16.  The filesystem has 
about 25 snapshots at the moment, only a handful of compressed files, 
and nothing fancy like qgroups enabled.

btrfs fi show:

  Label: none  uuid: 9d4db9e3-b9c3-4f6d-8cb4-60ff55e96d82
          Total devices 4 FS bytes used 2.48TiB
          devid    1 size 1.36TiB used 1.13TiB path /dev/sdd1
          devid    2 size 464.73GiB used 230.00GiB path /dev/sdc1
          devid    3 size 1.36TiB used 1.13TiB path /dev/sdb1
          devid    4 size 3.49TiB used 2.49TiB path /dev/sda1

btrfs fi df:

  Data, RAID1: total=2.49TiB, used=2.48TiB
  System, RAID1: total=32.00MiB, used=416.00KiB
  Metadata, RAID1: total=7.00GiB, used=5.29GiB
  GlobalReserve, single: total=512.00MiB, used=0.00B

dmesg output attached as well.

Thanks in advance for any assistance!  I have backups of all the 
important stuff here but it would be nice to fix the corruptions in place.

Steve

[-- Attachment #2: btrfs-check.txt.gz --]
[-- Type: application/gzip, Size: 3360 bytes --]

[-- Attachment #3: dmesg.txt.gz --]
[-- Type: application/gzip, Size: 15624 bytes --]

             reply	other threads:[~2018-05-18  5:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18  5:23 Steve Leung [this message]
2018-05-18  5:49 ` off-by-one uncompressed invalid ram_bytes corruptions Qu Wenruo
2018-05-18  9:42   ` james harvey
2018-05-18  9:56     ` Qu Wenruo
2018-05-19 23:40   ` Steve Leung
2018-05-20  1:02     ` Qu Wenruo
2018-05-20 20:43       ` Steve Leung
2018-05-21  1:07         ` Qu Wenruo
2018-05-26 14:06           ` Steve Leung
2018-05-27  0:57             ` Qu Wenruo
2018-05-28  3:47               ` Steve Leung
2018-05-28  5:11                 ` Qu Wenruo
2018-05-29 14:58                   ` Steve Leung
2018-06-05  5:30                     ` Qu Wenruo
2018-06-06  4:06                       ` Steve Leung
2018-05-29 18:49           ` Hans van Kranenburg
2018-06-05  5:24             ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b262fdfc-16b2-21d0-4d7b-745ef106b555@shaw.ca \
    --to=sjleung@shaw.ca \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.