* duplicate automounts with btrfs RAID1
@ 2016-03-02 20:34 Leigh Orf
2016-03-02 21:34 ` Pavol Cupka
2016-03-03 7:11 ` Duncan
0 siblings, 2 replies; 6+ messages in thread
From: Leigh Orf @ 2016-03-02 20:34 UTC (permalink / raw)
To: linux-btrfs
Hello,
Not entirely sure this is a btrfs issue, but here is my problem. I've
had this issue with recent Fedora and CentOS distros.
I created a btrfs RAID 1 pair with two identical USB external drives,
following the instructions found online:
mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1
Then I mount it as /ext1:
% df |grep sdc
/dev/sdc1 9767539112 1280 9765383552 1% /ext1
The problem? Over time, /dev/sdc1 keeps getting mounted under a
different mount point, these accrue a couple per day:
% mount|grep sdc
/dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd1 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd11 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd12 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd13 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd14 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd15 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd16 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd17 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd18 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
/dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd19 type
btrfs (rw,nosuid,nodev,relatime,space_cache)
It's as if the OS keeps "discovering a new disk" and mounting it
under /run/media (where things like external drives, thumb drives etc.
automount).
Here is info about my setup (up to date CentOS 7.2):
% cat /etc/system-release
CentOS Linux release 7.2.1511 (Core)
% uname -a
Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29
18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
% btrfs --version
btrfs-progs v3.19.1
% btrfs fi show
Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1
Total devices 2 FS bytes used 640.00KiB
devid 1 size 4.55TiB used 2.03GiB path /dev/sdc1
devid 2 size 4.55TiB used 2.01GiB path /dev/sdd1
btrfs-progs v3.19.1
% btrfs fi df /ext1
Data, RAID1: total=1.00GiB, used=512.00KiB
Data, single: total=8.00MiB, used=0.00B
System, RAID1: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, RAID1: total=1.00GiB, used=112.00KiB
Metadata, single: total=8.00MiB, used=0.00B
Periodically I manually unmount these duplicates, but they come back.
I'd like a solution that doesn't involve disabling automount all
together.
Thanks for any pointers, and apologies if this issue is unrelated to the
btrfs project.
Leigh
--
Leigh Orf
Associate Scientist
Cooperative Institute for Meteorological Satellite Studies
University of Wisconsin - Madison
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: duplicate automounts with btrfs RAID1
2016-03-02 20:34 duplicate automounts with btrfs RAID1 Leigh Orf
@ 2016-03-02 21:34 ` Pavol Cupka
2016-03-02 21:56 ` Leigh Orf
2016-03-03 7:11 ` Duncan
1 sibling, 1 reply; 6+ messages in thread
From: Pavol Cupka @ 2016-03-02 21:34 UTC (permalink / raw)
Cc: linux-btrfs
is anything in dmesg that would point to diskscontrollers being reset?
or something like that?
pavol
On Wed, Mar 2, 2016 at 9:34 PM, Leigh Orf <leigh.orf@gmail.com> wrote:
> Hello,
>
> Not entirely sure this is a btrfs issue, but here is my problem. I've
> had this issue with recent Fedora and CentOS distros.
>
> I created a btrfs RAID 1 pair with two identical USB external drives,
> following the instructions found online:
>
> mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1
>
> Then I mount it as /ext1:
>
> % df |grep sdc
> /dev/sdc1 9767539112 1280 9765383552 1% /ext1
>
> The problem? Over time, /dev/sdc1 keeps getting mounted under a
> different mount point, these accrue a couple per day:
>
> % mount|grep sdc
> /dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd1 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd11 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd12 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd13 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd14 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd15 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd16 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd17 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd18 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd19 type
> btrfs (rw,nosuid,nodev,relatime,space_cache)
>
> It's as if the OS keeps "discovering a new disk" and mounting it
> under /run/media (where things like external drives, thumb drives etc.
> automount).
>
> Here is info about my setup (up to date CentOS 7.2):
>
> % cat /etc/system-release
> CentOS Linux release 7.2.1511 (Core)
> % uname -a
> Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29
> 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> % btrfs --version
> btrfs-progs v3.19.1
> % btrfs fi show
> Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1
> Total devices 2 FS bytes used 640.00KiB
> devid 1 size 4.55TiB used 2.03GiB path /dev/sdc1
> devid 2 size 4.55TiB used 2.01GiB path /dev/sdd1
>
> btrfs-progs v3.19.1
> % btrfs fi df /ext1
> Data, RAID1: total=1.00GiB, used=512.00KiB
> Data, single: total=8.00MiB, used=0.00B
> System, RAID1: total=8.00MiB, used=16.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, RAID1: total=1.00GiB, used=112.00KiB
> Metadata, single: total=8.00MiB, used=0.00B
>
> Periodically I manually unmount these duplicates, but they come back.
> I'd like a solution that doesn't involve disabling automount all
> together.
>
> Thanks for any pointers, and apologies if this issue is unrelated to the
> btrfs project.
>
> Leigh
>
> --
> Leigh Orf
> Associate Scientist
> Cooperative Institute for Meteorological Satellite Studies
> University of Wisconsin - Madison
>
> --
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: duplicate automounts with btrfs RAID1
2016-03-02 21:34 ` Pavol Cupka
@ 2016-03-02 21:56 ` Leigh Orf
2016-03-02 22:01 ` Pavol Cupka
0 siblings, 1 reply; 6+ messages in thread
From: Leigh Orf @ 2016-03-02 21:56 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 4271 bytes --]
On Wed, Mar 2, 2016 at 3:34 PM, Pavol Cupka <pavol.cupka@gmail.com> wrote:
> is anything in dmesg that would point to diskscontrollers being reset?
>
> or something like that?
>
> pavol
Pavol,
Hmm, yes, there are some weird things going on. I am attaching what I
see as the relevant bits from /var/log/messages (command: egrep
'(sd[cd]|mount)' /var/log/messages)
Note, /dev/sdc is disk 1 and /dev/sdd is disk 2 (the two btrfs RAID1 members).
Leigh
>
> On Wed, Mar 2, 2016 at 9:34 PM, Leigh Orf <leigh.orf@gmail.com> wrote:
>> Hello,
>>
>> Not entirely sure this is a btrfs issue, but here is my problem. I've
>> had this issue with recent Fedora and CentOS distros.
>>
>> I created a btrfs RAID 1 pair with two identical USB external drives,
>> following the instructions found online:
>>
>> mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1
>>
>> Then I mount it as /ext1:
>>
>> % df |grep sdc
>> /dev/sdc1 9767539112 1280 9765383552 1% /ext1
>>
>> The problem? Over time, /dev/sdc1 keeps getting mounted under a
>> different mount point, these accrue a couple per day:
>>
>> % mount|grep sdc
>> /dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd1 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd11 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd12 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd13 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd14 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd15 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd16 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd17 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd18 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd19 type
>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>
>> It's as if the OS keeps "discovering a new disk" and mounting it
>> under /run/media (where things like external drives, thumb drives etc.
>> automount).
>>
>> Here is info about my setup (up to date CentOS 7.2):
>>
>> % cat /etc/system-release
>> CentOS Linux release 7.2.1511 (Core)
>> % uname -a
>> Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29
>> 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> % btrfs --version
>> btrfs-progs v3.19.1
>> % btrfs fi show
>> Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1
>> Total devices 2 FS bytes used 640.00KiB
>> devid 1 size 4.55TiB used 2.03GiB path /dev/sdc1
>> devid 2 size 4.55TiB used 2.01GiB path /dev/sdd1
>>
>> btrfs-progs v3.19.1
>> % btrfs fi df /ext1
>> Data, RAID1: total=1.00GiB, used=512.00KiB
>> Data, single: total=8.00MiB, used=0.00B
>> System, RAID1: total=8.00MiB, used=16.00KiB
>> System, single: total=4.00MiB, used=0.00B
>> Metadata, RAID1: total=1.00GiB, used=112.00KiB
>> Metadata, single: total=8.00MiB, used=0.00B
>>
>> Periodically I manually unmount these duplicates, but they come back.
>> I'd like a solution that doesn't involve disabling automount all
>> together.
>>
>> Thanks for any pointers, and apologies if this issue is unrelated to the
>> btrfs project.
>>
>> Leigh
>>
>> --
>> Leigh Orf
>> Associate Scientist
>> Cooperative Institute for Meteorological Satellite Studies
>> University of Wisconsin - Madison
>>
>> --
>> 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
> --
> 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
[-- Attachment #2: btrfs-automount-log.txt --]
[-- Type: text/plain, Size: 7247 bytes --]
% sudo egrep '(sd[cd]|mount)' /var/log/messages
Feb 29 09:02:45 xxx kernel: [577517.900206] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Feb 29 09:02:45 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 on behalf of uid 15321
Feb 29 10:26:29 xxx kernel: [582542.307617] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Feb 29 10:26:29 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11 on behalf of uid 15321
Feb 29 11:23:40 xxx systemd[1]: Stopping Automounts filesystems on demand...
Feb 29 11:23:41 xxx systemd[1]: Starting Automounts filesystems on demand...
Feb 29 11:23:41 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 (device 8:49 is not mounted)
Feb 29 11:23:41 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1: Error removing directory: Device or resource busy
Feb 29 11:23:41 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11 (device 8:49 is not mounted)
Feb 29 11:23:41 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11: Error removing directory: Device or resource busy
Feb 29 11:23:41 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 (device 8:49 is not mounted)
Feb 29 11:23:41 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1: Error removing directory: Device or resource busy
Feb 29 11:23:41 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11 (device 8:49 is not mounted)
Feb 29 11:23:41 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11: Error removing directory: Device or resource busy
Feb 29 11:23:41 xxx systemd[1]: Started Automounts filesystems on demand.
Feb 29 13:53:22 xxx kernel: [594955.225259] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Feb 29 13:53:22 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd12 on behalf of uid 15321
Mar 1 09:37:01 xxx kernel: [665974.023184] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 1 09:37:01 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd13 on behalf of uid 15321
Mar 1 13:07:25 xxx kernel: [678598.031373] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 1 13:07:25 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd14 on behalf of uid 15321
Mar 1 13:48:27 xxx kernel: [681060.534997] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 1 13:48:27 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd15 on behalf of uid 15321
Mar 1 16:30:46 xxx kernel: [690799.577066] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 1 16:30:46 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd16 on behalf of uid 15321
Mar 2 09:06:26 xxx kernel: [750539.534651] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 2 09:06:26 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd17 on behalf of uid 15321
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd11: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd12 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd12: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd13 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd13: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd14 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd14: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd15 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd15: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd16 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd16: Error removing directory: Device or resource busy
Mar 2 10:09:34 xxx udisksd[13185]: Cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd17 (device 8:49 is not mounted)
Mar 2 10:09:34 xxx udisksd[13185]: Error cleaning up mount point /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd17: Error removing directory: Device or resource busy
Mar 2 10:10:54 xxx kernel: [754407.268256] Lustre: Unmounted odyssey-client
Mar 2 12:34:23 xxx kernel: [763016.059052] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 2 12:34:23 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd18 on behalf of uid 15321
Mar 2 13:41:12 xxx kernel: [767025.189266] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 7 /dev/sdd1
Mar 2 13:41:12 xxx udisksd[13185]: Mounted /dev/sdd1 at /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd19 on behalf of uid 15321
Mar 2 13:51:40 xxx kernel: [767653.601537] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 1 transid 8 /dev/sdc1
Mar 2 13:51:40 xxx kernel: [767653.601568] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 8 /dev/sdd1
Mar 2 13:51:46 xxx kernel: [767659.676472] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 1 transid 8 /dev/sdc1
Mar 2 13:51:46 xxx kernel: [767659.676521] btrfs: device fsid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxd1 devid 2 transid 8 /dev/sdd1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: duplicate automounts with btrfs RAID1
2016-03-02 21:56 ` Leigh Orf
@ 2016-03-02 22:01 ` Pavol Cupka
2016-03-03 1:16 ` Anand Jain
0 siblings, 1 reply; 6+ messages in thread
From: Pavol Cupka @ 2016-03-02 22:01 UTC (permalink / raw)
Cc: linux-btrfs
and disk/ata/usb resets?
On Wed, Mar 2, 2016 at 10:56 PM, Leigh Orf <leigh.orf@gmail.com> wrote:
> On Wed, Mar 2, 2016 at 3:34 PM, Pavol Cupka <pavol.cupka@gmail.com> wrote:
>> is anything in dmesg that would point to diskscontrollers being reset?
>>
>> or something like that?
>>
>> pavol
>
> Pavol,
>
> Hmm, yes, there are some weird things going on. I am attaching what I
> see as the relevant bits from /var/log/messages (command: egrep
> '(sd[cd]|mount)' /var/log/messages)
>
> Note, /dev/sdc is disk 1 and /dev/sdd is disk 2 (the two btrfs RAID1 members).
>
> Leigh
>
>>
>> On Wed, Mar 2, 2016 at 9:34 PM, Leigh Orf <leigh.orf@gmail.com> wrote:
>>> Hello,
>>>
>>> Not entirely sure this is a btrfs issue, but here is my problem. I've
>>> had this issue with recent Fedora and CentOS distros.
>>>
>>> I created a btrfs RAID 1 pair with two identical USB external drives,
>>> following the instructions found online:
>>>
>>> mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1
>>>
>>> Then I mount it as /ext1:
>>>
>>> % df |grep sdc
>>> /dev/sdc1 9767539112 1280 9765383552 1% /ext1
>>>
>>> The problem? Over time, /dev/sdc1 keeps getting mounted under a
>>> different mount point, these accrue a couple per day:
>>>
>>> % mount|grep sdc
>>> /dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd1 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd11 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd12 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd13 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd14 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd15 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd16 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd17 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd18 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd19 type
>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>
>>> It's as if the OS keeps "discovering a new disk" and mounting it
>>> under /run/media (where things like external drives, thumb drives etc.
>>> automount).
>>>
>>> Here is info about my setup (up to date CentOS 7.2):
>>>
>>> % cat /etc/system-release
>>> CentOS Linux release 7.2.1511 (Core)
>>> % uname -a
>>> Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29
>>> 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>> % btrfs --version
>>> btrfs-progs v3.19.1
>>> % btrfs fi show
>>> Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1
>>> Total devices 2 FS bytes used 640.00KiB
>>> devid 1 size 4.55TiB used 2.03GiB path /dev/sdc1
>>> devid 2 size 4.55TiB used 2.01GiB path /dev/sdd1
>>>
>>> btrfs-progs v3.19.1
>>> % btrfs fi df /ext1
>>> Data, RAID1: total=1.00GiB, used=512.00KiB
>>> Data, single: total=8.00MiB, used=0.00B
>>> System, RAID1: total=8.00MiB, used=16.00KiB
>>> System, single: total=4.00MiB, used=0.00B
>>> Metadata, RAID1: total=1.00GiB, used=112.00KiB
>>> Metadata, single: total=8.00MiB, used=0.00B
>>>
>>> Periodically I manually unmount these duplicates, but they come back.
>>> I'd like a solution that doesn't involve disabling automount all
>>> together.
>>>
>>> Thanks for any pointers, and apologies if this issue is unrelated to the
>>> btrfs project.
>>>
>>> Leigh
>>>
>>> --
>>> Leigh Orf
>>> Associate Scientist
>>> Cooperative Institute for Meteorological Satellite Studies
>>> University of Wisconsin - Madison
>>>
>>> --
>>> 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
>> --
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: duplicate automounts with btrfs RAID1
2016-03-02 22:01 ` Pavol Cupka
@ 2016-03-03 1:16 ` Anand Jain
0 siblings, 0 replies; 6+ messages in thread
From: Anand Jain @ 2016-03-03 1:16 UTC (permalink / raw)
To: Pavol Cupka; +Cc: linux-btrfs
First,
If /dev/sdc1 is getting disappeared and reappearing you may have this
problem, securing the connection for /dev/sdc1 will help.
But, Should automount be more intelligent to identify FSID thats
already mounted ? In btrfs RAIDs, Both /dev/sdc1 /dev/sdd1 contains
same FSID. With btrfs its not guaranteed that there is one unique FSID
per device.
So automount should, depend on the FSID to check if its already mounted
I am not sure if its doing it, but apparently it does not appears to
be doing it.
Further, I think there is small little bug in the btrfs that, when
one of the device disappears the /proc/self/mounts should should
probably show surviving device. To implement this we need device
state being managed dynamically. Which my hot-spare and auto-replace
patch introduced.
Thanks, Anand
On 03/03/2016 06:01 AM, Pavol Cupka wrote:
> and disk/ata/usb resets?
>
> On Wed, Mar 2, 2016 at 10:56 PM, Leigh Orf <leigh.orf@gmail.com> wrote:
>> On Wed, Mar 2, 2016 at 3:34 PM, Pavol Cupka <pavol.cupka@gmail.com> wrote:
>>> is anything in dmesg that would point to diskscontrollers being reset?
>>>
>>> or something like that?
>>>
>>> pavol
>>
>> Pavol,
>>
>> Hmm, yes, there are some weird things going on. I am attaching what I
>> see as the relevant bits from /var/log/messages (command: egrep
>> '(sd[cd]|mount)' /var/log/messages)
>>
>> Note, /dev/sdc is disk 1 and /dev/sdd is disk 2 (the two btrfs RAID1 members).
>>
>> Leigh
>>
>>>
>>> On Wed, Mar 2, 2016 at 9:34 PM, Leigh Orf <leigh.orf@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Not entirely sure this is a btrfs issue, but here is my problem. I've
>>>> had this issue with recent Fedora and CentOS distros.
>>>>
>>>> I created a btrfs RAID 1 pair with two identical USB external drives,
>>>> following the instructions found online:
>>>>
>>>> mkfs.btrfs -m raid1 -d raid1 /dev/sdc1 /dev/sdd1
>>>>
>>>> Then I mount it as /ext1:
>>>>
>>>> % df |grep sdc
>>>> /dev/sdc1 9767539112 1280 9765383552 1% /ext1
>>>>
>>>> The problem? Over time, /dev/sdc1 keeps getting mounted under a
>>>> different mount point, these accrue a couple per day:
>>>>
>>>> % mount|grep sdc
>>>> /dev/sdc1 on /ext1 type btrfs (rw,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd1 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd11 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd12 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd13 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd14 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd15 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd16 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd17 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd18 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>> /dev/sdc1 on /run/media/fred/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx38fd19 type
>>>> btrfs (rw,nosuid,nodev,relatime,space_cache)
>>>>
>>>> It's as if the OS keeps "discovering a new disk" and mounting it
>>>> under /run/media (where things like external drives, thumb drives etc.
>>>> automount).
>>>>
>>>> Here is info about my setup (up to date CentOS 7.2):
>>>>
>>>> % cat /etc/system-release
>>>> CentOS Linux release 7.2.1511 (Core)
>>>> % uname -a
>>>> Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29
>>>> 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>> % btrfs --version
>>>> btrfs-progs v3.19.1
>>>> % btrfs fi show
>>>> Label: none uuid: d9706351-609b-4c6e-9f37-7058bb038fd1
>>>> Total devices 2 FS bytes used 640.00KiB
>>>> devid 1 size 4.55TiB used 2.03GiB path /dev/sdc1
>>>> devid 2 size 4.55TiB used 2.01GiB path /dev/sdd1
>>>>
>>>> btrfs-progs v3.19.1
>>>> % btrfs fi df /ext1
>>>> Data, RAID1: total=1.00GiB, used=512.00KiB
>>>> Data, single: total=8.00MiB, used=0.00B
>>>> System, RAID1: total=8.00MiB, used=16.00KiB
>>>> System, single: total=4.00MiB, used=0.00B
>>>> Metadata, RAID1: total=1.00GiB, used=112.00KiB
>>>> Metadata, single: total=8.00MiB, used=0.00B
>>>>
>>>> Periodically I manually unmount these duplicates, but they come back.
>>>> I'd like a solution that doesn't involve disabling automount all
>>>> together.
>>>>
>>>> Thanks for any pointers, and apologies if this issue is unrelated to the
>>>> btrfs project.
>>>>
>>>> Leigh
>>>>
>>>> --
>>>> Leigh Orf
>>>> Associate Scientist
>>>> Cooperative Institute for Meteorological Satellite Studies
>>>> University of Wisconsin - Madison
>>>>
>>>> --
>>>> 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
>>> --
>>> 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
> --
> 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: duplicate automounts with btrfs RAID1
2016-03-02 20:34 duplicate automounts with btrfs RAID1 Leigh Orf
2016-03-02 21:34 ` Pavol Cupka
@ 2016-03-03 7:11 ` Duncan
1 sibling, 0 replies; 6+ messages in thread
From: Duncan @ 2016-03-03 7:11 UTC (permalink / raw)
To: linux-btrfs
Leigh Orf posted on Wed, 02 Mar 2016 14:34:41 -0600 as excerpted:
> Here is info about my setup (up to date CentOS 7.2):
>
> % cat /etc/system-release
> CentOS Linux release 7.2.1511 (Core)
> % uname -a
> Linux xxx.xxx.xxx.edu 3.10.0-123.20.1.el7.x86_64 #1 SMP
> Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> % btrfs --version
> btrfs-progs v3.19.1
Looks like you're getting some issue specific help already, but FWIW,
here's the somewhat more generic general list recommendations.
First, note that btrfs in kernel 3.10 was still considered experimental,
and came with big warnings about not using it in production, etc, and
being sure to stay current as potentially data eating bugs were pretty
literally being fixed in every release, back then. That experimental
lable wasn't removed until kernel 3.12, IIRC.
So as far as the list is concerned, your kernel is not only extremely
old, it's from when btrfs was still considered experimental, when
following the current kernel and userspace releases was *very* strongly
recommended, as bugfix patches were *NOT* reliably backported at that
point.
Second, realize that this list is mainstream kernel oriented, and that
btrfs, while past experimental for ~2.5 years and nearing 13 kernel
release cycles now, is still considered "stabilizing, not fully stable
and mature", and as such, the strong recommendation is to be sure you
have backups and are willing to use them if you choose to use btrfs,
because it really is /not/ fully stable and mature yet. (But I expect
you have this point covered.)
Third, because btrfs /is/ still stabilizing, the recommendation remains,
while not as insistent on staying /absolutely/ current as it was in the
experimental btrfs era, to pick either the (mainstream stable) LTS kernel
series or the current kernel series, and stay within two release cycles
on either one.
With 4.4 both the latest release and the latest LTS series release, and
4.1 the latest previous LTS series release, the recommendation is thus to
be on 4.3 or 4.4 if you're following current kernels, and 4.1 or 4.4 if
you're following the LTS series kernels. Tho as it happens 3.18, the
previous LTS series before 4.1, was pretty stable as well, so with it
we're starting to reach three LTS series back, and continuing to support
3.18 as well, now. Whether that will continue thru 4.4 as the latest LTS
and beyond, I'm not sure, but for now it seems we are.
But previous to 3.18, on-list, we really aren't supporting so well any
more, because it's simply too old and too much has been fixed and/or
simply changed, since then. That doesn't mean we won't do the best we
can, but simply, our best with that old just doesn't reach the same level
as our best with 3.18 or newer.
Forth, while we do recognize that there are valid reasons to be
conservative and want truly stable, given the btrfs status of
stabilizing, but not yet fully stable and mature, wishing to run the
still not entirely stable btrfs would seem at odds with a use-case
requiring the stability of a three year old kernel in any case. From the
list perspective, at least, people doing that sort of thing, years-old
kernel and software because they want stability, while trying to do btrfs
as well, are choosing a filesystem that is simply not yet at that level
of stability and maturity, and is thus incompatible with their needs and
desire for long term stability. As such, the strong recommendation in
such cases is to reconsider such a choice, with the expected outcome
being that they either don't need such years outdated stability after
all, and can thus use btrfs on a more modern kernel and userspace, or
they really /do/ need that sort of stability, in which case btrfs
probably simply isn't an appropriate choice for them at this point.
So from the list perspective, at least, 3.10 is not only old, it's still
from the experimental btrfs era, and you really ARE strongly encouraged
to upgrade to more recent. And by "more recent", we really mean at least
3.18 LTS series, tho preferably it'd be at least 4.1 LTS, because older
than that is simply too old to be effectively supported to the level we
want our support to be. The alternative of course is to use a filesystem
more appropriate to the stability needs and concerns of those who for
that reason choose to use three years outdated kernels.
But fifth, all that said, there's a flip side as well. The above is
indeed the general list consensus, but the list is focused on the
/mainline/ kernel. We recognize that various distros _have_ chosen to
provide btrfs support on generally older kernels to which they backport
many of the fixes, with the general idea being that they backport the
newer fixes, but hopefully not the newer bugs.
But, it's the _distros_ choosing to provide that support, not the list,
and only those _distros_ are tracking what patches they've backported and
what they haven't. As far as the _list_ is concerned, that's still a
3.10 experimental btrfs kernel, with an unknown number of who knows which
patches backported. We're focused on the mainstream kernel and not the
various distro efforts, and while we try to support the distro backport
hackfests at the same version as the corresponding mainstream kernels
because within our support period they've usually not diverged _that_ far
from mainstream, there's really no practical way for us to properly
support three year old kernel versions from the distros, for the same
reason we aren't supporting three year old kernel versions from
mainstream, *plus* the fact that we don't track what they've backported
and what they haven't.
So while we do recognize that distros do offer btrfs support on such old
kernels, in that case, you really should be taking those distros up on
that offer, and getting that support from them, rather than from the
list, because while we /will/ do our best, as the other replies to this
thread have already demonstrated, often times, "our best", particularly
when you're running a btrfs so old it was still listed as experimental,
is going to literally be, "try upgrading to a newer kernel, something
within the list-recommended kernel range at least, and see if the problem
still exists." For actually _staying_ on that old kernel, at least once
you really hit btrfs issues, in practice, you'll probably need to get
your support from your distro, who has chosen to provide that support on
the old kernels we don't.
Finally, for userspace btrfs-progs, while policy is to try to support
older and newer kernels with older and newer userspace as well, as a
practical matter, while the kernel code is primary when you're _running_
btrfs, when there's problems and you're trying to recover from an
unmountable filesystem situation, it's the userspace code that's primary,
so it's then that having the latest btrfs-progs with all the latest fixes
to recently discovered problems comes in handy. So you don't really want
userspace to get too behind, either.
As a rule of thumb, therefore, assuming people are already following the
kernel recommendations and thus aren't running /too/ old a kernel, 3.18
or 4.1 LTS series at the oldest, and because the userspace btrfs versions
sync with those of kernel space so for instance a 4.1 series userspace
was developed in sync with the 4.1 kernel, keeping userspace updated to
at least kernel series sync is recommended, but newer is even better,
because as I said, it gives you a better chance at fixing problems when
they occur, because it'll have the latest patches to do so.
But you're already running a 3.19.1 btrfs-progs, and as I said, the
oldest still supported kernel and thus the oldest recommended userspace
by this rule of thumb is 3.18 series, you're fine on btrfs-progs.
But you really _do_ need to reconsider whether the still stabilizing and
maturing btrfs is in line with the fact that you're choosing to run three
years outdated kernels and a distro aimed at stability over currency.
It's very likely that one or the other is out of sync with your needs.
And if you find the distro's provision of btrfs support on that old a
kernel sufficient, then you probably should be looking to your distro
/for/ that support, as well, not here, as the level of support we can
provide on such old kernels, particularly when they're old enough that
btrfs was still experimental on them, really is quite limited, and the
chances that we won't be able to do much but tell you to try a (much)
newer kernel on any problems you have is very high.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-03 7:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-02 20:34 duplicate automounts with btrfs RAID1 Leigh Orf
2016-03-02 21:34 ` Pavol Cupka
2016-03-02 21:56 ` Leigh Orf
2016-03-02 22:01 ` Pavol Cupka
2016-03-03 1:16 ` Anand Jain
2016-03-03 7:11 ` Duncan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.