* bizare bug in "btrfs subvolume show"
@ 2020-11-14 5:47 Lawrence D'Anna
2020-11-14 7:28 ` Chris Murphy
2020-11-14 21:35 ` Lawrence D'Anna
0 siblings, 2 replies; 9+ messages in thread
From: Lawrence D'Anna @ 2020-11-14 5:47 UTC (permalink / raw)
To: linux-btrfs; +Cc: Meghan Gwyer
Hi btrfs folks.
I’m encountering what looks like a very strange bug in btrfs-progs or possibly btrfs itself.
If i just do subvol show in a terminal, it works
root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs subvol show /data/
/
Name: <FS_TREE>
UUID: 853d0925-fafc-4b69-9efa-b970fb93a419
Parent UUID: -
Received UUID: -
Creation time: 2020-09-28 22:44:37 -0700
Subvolume ID: 5
Generation: 56582
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
but if I redirect standard out, it fails!
root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs subvol show /data/ >/dev/null
ERROR: Subvolume not found: No such file or directory
same result if I redirect to a file, or pipe it to cat
I can see in a debugger that the error causing the message is being returned from here,
in get_subvolume_info_privileged() in subvolume.c
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, &search);
if (ret == -1)
return BTRFS_UTIL_ERROR_SEARCH_FAILED;
items_pos = 0;
buf_off = 0;
if (search.key.nr_items == 0) {
if (need_root_item) {
errno = ENOENT;
return BTRFS_UTIL_ERROR_SUBVOLUME_NOT_FOUND; /* HERE */
} else {
break;
}
}
But I haven’t been able to track down how redirecting the standard out is possibly influencing this.
Has anyone seen this before or have a clue what might be going on?
Thanks for the help.
system info:
root@odin:/home/lawrence_danna/src/btrfs-progs# uname -a
Linux odin 5.4.0-53-generic #59-Ubuntu SMP Wed Oct 21 09:38:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs --version
btrfs-progs v5.4.1
root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs fi show /data/
Label: 'odin-data-2' uuid: aa5c45da-a789-44fe-825d-9b33f81c9db3
Total devices 4 FS bytes used 4.12TiB
devid 1 size 7.28TiB used 2.06TiB path /dev/sdd
devid 2 size 7.28TiB used 2.06TiB path /dev/sdc
devid 3 size 7.28TiB used 2.06TiB path /dev/sdb
devid 4 size 7.28TiB used 2.06TiB path /dev/sda
root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs fi df /data/
Data, RAID10: total=3.84TiB, used=3.83TiB
System, RAID10: total=64.00MiB, used=528.00KiB
Metadata, RAID10: total=292.00GiB, used=291.16GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
root@odin:/home/lawrence_danna/src/btrfs-progs# lsb_release -rd
Description: Ubuntu 20.04.1 LTS
Release: 20.04
root@odin:/home/lawrence_danna/src/btrfs-progs# dpkg -l btrfs-progs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-===============================================
ii btrfs-progs 5.4.1-2 amd64 Checksumming Copy on Write Filesystem utilities
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-14 5:47 bizare bug in "btrfs subvolume show" Lawrence D'Anna
@ 2020-11-14 7:28 ` Chris Murphy
2020-11-14 18:29 ` Lawrence D'Anna
2020-11-14 21:35 ` Lawrence D'Anna
1 sibling, 1 reply; 9+ messages in thread
From: Chris Murphy @ 2020-11-14 7:28 UTC (permalink / raw)
To: Btrfs BTRFS
On Fri, Nov 13, 2020 at 10:58 PM Lawrence D'Anna <larry@elder-gods.org> wrote:
>
> Hi btrfs folks.
>
> I’m encountering what looks like a very strange bug in btrfs-progs or possibly btrfs itself.
>
> If i just do subvol show in a terminal, it works
>
> root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs subvol show /data/
> /
> Name: <FS_TREE>
> UUID: 853d0925-fafc-4b69-9efa-b970fb93a419
> Parent UUID: -
> Received UUID: -
> Creation time: 2020-09-28 22:44:37 -0700
> Subvolume ID: 5
> Generation: 56582
> Gen at creation: 0
> Parent ID: 0
> Top level ID: 0
> Flags: -
> Snapshot(s):
>
>
> but if I redirect standard out, it fails!
>
> root@odin:/home/lawrence_danna/src/btrfs-progs# btrfs subvol show /data/ >/dev/null
> ERROR: Subvolume not found: No such file or directory
>
> same result if I redirect to a file, or pipe it to cat
I can't reproduce the error with kernel 5.9.8 and btrfs-progs 5.8.
--
Chris Murphy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-14 7:28 ` Chris Murphy
@ 2020-11-14 18:29 ` Lawrence D'Anna
0 siblings, 0 replies; 9+ messages in thread
From: Lawrence D'Anna @ 2020-11-14 18:29 UTC (permalink / raw)
To: Chris Murphy; +Cc: Btrfs BTRFS
> On Nov 13, 2020, at 11:28 PM, Chris Murphy <lists@colorremedies.com> wrote:
>
> I can't reproduce the error with kernel 5.9.8 and btrfs-progs 5.8.
>
The problem seems to be tied to a particular filesystem. If i try it on another filesystem on the
same computer, it does not reproduce.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-14 5:47 bizare bug in "btrfs subvolume show" Lawrence D'Anna
2020-11-14 7:28 ` Chris Murphy
@ 2020-11-14 21:35 ` Lawrence D'Anna
2020-11-15 9:53 ` Roman Mamedov
1 sibling, 1 reply; 9+ messages in thread
From: Lawrence D'Anna @ 2020-11-14 21:35 UTC (permalink / raw)
To: Btrfs BTRFS; +Cc: Meghan Gwyer
> On Nov 13, 2020, at 9:47 PM, Lawrence D'Anna <larry@elder-gods.org> wrote:
>
>
> But I haven’t been able to track down how redirecting the standard out is possibly influencing this.
I have narrowed it down a little bit further.
cmd_subvol_show uses btrfs_util_subvolume_iterator_next_info to find all the snapshots of the
subvol it’s showing.
while it’s performing this iteration, subvolume_iterator_next_tree_search returns a subvolume id
of 7168, which does not appear in my filesystem according to "btrfs subvol list”
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-14 21:35 ` Lawrence D'Anna
@ 2020-11-15 9:53 ` Roman Mamedov
2020-11-16 2:09 ` Lawrence D'Anna
0 siblings, 1 reply; 9+ messages in thread
From: Roman Mamedov @ 2020-11-15 9:53 UTC (permalink / raw)
To: Lawrence D'Anna; +Cc: Btrfs BTRFS, Meghan Gwyer
On Sat, 14 Nov 2020 13:35:43 -0800
Lawrence D'Anna <larry@elder-gods.org> wrote:
> > On Nov 13, 2020, at 9:47 PM, Lawrence D'Anna <larry@elder-gods.org> wrote:
> >
> >
> > But I haven’t been able to track down how redirecting the standard out is possibly influencing this.
>
> I have narrowed it down a little bit further.
>
> cmd_subvol_show uses btrfs_util_subvolume_iterator_next_info to find all the snapshots of the
> subvol it’s showing.
>
> while it’s performing this iteration, subvolume_iterator_next_tree_search returns a subvolume id
> of 7168, which does not appear in my filesystem according to "btrfs subvol list”
This still sounds very puzzling, as to how output redirection could affect
things. Perhaps you could run "btrfs sub show" with "strace"? Both with and
without the redirect to see exactly what was the call sequence, parameters and
return values, to compare and find where the difference starts.
--
With respect,
Roman
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-15 9:53 ` Roman Mamedov
@ 2020-11-16 2:09 ` Lawrence D'Anna
2020-11-16 20:31 ` Goffredo Baroncelli
0 siblings, 1 reply; 9+ messages in thread
From: Lawrence D'Anna @ 2020-11-16 2:09 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Btrfs BTRFS, Meghan Gwyer
> On Nov 15, 2020, at 1:53 AM, Roman Mamedov <rm@romanrm.net> wrote:
>
> This still sounds very puzzling, as to how output redirection could affect
> things. Perhaps you could run "btrfs sub show" with "strace"? Both with and
> without the redirect to see exactly what was the call sequence, parameters and
> return values, to compare and find where the difference starts.
>
>
The first meaningful difference occurs at this ioctl:
--- /dev/fd/63 2020-11-15 18:06:23.000000000 -0800
+++ /dev/fd/62 2020-11-15 18:06:23.000000000 -0800
@@ -1,84 +1,84 @@
ioctl(3, BTRFS_IOC_TREE_SEARCH, {key={tree_id=BTRFS_ROOT_TREE_OBJECTID,
min_objectid=BTRFS_FS_TREE_OBJECTID, max_objectid=BTRFS_FS_TREE_OBJECTID,
min_offset=7274, max_offset=UINT64_MAX, min_transid=0, max_transid=UINT64_MAX,
min_type=BTRFS_ROOT_REF_KEY, max_type=BTRFS_ROOT_REF_KEY, nr_items=4096}} =>
{key={nr_items=53}, buf=[{transid=56320, objectid=BTRFS_FS_TREE_OBJECTID,
offset=7274, type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7275, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7276,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7277, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7278,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7279, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7280,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7281, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7282,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7283, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7284,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7285, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7286,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7287, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7288,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7289, type=BTRFS_ROOT_REF_KEY, len=43},
-{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7290,
+{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7168,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7291, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7292,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7293, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7295,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7296, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7297,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7298, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7299,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7300, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7309,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7310, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7311,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7312, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7313,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7314, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7315,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7316, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7317,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7318, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7319,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7320, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7322,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7323, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7324,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7325, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7326,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7327, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7328,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7329, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7330,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7331, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7332,
type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7333, type=BTRFS_ROOT_REF_KEY, len=43},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7334,
type=BTRFS_ROOT_REF_KEY, len=45}, {transid=56695,
objectid=BTRFS_FS_TREE_OBJECTID, offset=7335, type=BTRFS_ROOT_REF_KEY, len=45},
{transid=56695, objectid=BTRFS_FS_TREE_OBJECTID, offset=7336,
type=BTRFS_ROOT_REF_KEY, len=45}]}) = 0
A little while later they diverge again when the good side does a BTRFS_IOC_TREE_SEARCH for
7290, and the bad side does it for 7168, which fails.
Full traces are at https://odin.elder-gods.org/btrfs-bug/a and https://odin.elder-gods.org/btrfs-bug/b
If you’d like to see them
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-16 2:09 ` Lawrence D'Anna
@ 2020-11-16 20:31 ` Goffredo Baroncelli
2020-11-16 20:51 ` Lawrence D'Anna
0 siblings, 1 reply; 9+ messages in thread
From: Goffredo Baroncelli @ 2020-11-16 20:31 UTC (permalink / raw)
To: Lawrence D'Anna, Roman Mamedov; +Cc: Btrfs BTRFS, Meghan Gwyer
On 11/16/20 3:09 AM, Lawrence D'Anna wrote:
>
>
>> On Nov 15, 2020, at 1:53 AM, Roman Mamedov <rm@romanrm.net> wrote:
>>
>> This still sounds very puzzling, as to how output redirection could affect
>> things. Perhaps you could run "btrfs sub show" with "strace"? Both with and
>> without the redirect to see exactly what was the call sequence, parameters and
>> return values, to compare and find where the difference starts.
>>
>>
>
> The first meaningful difference occurs at this ioctl:
>
> --- /dev/fd/63 2020-11-15 18:06:23.000000000 -0800
> +++ /dev/fd/62 2020-11-15 18:06:23.000000000 -0800
> @@ -1,84 +1,84 @@
> ioctl(3, BTRFS_IOC_TREE_SEARCH, {key={tree_id=BTRFS_ROOT_TREE_OBJECTID,
> min_objectid=BTRFS_FS_TREE_OBJECTID, max_objectid=BTRFS_FS_TREE_OBJECTID,
> min_offset=7274, max_offset=UINT64_MAX, min_transid=0, max_transid=UINT64_MAX,
> min_type=BTRFS_ROOT_REF_KEY, max_type=BTRFS_ROOT_REF_KEY, nr_items=4096}} =>
> {key={nr_items=53}, buf=[{transid=56320, objectid=BTRFS_FS_TREE_OBJECTID,
> offset=7274, type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
> objectid=BTRFS_FS_TREE_OBJECTID, offset=7275, type=BTRFS_ROOT_REF_KEY, len=43},
> {transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7276,
> type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
> objectid=BTRFS_FS_TREE_OBJECTID, offset=7277, type=BTRFS_ROOT_REF_KEY, len=43},
[...]
> -{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7290,
> +{transid=56570, objectid=BTRFS_FS_TREE_OBJECTID, offset=7168,
> type=BTRFS_ROOT_REF_KEY, len=43}, {transid=56570,
> objectid=BTRFS_FS_TREE_OBJECTID, offset=7291, type=BTRFS_ROOT_REF_KEY, len=43},
[...]
>
> A little while later they diverge again when the good side does a BTRFS_IOC_TREE_SEARCH for
> 7290, and the bad side does it for 7168, which fails.
>
> Full traces are at https://odin.elder-gods.org/btrfs-bug/a and https://odin.elder-gods.org/btrfs-bug/b
> If you’d like to see them
>
Definitely it is a strange behavior. The value 7168 should be the wrong one because it is out of order.
Are you sure that this behavior depends *only* by the redirect ?
If you ran "btrfs subvol show /data/" several time, you always get the same (good) value ?
And if you do it with a redirect, you always got the wrong one ?
You have a raid10 profile, so an explanation is that sometime you read from the good drive (where there is the value 7290) and sometime from the bad one (where there is the value 7168).
However this should be impossible because
1) the metadata is protected by a corruption by the checksum (may be the checksum is different in each mirror ?)
2) and it should be not strictly related to the redirection. The mirror from which the kernel reads is decided on the value 'pid % 2'.
BR
>
>
>
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-16 20:31 ` Goffredo Baroncelli
@ 2020-11-16 20:51 ` Lawrence D'Anna
2020-11-18 1:17 ` Lawrence D'Anna
0 siblings, 1 reply; 9+ messages in thread
From: Lawrence D'Anna @ 2020-11-16 20:51 UTC (permalink / raw)
To: kreijack; +Cc: Roman Mamedov, Btrfs BTRFS, Meghan Gwyer
> On Nov 16, 2020, at 12:31 PM, Goffredo Baroncelli <kreijack@libero.it> wrote:
>
> Definitely it is a strange behavior. The value 7168 should be the wrong one because it is out of order.
> Are you sure that this behavior depends *only* by the redirect ?
> If you ran "btrfs subvol show /data/" several time, you always get the same (good) value ?
> And if you do it with a redirect, you always got the wrong one ?
yup, it’s very reliable. Every time I do a "subvol show” without redirect, it works. Every time I redirect it to anything, a file,
pipe, or /dev/null, it fails in that same way. I’ve tried it many times at this point.
> You have a raid10 profile, so an explanation is that sometime you read from the good drive (where there is the value 7290) and sometime from the bad one (where there is the value 7168).
> However this should be impossible because
> 1) the metadata is protected by a corruption by the checksum (may be the checksum is different in each mirror ?)
> 2) and it should be not strictly related to the redirection. The mirror from which the kernel reads is decided on the value 'pid % 2'.
yea, I did a “btrfs scrub” this morning and it found no errors. Absolutely bizarre.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: bizare bug in "btrfs subvolume show"
2020-11-16 20:51 ` Lawrence D'Anna
@ 2020-11-18 1:17 ` Lawrence D'Anna
0 siblings, 0 replies; 9+ messages in thread
From: Lawrence D'Anna @ 2020-11-18 1:17 UTC (permalink / raw)
To: kreijack; +Cc: Roman Mamedov, Btrfs BTRFS, Meghan Gwyer
I tried this ubuntu mainline build, and the problem went away :/
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.9.8/
Linux odin 5.9.8-050908-generic #202011101634 SMP Wed Nov 11 00:51:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-11-18 1:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-11-14 5:47 bizare bug in "btrfs subvolume show" Lawrence D'Anna
2020-11-14 7:28 ` Chris Murphy
2020-11-14 18:29 ` Lawrence D'Anna
2020-11-14 21:35 ` Lawrence D'Anna
2020-11-15 9:53 ` Roman Mamedov
2020-11-16 2:09 ` Lawrence D'Anna
2020-11-16 20:31 ` Goffredo Baroncelli
2020-11-16 20:51 ` Lawrence D'Anna
2020-11-18 1:17 ` Lawrence D'Anna
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox