Port autofs to DragonFly

[Tomohiro Kusumi]

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 <kusumi.tomohiro at gmail.com>:
> 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 <kusumi.tomohiro at gmail.com>:
>> 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