On Fri, Mar 16, 2018 at 7:34 PM, higuita <higuita@xxxxxxx> wrote: > On Tue, 13 Mar 2018 22:24:43 -0600, Chris Murphy > <lists@xxxxxxxxxxxxxxxxx> wrote: >> c. (optional) take a btrfs image before you do the repair because if >> something blows up, at least that will help a dev figure out why btrfs >> check blew up your file system. > > done! i was expecting a image with at least my used space ( ~40GB), > but i got a 1GB file. Is that normal? Depends on 'btrfs fi us' output for metadata, and what compression option used for btrfs-image. The resulting image output by btrfs-image is only metadata. Also, if you want to sanitize file names, it's recommended to use the -ss switch rather than just -s; I guess it's easier for the devs. > After booting with a livecd and running a --repair with > btrfs-progs v4.15.1, it didn't look it have done almost anything to the > errors, running a new check still show mostly the same errors: OK but we need the entire output from the repair attempt... > # btrfs check --force /dev/vdisk/root > WARNING: filesystem mounted, continuing because of --force Maybe Qu or Liu can say otherwise. But in my opinion, btrfs check on mounted file system is unreliable. If it's completely idle, no writes the entire time the check is happening, it might be reliable. But it's expected that btrfs check is an offline check. And btrfs scrub is an online check. OK so going back to your first email, I've noticed a couple things: 1. The problem file system is vdisk/root which is an LVM LV made from two PVs which are two SSDs. By default LVM uses linear concat so it should be possible to figure out which drive is actually involved. It's probably not important to know the mapping right now, but it does make the troubleshooting more complicated. 2. >From dmesg, one of the drives has a GPT problem and it makes me wonder why. The backup GPT is at the end of the drive, so whatever stepped on it probably did not affect anything in sdd2 which is one of the PVs for vdisk/root. So it probably isn't related. [ 8.976491] Alternate GPT is invalid, using primary GPT. [ 8.976506] sdd: sdd1 sdd2 sdd3 sdd4 3. You got this message from btrfs scrub ERROR: scrubbing /dev/mapper/vdisk-root failed for device id 1: ret=-1, errno=5 (Input/output error) Do you have the kernel message that appeared at the exact same time as this? I suggest rebooting from live media and attaching output for the following: btrfs check btrfs check --mode=lowmem mount the Btrfs volume and scrub it, and include all the kernel messages specifically from mount through the end of scrub, including any user space i/o errors. The problem could be anything in the storage stack so we need to see device, device-mapper messages as well as Btrfs. umount and try btrfs check --repair but include all the output The lowmem check is a different implementation and sometimes gives different results. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
