Port autofs to DragonFly
Tomohiro Kusumi
kusumi.tomohiro at gmail.com
Fri May 13 07:06:32 PDT 2016
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