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
