On Wed, Jan 14, 2015 at 4:01 PM, <sf...@users.sourceforge.net> wrote: > > Daniel Smedegaard Buus: >> Do you have any idea why aufs won't mount with autofs? I have a direct >> map using tmpfs which works: >> >> /Archive -fstype=3Dtmpfs,size=3D20M none >> >> Doing an ls on /Archive instantly mounts it. However, >> >> /Archive -fstype=3Daufs,ro,xino=3D/run/xino,br=3D/titanic/Downloads/Pro= >> cessed=3Dro:/titanic/Volumes/XD001=3Dro >> none >> >> does not. It just, >> >> # ll /Archive/ >> ls: cannot access /Archive/: No such file or directory > > I've tried it with these. > - both of aufs3.14 and aufs3.x-rcN (for 3.19) > - /etc/auto.master > /tmp/auto /etc/auto.tmp > > - /etc/auto.tmp > rw -fstype=tmpfs,size=1M none > ro -fstype=tmpfs,size=1M none > u -fstype=aufs,br=/tmp/auto/rw:/tmp/auto/ro none > > In both kernel versions, simple ls(1) made /tmp/auto/u mounted > expectedly. But I had to access rw and ro before accessing u. > $ ls /tmp/auto/rw > $ ls /tmp/auto/ro > $ ls /tmp/auto/u > --> succeeded > > When I tried "ls /tmp/auto/u" without acessing rw and ro, it failed. > $ ls /tmp/auto/u > aufs opt_add:790:mount[3390]: lookup failed /tmp/auto/rw (-2) > ls: cannot access /tmp/auto/u: No such file or directory > > Here is my guess. > - the branch pathnames are passed to mount(2), and they are passed to > aufs as it is. > - in kernel-space aufs look-up those pathnames. > --> the msg "lookup failed /tmp/auto/rw" was produced here. > --> which means the look-up from kernel-space doesn't affect > automount. > - no userspace tools (as /sbin/mount.aufs) access them. > > And here is my suggestion. > - rename /sbin/mount.aufs to /sbin/mount.aufs.orig > - write a simple script to run ls for all given paths in "br=", and then > invoke /sbin/mount.aufs.orig. > - name the script /sbin/mount.aufs. >
That works, and your logic sounds right. In the meantime, I just added noauto to my fstab aufs mount and am now mounting it post-boot via rc.local. I don't really "like" to put such stuff in rc.local, but as you suggest, it seems it must be a userspace tool that triggers the automount (makes sense, as autofs seems designed primarily for the desktop user). And on my box, any one of Samba, NFS, Kodi, or a number of other services is likely to want to access the aufs share first, and there's no way of knowing in advance how each service attempts to access that share. Therefore it seems safer to do it with the rc.local "hack" for my use case... Just wish ZFS would mount before fstab is processed. I think I'll ask over there why it isn't. Thank you so much for your help, J. R. :) Daniel > > J. R. Okajima ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet
