So you think this might be a bug in the Kernel? In fact I wanted to try with a newer kernel, but could no longer reproduce the issue. In addition, I did a scrub on the partition and there were no errors. So wither there was some transient disk issue that affected only that partition, or there is a strange bug in the kernel.
I'll see if I can reproduce the issue again. On Mon, Apr 17, 2017 at 2:15 PM, Liu Bo <bo.li....@oracle.com> wrote: > On Mon, Apr 17, 2017 at 02:00:45PM -0400, Alexandru Guzu wrote: >> Not sure if anyone is looking into that segfault, but I have an update. >> I disconnected the USB drive for a while and today I reconnected it >> and it auto-mounted with no issue. >> >> What is interesting is that the drive letter changed to what is was >> before when it was working. >> Remember that in my first email, the drive encounters an error as >> /dev/sdg2, and it reconnected as /dev/sdh2 >> >> I was getting errors when it was assigned /dev/sdh2, but now it mounts >> just fine when it is assigned /dev/sdg2 >> >> sudo btrfs fi show >> Label: 'USB-data' uuid: 227fbb6c-ae72-4b81-8e65-942a0ddc6ef7 >> Total devices 1 FS bytes used 230.72GiB >> devid 1 size 447.13GiB used 238.04GiB path /dev/sdg2 >> >> >> is BTRFS really so sensitive to drive letter changes? >> The USB driver is automounted as such: >> >> /dev/sdg2 on /media/alex/USB-data1 type btrfs >> (rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/,uhelper=udisks2) >> > > I don't think it's because of the changed drive letter, it was hitting the > BUG_ON in kernel code btrfs_search_forward() and showed that somehow your > btrfs > had failed to read the metadata out of the drive (either because the > underlying > drive is not available for reading or because metadata checksum check is > failing). > > That BUG_ON had gotten fixed in a later version, you may want to try the > latest > btrfs. > > > Thanks, > > -liubo > >> > Thanks for the reply. >> > >> > I mounted it ro: >> > $ sudo btrfs fi show /mnt >> > Segmentation fault (core dumped) >> > >> > dmesg says: >> > ... >> > kernel BUG at /build/linux-wXdoVv/linux-4.4.0/fs/btrfs/ctree.c:5205! >> > ... >> > RIP: 0010:[<ffffffffc0371b98>] [<ffffffffc0371b98>] >> > btrfs_search_forward+0x268/0x350 [btrfs] >> > ... >> > Call Trace: >> > [<ffffffffc03cabb2>] search_ioctl+0xf2/0x1c0 [btrfs] >> > [<ffffffff811afc4c>] ? zone_statistics+0x7c/0xa0 >> > [<ffffffffc03cacf2>] btrfs_ioctl_tree_search+0x72/0xc0 [btrfs] >> > [<ffffffffc03ce1b5>] btrfs_ioctl+0x455/0x28b0 [btrfs] >> > [<ffffffff8120274b>] ? mem_cgroup_try_charge+0x6b/0x1e0 >> > [<ffffffff811c1a5d>] ? handle_mm_fault+0xcad/0x1820 >> > [<ffffffff81222caf>] do_vfs_ioctl+0x29f/0x490 >> > [<ffffffff8106b544>] ? __do_page_fault+0x1b4/0x400 >> > [<ffffffff81222f19>] SyS_ioctl+0x79/0x90 >> > [<ffffffff8183c672>] entry_SYSCALL_64_fastpath+0x16/0x71 >> > ... >> > >> > full dmesg output is at: >> > pastebin.com/bhsEJiJN >> > >> > $ sudo btrfs fi df /mnt >> > Data, single: total=236.01GiB, used=230.35GiB >> > System, DUP: total=8.00MiB, used=48.00KiB >> > System, single: total=4.00MiB, used=0.00B >> > Metadata, DUP: total=1.00GiB, used=349.11MiB >> > Metadata, single: total=8.00MiB, used=0.00B >> > GlobalReserve, single: total=128.00MiB, used=0.00B >> > >> > I downloaded and compiled the current btrfs v4.10.1-9-gbd0ab27. >> > >> > sudo ./btrfs check /dev/sdh2 >> > Checking filesystem on /dev/sdh2 >> > UUID: 227fbb6c-ae72-4b81-8e65-942a0ddc6ef7 >> > checking extents >> > checking free space cache >> > checking fs roots >> > checking csums >> > checking root refs >> > found 247628603392 bytes used, no error found >> > total csum bytes: 241513756 >> > total tree bytes: 366084096 >> > total fs tree bytes: 90259456 >> > total extent tree bytes: 10010624 >> > btree space waste bytes: 35406538 >> > file data blocks allocated: 23837459185664 >> > referenced 252963553280 >> > >> > and with lowmem mode (again no errors found): >> > ./btrfs check /dev/sdh2 --mode=lowmem >> > Checking filesystem on /dev/sdh2 >> > UUID: 227fbb6c-ae72-4b81-8e65-942a0ddc6ef7 >> > checking extents >> > checking free space cache >> > checking fs roots >> > checking csums >> > checking root refs >> > found 247738298368 bytes used, no error found >> > total csum bytes: 241513756 >> > total tree bytes: 366084096 >> > total fs tree bytes: 90259456 >> > total extent tree bytes: 10010624 >> > btree space waste bytes: 35406538 >> > file data blocks allocated: 23837459185664 >> > referenced 252963553280 >> > >> > maybe there is some hint in that segmentation fault? >> > Also, I compiled from >> > git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git but I >> > did not get version 4.10.1 instead of 4.10.2 >> > >> > Regards, >> > >> > On Fri, Apr 14, 2017 at 1:17 PM, Chris Murphy <li...@colorremedies.com> >> > wrote: >> >> Can you ro mount it and: >> >> >> >> btrfs fi show /mnt >> >> btrfs fi df /mnt >> >> >> >> And then next update the btrfs-progs to something newer like 4.9.2 or >> >> 4.10.2 and then do another 'btrfs check' without repair. And then >> >> separately do it again with --mode=lowmem and post both sets of >> >> results? >> >> >> >> >> >> Chris Murphy >> -- >> 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 -- 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
