New: race condition on mounting local disks with autofs
https://bugzilla.kernel.org/show_bug.cgi?id=53951
Summary: race condition on mounting local disks with autofs
Product: File System
Version: 2.5
Kernel Version: 3.7.7
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No
I am using autofs to mount a local disk to /misc/data6 on request. Problem: It seems that the first access silently fails, if the disk is not yet mounted.
Below is an example. Before running it I had umounted /misc/data6 and restarted autofs.
% find /misc/data6 | wc -l; find /misc/data6 | wc -l 18
find: `/misc/data6/lost+found': Permission denied 358
As you can see, the first "find" sees just a subset of the directory entries. The second "find" stumbles over lost+found (as expected) and finds all entries.
Kernel is 3.7.7. There is no error message in kernel.log, only a line to mention the mount:
EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
/etc/auto.master:
/misc /etc/auto.misc
/etc/auto.misc:
data1 -fstype=auto,noatime :/dev/disk/by-label/data1 data2 -fstype=auto,noatime :/dev/disk/by-label/data2 data3 -fstype=auto,noatime :/dev/disk/by-label/data3 data4 -fstype=auto,noatime :/dev/disk/by-label/data4 data5 -fstype=auto,noatime :/dev/disk/by-label/data5 data6 -fstype=auto,noatime :/dev/disk/by-label/data6 data7 -fstype=auto,noatime :/dev/disk/by-label/data7 data8 -fstype=auto,noatime :/dev/disk/by-label/data8
The problem is reproducible, as it seems. Please mail if I can help to track this down.
Regards
Harri
Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.
[Bug 53951] race condition on mounting local disks with autofs
https://bugzilla.kernel.org/show_bug.cgi?id=53951
--- Comment #1 from Harald Dunkel <[email protected]> --- This problem is still in (using 3.12.8):
% find /misc/data6 | wc -l; find /misc/data6 | wc -l 17
find: `/misc/data6/lost+found': Permission denied 341
Signature · 2 lines
You are receiving this mail because: You are watching the assignee of the bug.
Re: [Bug 53951] race condition on mounting local disks with autofs
Quoted 9 lines · On Wed, Feb 05, 2014 at 05:03:53PM +0000, [email protected]…
https://bugzilla.kernel.org/show_bug.cgi?id=53951
--- Comment #1 from Harald Dunkel <[email protected]> --- This problem is still in (using 3.12.8):
% find /misc/data6 | wc -l; find /misc/data6 | wc -l 17
find: `/misc/data6/lost+found': Permission denied 341
Hi Harald,
There isn't an autofs bugzilla component, and it's unlikely that the autofs folks are reading the ext4 mailing list. Since this bug is almost certainly an autofs problem, using bugzilla might not be the best way to report the bug in a way that get the attention of the right people.
I've cc'ed the autofs folks; hopefully they can help you out.
- Ted
Original bug report, from https://bugzilla.kernel.org/show_bug.cgi?id=53951:
Harald Dunkel 2013-02-16 15:55:40 UTC
I am using autofs to mount a local disk to /misc/data6 on request. Problem: It seems that the first access silently fails, if the disk is not yet mounted.
Below is an example. Before running it I had umounted /misc/data6 and restarted autofs.
% find /misc/data6 | wc -l; find /misc/data6 | wc -l 18
find: `/misc/data6/lost+found': Permission denied 358
As you can see, the first "find" sees just a subset of the directory entries. The second "find" stumbles over lost+found (as expected) and finds all entries.
Kernel is 3.7.7. There is no error message in kernel.log, only a line to mention the mount:
EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
/etc/auto.master:
/misc /etc/auto.misc
/etc/auto.misc:
data1 -fstype=auto,noatime :/dev/disk/by-label/data1 data2 -fstype=auto,noatime :/dev/disk/by-label/data2 data3 -fstype=auto,noatime :/dev/disk/by-label/data3 data4 -fstype=auto,noatime :/dev/disk/by-label/data4 data5 -fstype=auto,noatime :/dev/disk/by-label/data5 data6 -fstype=auto,noatime :/dev/disk/by-label/data6 data7 -fstype=auto,noatime :/dev/disk/by-label/data7 data8 -fstype=auto,noatime :/dev/disk/by-label/data8
The problem is reproducible, as it seems. Please mail if I can help to track this down.
Regards
Harri
Ian Kent
maintainerRe: [Bug 53951] race condition on mounting local disks with autofs
Quoted 7 lines · Theodore Ts'o
Original bug report, from https://bugzilla.kernel.org/show_bug.cgi?id=53951:
Harald Dunkel 2013-02-16 15:55:40 UTC
I am using autofs to mount a local disk to /misc/data6 on request. Problem: It seems that the first access silently fails, if the disk is not yet mounted.
Does it!
Or is it the mix of system calls that are made, some of which won't trigger the mount and others that will. I know from experience that find(1) does a fairly unusual mix of these calls.
Does it still happen if you append a "/" to /misc/data6.
Since there are a number of system calls that won't trigger mounts, which is required to avoid mount storms, there needs to be some way to selectively force mount triggering and appending a "/" to a path is the way it's done (at least it should function that way).
Mind you the mix of calls won't matter if the automount is mounted "nobrowse" since mount point directories that don't yet exist should trigger a mount on any access.
The default installed autofs configuration sets this but if you wiped out the configuration and didn't retain that setting then the automount will be mounted "browse", the internal program default.
What are you using for that setting?
Ian
[Bug 53951] race condition on mounting local disks with autofs
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=53951
--- Comment #2 from Theodore Tso <[email protected]> ---
Quoted 9 lines · On Wed, Feb 05, 2014 at 05:03:53PM +0000, [email protected]…
https://bugzilla.kernel.org/show_bug.cgi?id=53951
--- Comment #1 from Harald Dunkel <[email protected]> --- This problem is still in (using 3.12.8):
% find /misc/data6 | wc -l; find /misc/data6 | wc -l 17
find: `/misc/data6/lost+found': Permission denied 341
Hi Harald,
There isn't an autofs bugzilla component, and it's unlikely that the autofs folks are reading the ext4 mailing list. Since this bug is almost certainly an autofs problem, using bugzilla might not be the best way to report the bug in a way that get the attention of the right people.
I've cc'ed the autofs folks; hopefully they can help you out.
- Ted
Original bug report, from https://bugzilla.kernel.org/show_bug.cgi?id=53951:
Harald Dunkel 2013-02-16 15:55:40 UTC
I am using autofs to mount a local disk to /misc/data6 on request. Problem: It seems that the first access silently fails, if the disk is not yet mounted.
Below is an example. Before running it I had umounted /misc/data6 and restarted autofs.
% find /misc/data6 | wc -l; find /misc/data6 | wc -l 18
find: `/misc/data6/lost+found': Permission denied 358
As you can see, the first "find" sees just a subset of the directory entries. The second "find" stumbles over lost+found (as expected) and finds all entries.
Kernel is 3.7.7. There is no error message in kernel.log, only a line to mention the mount:
EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
/etc/auto.master:
/misc /etc/auto.misc
/etc/auto.misc:
data1 -fstype=auto,noatime :/dev/disk/by-label/data1 data2 -fstype=auto,noatime :/dev/disk/by-label/data2 data3 -fstype=auto,noatime :/dev/disk/by-label/data3 data4 -fstype=auto,noatime :/dev/disk/by-label/data4 data5 -fstype=auto,noatime :/dev/disk/by-label/data5 data6 -fstype=auto,noatime :/dev/disk/by-label/data6 data7 -fstype=auto,noatime :/dev/disk/by-label/data7 data8 -fstype=auto,noatime :/dev/disk/by-label/data8
The problem is reproducible, as it seems. Please mail if I can help to track this down.
Regards
Harri
Signature · 2 lines
You are receiving this mail because: You are watching the assignee of the bug.
[Bug 53951] race condition on mounting local disks with autofs
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=53951
--- Comment #3 from Ian Kent <[email protected]> ---
Quoted 7 lines · Theodore Ts'o
Original bug report, from https://bugzilla.kernel.org/show_bug.cgi?id=53951:
Harald Dunkel 2013-02-16 15:55:40 UTC
I am using autofs to mount a local disk to /misc/data6 on request. Problem: It seems that the first access silently fails, if the disk is not yet mounted.
Does it!
Or is it the mix of system calls that are made, some of which won't trigger the mount and others that will. I know from experience that find(1) does a fairly unusual mix of these calls.
Does it still happen if you append a "/" to /misc/data6.
Since there are a number of system calls that won't trigger mounts, which is required to avoid mount storms, there needs to be some way to selectively force mount triggering and appending a "/" to a path is the way it's done (at least it should function that way).
Mind you the mix of calls won't matter if the automount is mounted "nobrowse" since mount point directories that don't yet exist should trigger a mount on any access.
The default installed autofs configuration sets this but if you wiped out the configuration and didn't retain that setting then the automount will be mounted "browse", the internal program default.
What are you using for that setting?
Ian
Signature · 2 lines
You are receiving this mail because: You are watching the assignee of the bug.
[Bug 53951] race condition on mounting local disks with autofs
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=53951
Harald Dunkel <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID--- Comment #4 from Harald Dunkel <[email protected]> --- Hi folks,
using "/misc/data6/" or a manual mount or BROWSE_MODE=no did the trick, so it seems you are right. I will contact the autofs folks.
Thanx very much
Harri
Signature · 2 lines
You are receiving this mail because: You are watching the assignee of the bug.