* 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.