Remounting read-write after error is not allowed

Remounting read-write after error is not allowed

[Alexandru Guzu]

Hello,

I am not sure how to better summarize this but I'll give a more
detailed description.

I am using btrfs tools v4.4, I setup up a btrfs partition on an
external USB2 drive and I started to play with it.
The partition was about HALF full when I decided to run duperemove on
it. This took a while but it eventually hung.

the logs around the hung say something like:

    usb 1-1.1: USB disconnect, device number 3
    usb 1-1.5: USB disconnect, device number 5
    ...
    BTRFS error (device sdg2): bdev /dev/sdg2 errs: wr 0, rd 1, flush
0, corrupt 0, gen 0
    ...
    Call Trace:
    [<ffffffffc03d031f>] btrfs_ioctl+0x25bf/0x28b0 [btrfs]
    [<ffffffff814fbf53>] ? tty_insert_flip_string_fixed_flag+0x83/0xe0
    [<ffffffff810c3bd4>] ? __wake_up+0x44/0x50
    [<ffffffff814f0db1>] ? tty_write_unlock+0x31/0x40
    [<ffffffff814fae16>] ? tty_ldisc_deref+0x16/0x20
    [<ffffffff81222caf>] do_vfs_ioctl+0x29f/0x490
    [<ffffffff8120f099>] ? vfs_write+0x149/0x1a0
    [<ffffffff8120df8f>] ? do_sys_open+0x1bf/0x2a0
    [<ffffffff81222f19>] SyS_ioctl+0x79/0x90
    [<ffffffff8183c672>] entry_SYSCALL_64_fastpath+0x16/0x71
    ...
    usb-storage 1-1.5:1.0: USB Mass Storage device detected
    ...
    sd 7:0:0:0: [sdh] Attached SCSI disk
    EXT4-fs (sdh1): recovery complete
    EXT4-fs (sdh1): mounted filesystem with ordered data mode. Opts: (null)
    BTRFS error (device sdg2): bdev /dev/sdh2 errs: wr 0, rd 5, flush
0, corrupt 0, gen 0
    ...
    BTRFS warning (device sdg2): error -5 while searching for
dev_stats item for device /dev/sdh2
    BTRFS warning (device sdg2): Skipping commit of aborted transaction.
    ...
    BTRFS: error (device sdg2) in cleanup_transaction:1746: errno=-5 IO failure
    BTRFS info (device sdg2): forced readonly

More complete logs at:
pastebin.com/LqyWQamy

Basically the device can only be mounted as read-only, but no files
are accessible.

- Doing an `ls` on a folder gives "Input/output error".

- doing a `btrfs check` without --repair gives:

    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 247566471406 bytes used err is 0
    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

So I guess no errors.

I can only mount it as read-only, and when I do a SCRUB it finishes in
0 seconds saying it was ABORTED.

I have no issue accessing the other EXT4 partition or dd-ing the btrfs
partition to /dev/null, so I doubt it is a disk issue.

I have not tried btrfs-zero-log because I do not see those kernel errors.
All I see when I mount it is lots of messages such as:
bdev /dev/sdh2 errs: wr 20, rd 28049, flush 0, corrupt 0, gen 0

I have not tried btrfs check --repair because I do not fully
understand the output of btrfs check.

Now, I have backups of the data, but I was wondering if and how can
BTRFS recover from this type of failure that can be quite common
(pulled plug).

Thanks.
- Alex.

Re: Remounting read-write after error is not allowed

[Chris Murphy]

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

Re: Remounting read-write after error is not allowed

[Alexandru Guzu]

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 <lists@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

Re: Remounting read-write after error is not allowed

[Alexandru Guzu]

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)

Regards,

On Fri, Apr 14, 2017 at 3:51 PM, Alexandru Guzu <alexguzu@gmail.com> wrote:
> 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 <lists@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

Re: Remounting read-write after error is not allowed

[Liu Bo]

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 <lists@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Remounting read-write after error is not allowed

[Alexandru Guzu]

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.liu@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 <lists@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html