Port autofs to DragonFly
Tomohiro Kusumi
kusumi.tomohiro at gmail.com
Wed May 25 18:17:04 PDT 2016
The code has been tested by a user.
A simple configuration works without issues just like it did on my machines.
If it works the same with more complex configurations the user
normally uses, and if one VFS change I made to nlookup() (which
doesn't affect or used by other filesystems) is acceptable by Matt,
I'd like autofs to go into master for upcoming 4.6.
I'll make the code without bunch of debug kprintfs available hopefully
in a few days.
2016-05-13 23:06 GMT+09:00 Tomohiro Kusumi <kusumi.tomohiro at gmail.com>:
> 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 <kusumi.tomohiro at gmail.com>:
>> 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
More information about the Users
mailing list