I managed to fix the show stopper issue I mentioned yesterday. I had to add a retry goto around nlookup() code in order to make this work.
This issue occurs when autofs' nresovle VOP triggers an userspace daemon to mount(2) the target fs. I need to examine if the same is possible without making a change to VFS for this special case. ---------- [root@]~# uname -r 4.5-DEVELOPMENT [root@]~# cat /etc/auto_master | grep -v "#" /mnt auto_nfs [root@]~# cat /etc/auto_nfs NFS -intr,nfsv3 192.168.1.103:/NFS [root@]~# ls /mnt [root@]~# kldload autofs [root@]~# automountd [root@]~# automount [root@]~# mount | grep "mnt" map auto_nfs on /mnt (autofs) [root@]~# ls /mnt/NFS/fio/arch; echo $? arch-aarch64.h arch-generic.h arch-mips.h arch-sh.h arch-x86-common.h arch.h arch-alpha.h arch-hppa.h arch-ppc.h arch-sparc.h arch-x86.h arch-arm.h arch-ia64.h arch-s390.h arch-sparc64.h arch-x86_64.h 0 [root@]~# mount | grep "mnt" map auto_nfs on /mnt (autofs) 192.168.1.103:/NFS on /mnt/NFS (nfs, automounted) 2016-05-12 23:01 GMT+09:00 Tomohiro Kusumi <[email protected]>: > I tried automounting NFS via autofs for the first time after > automounting local filesystems have become kinda stable. > As shown in below, it basically works. > > [root@]~# uname -r > 4.5-DEVELOPMENT > [root@]~# cat /etc/auto_master | grep -v "#" > /mnt auto_nfs > [root@]~# cat /etc/auto_nfs > NFS -intr,nfsv3 192.168.1.103:/NFS > [root@]~# ls /mnt > [root@]~# kldload autofs > [root@]~# automountd > [root@]~# automount > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > [root@]~# ls /mnt/NFS > .snap fio > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > 192.168.1.103:/NFS on /mnt/NFS (nfs, automounted) > [root@]~# autounmountd -r 30 -t 30; sleep 30 > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > [root@]~# > > > -------- > The remaining show stopper is that autofs unable to seemlessly resolve > the path when a process directly tries to ls or cd into the target > filesystem before the target is once mounted, though it does mount the > filesystem at the same time. > In the example below, the first attempt to "ls /mnt/NFS/fio/arch" > fails to list the directory entries though it does mount. > This example uses NFS, but this isn't specific to automounting NFS, it > happens with a local filesystem as well. > > [root@]~# ls /mnt > [root@]~# kldload autofs > [root@]~# automountd > [root@]~# automount > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > [root@]~# ls /mnt/NFS/fio/arch; echo $? > /mnt/NFS/fio/arch > 0 > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > 192.168.1.103:/NFS on /mnt/NFS (nfs, automounted) > [root@]~# ls /mnt/NFS/fio/arch; echo $? > arch-aarch64.h arch-generic.h arch-mips.h arch-sh.h > arch-x86-common.h arch.h > arch-alpha.h arch-hppa.h arch-ppc.h arch-sparc.h > arch-x86.h > arch-arm.h arch-ia64.h arch-s390.h arch-sparc64.h > arch-x86_64.h > 0 > [root@]~# > > > This is the same with cd, as cd goes through the same namei path. > > [root@]~# ls /mnt > [root@]~# kldload autofs > [root@]~# automountd > [root@]~# automount > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > [root@]~# cd /mnt/NFS/fio/arch; echo $? > cd: not a directory: /mnt/NFS/fio/arch > 1 > [root@]~# mount | grep "mnt" > map auto_nfs on /mnt (autofs) > 192.168.1.103:/NFS on /mnt/NFS (nfs, automounted) > [root@]~# cd /mnt/NFS/fio/arch; echo $? > 0 > [root@]/mnt/NFS/fio/arch# > > > This behavior makes a user or userspace programs unable to seemlessly > access the target filesystem which is what the concept of autofs is. > If it's a person who access the target (and if one knows this issue), > then it's still operational by doing ls or cd twice, > but if it's a program it just breaks by failing to properly ls > (readdir(3)) or cd (chdir(2)). > > The difficulty of doing this seems to come from how DragonFly's namei is made. > FreeBSD's VFS is more vnode-centric which makes VOPs easier to handle > vnodes when implementing a filesystem like autofs. > I'll spend a few more days or so to do this, but if unable to fix > this, I'll leave it for now. > > > -------- >> 2. automountd unable to mount HAMMER consists of multiple volumes. >> This is because of the way automountd and autofs sh scripts work. >> This should be fixed, but requires userspace rewrite. I probably don't >> fix this initially. > > The issue I mentioned previously about hammer with >1 volumes is > mountable as long as it's not using -media map. > When using -media map, it's fundamentally difficult to detect which > block devices are the ones make up 1 hammer filesystem. > One way to mount it via -media map is to just read the first 2KB of > all block devices and check if those are hammer volumes with the same > fs ID until all volumes are found, but this sounds stupid. > > [root@]~# cat /etc/auto_master | grep -v "#" > /mnt auto_hammer > [root@]~# cat /etc/auto_hammer > hammer -fstype=hammer :/dev/da2:/dev/da3:/dev/da4 > [root@]~# ls /mnt > [root@]~# kldload autofs > [root@]~# automountd > [root@]~# automount > [root@]~# mount | grep "mnt" > map auto_hammer on /mnt (autofs) > [root@]~# ls /mnt/hammer > fio > [root@]~# mount | grep "mnt" > map auto_hammer on /mnt (autofs) > AUTO on /mnt/hammer (hammer, automounted, noatime, local) > [root@]~# hammer volume-list /mnt/hammer > /dev/da2 > /dev/da3 > /dev/da4 > [root@]~# > > > -------- > Things that I need to bring in from FreeBSD other than autofs itself > (filesystem, userspace daemon, userspace scripts, and fstyp command) > are as follows. > The last one is actually not necessary nor is it from FreeBSD, but > makes filesystem code without backing storage look less insane. > > Add MNT_AUTOMOUNTED to port autofs from FreeBSD > https://bugs.dragonflybsd.org/issues/2900 > Add kstrndup() > https://bugs.dragonflybsd.org/issues/2901 > Add EVFILT_FS > https://bugs.dragonflybsd.org/issues/2905 > Extend IOCPARM_MAX > https://bugs.dragonflybsd.org/issues/2907 > sbin/mount_nfs: Add -o retrycnt= from FreeBSD > https://bugs.dragonflybsd.org/issues/2913 > Don't implement .vfs_sync for nothing > https://bugs.dragonflybsd.org/issues/2912 > > There are quite a few numbers of newly added or modified files. > > # git diff origin/master | grep "diff --git" | wc -l > 62 > > > 2016-05-08 5:23 GMT+09:00 Tomohiro Kusumi <[email protected]>: >> The code has become a bit more stable. >> I haven't pushed the code to publicly available git repo yet because >> it has way too many debug kprintfs all over in autofs and syscalls >> that need to be cleaned up. >> >> Some of the limitations in terms of features are >> >> 1. fstyp unable to detect ZFS and GEOM (but it does detect HAMMER). >> 2. automountd unable to mount HAMMER consists of multiple volumes. >> 3. automountd ignores /dev/md* >> 4. vfs.autofs.mount_on_stat is not supported. >> >> >> 1. This isn't a real issue. This is because DragonFly doesn't have >> headers that define magic numbers for ZFS and GEOM, and I don't want >> to spend extra time bringing them in since DragonFly can't use or >> mount them anyway. Also ZFS headers are probably in CDDL. >> >> 2. This is because of the way automountd and autofs sh scripts work. >> This should be fixed, but requires userspace rewrite. I probably don't >> fix this initially. >> >> 3. I had to ignore /dev/md* because of the stupid behavior of /dev/md* open. >> https://bugs.dragonflybsd.org/issues/2909 >> >> 4. This is disabled by default on FreeBSD so it's usually unused. >> DragonFly has this sysctl too, but does nothing regardless of its >> value. Autofs recursivelly calls some of the VOPs from a vnode of >> autofs to a vnode of another filesystem, which is probably something >> that most filesystems never do. I couldn't find a way to make this >> work without causing deadlock in namecache paths for >> vfs.autofs.mount_on_stat case. >> >> >> Other than autofs code, I need to bring in these from FreeBSD. >> https://bugs.dragonflybsd.org/issues/2905 >> https://bugs.dragonflybsd.org/issues/2907 >> >> Most of the issues that I've had so far are something to do with >> interaction between automountd (userspace daemon) and a process that >> has accessed autofs directory. The basic mechanism of autofs is that >> these two waking up each other after each has finished its job. If >> these two fail to interact properly, it ends up panicing or >> timeout/retry storm. >> >> >> [root@]~# uname -r >> 4.5-DEVELOPMENT >> [root@]~# newfs_hammer -L TEST /dev/da1 > /dev/null >> [root@]~# /etc/autofs/special_media >> TEST >> Fedora-S-23-x86_64 >> [root@]~# kldload autofs >> [root@]~# automount >> [root@]~# df /mnt >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> map -media 0 0 0 100% /mnt >> [root@]~# automountd -vvvvvvvvvvvv >> [root@]~# ls /mnt >> Fedora-S-23-x86_64 TEST >> [root@]~# cd /mnt/TEST >> [root@]/mnt/TEST# ls >> [root@]/mnt/TEST# cd ../Fedora-S-23-x86_64 >> [root@]/mnt/Fedora-S-23-x86_64# ls >> .discinfo .treeinfo EFI Packages TRANS.TBL images isolinux >> repodata >> [root@]/mnt/Fedora-S-23-x86_64# mount | grep "/mnt" >> map -media on /mnt (autofs) >> TEST on /mnt/TEST (hammer, nosuid, automounted, noatime, local) >> /dev/da8 on /mnt/Fedora-S-23-x86_64 (cd9660, read-only, nosuid, >> automounted, local) >> [root@]~# autounmountd -r 30 -t 30 -vvvvvvvvvvv; sleep 30 >> [root@]~# mount | grep "/mnt" >> map -media on /mnt (autofs) >> [root@]~# ls /mnt >> Fedora-S-23-x86_64 TEST >> [root@]~# mount | grep "/mnt" >> map -media on /mnt (autofs) >> [root@]~# ls /mnt/Fedora-S-23-x86_64 >> .discinfo .treeinfo EFI Packages TRANS.TBL images isolinux >> repodata >> [root@]~# mount | grep "/mnt" >> map -media on /mnt (autofs) >> /dev/da8 on /mnt/Fedora-S-23-x86_64 (cd9660, read-only, nosuid, >> automounted, local) >> [root@]~# automount -u >> [root@]~# mount | grep "/mnt" >> map -media on /mnt (autofs) >> >> >> >> 2016-05-04 18:48 GMT+09:00 Tomohiro Kusumi <[email protected]>: >>> I've been working on porting autofs from FreeBSD for the last 3-4 weeks. >>> It finally started to work in the last few days though it's still *very* >>> buggy. >>> >>> I'll be committing this to master sometime in May even if it's not >>> 100% stable after tested by a user who asked me to port this, as I >>> don't want to spend too much time on this. >>> I don't use NFS, but it's easy to imagine issues with NFS just like >>> other filesystems. >>> >>> It actually took more time than I thought it would be, because there >>> were several features supported by FreeBSD but not on DragonFly, >>> which broke portability of userspace and made me bring in those >>> missing stuff from FreeBSD first. >>> >>> (I did this as a practice before I attempt to port HAMMER1 to other BSD >>> kernel. >>> I originally planned to do this with ext2, but changed my mind as >>> someone asked me to port autofs.) >>> >>> ----- >>> [root@]~# uname -r >>> 4.5-DEVELOPMENT >>> [root@]~# kldload autofs >>> [root@]~# grep "/mnt" /etc/auto_master >>> /mnt -media -nosuid >>> [root@]~# ls /mnt >>> [root@]~# automount >>> [root@]~# df /mnt >>> Filesystem 1K-blocks Used Avail Capacity Mounted on >>> map -media 0 0 0 100% /mnt >>> [root@]~# automountd -vvvvvvvv >>> [root@]~# ls /mnt >>> Fedora-S-23-x86_64 >>> [root@]~# cd /mnt/Fedora-S-23-x86_64 >>> [root@]/mnt/Fedora-S-23-x86_64# ls >>> .discinfo .treeinfo EFI Packages TRANS.TBL images isolinux >>> repodata
