On Mon, 2 Mar 2020 at 10:09, Chavdar Ivanov <ci4...@gmail.com> wrote: > > On Mon, 2 Mar 2020 at 05:45, Michael <macal...@netbsd.org> wrote: > > > > Hello, > > > > On Sun, 01 Mar 2020 11:32:46 -0500 > > Greg Troxel <g...@lexort.com> wrote: > > > > > http://wiki.netbsd.org/zfs/ > > > > > > This is really rough, and I freely admit that I don't understand all the > > > details. Part of the point was to understand things better for myself, > > > and part of it is to provoke others into saying what's wrong with it :-) > > > > > > Please feel free to email me or reply on-list with suggestions, fixes, > > > or things that ought to be explained that aren't. (And feel free to > > > just fix it, for those that can write. I'm at a stopping point.) > > > > Something to be addressed would be nfs sharing. Apparently zfs has its > > own code for that ( see zfs sharenfs ... ) - it's quite unclear ( to me > > at least ) how that interacts with netbsd's own nfs server code. As in, > > can I zfs sharenfs a zfs filesystem and still share a bunch of others > > via /etc/exports? > > I guess I'll do some experiments on that. > > No point. It doesn't change the state of the exported list at all. > > # zfs get sharenfs tank/t1 > NAME PROPERTY VALUE SOURCE > tank/t1 sharenfs no local > # zfs set sharenfs=yes tank/t1 > # zfs get sharenfs tank/t1 > NAME PROPERTY VALUE SOURCE > tank/t1 sharenfs yes local > # showmount -e > Exports list on localhost: > /xcpng 192.168.0.0 > ..... > But of course you can: > ... > # echo /tank/t1 -maproot=0:10 -network 192.168.0/24 >> /etc/exports > # pkill -HUP mountd > # showmount -e > Exports list on localhost: > /tank/t1 192.168.0.0 > /xcpng 192.168.0.0 > .... > .... > > And on another system: > ... > # showmount -E ymir > /tank/t1 > /xcpng > .... > # mount -t nfs ymir:/tank/t1 /mnt/t1 > # ls -l /mnt/t1 > total 1 > drwxr-xr-x 2 root wheel 2 Oct 27 11:30 minidlna > crw-rw-rw- 1 root wheel 2, 2 Feb 12 13:13 null
Oh, dear; I was way too quick. The zfs file system is thus mounted on the remote system, but any operation on it panics the NFS ZFS server: ... (gdb) target kvm netbsd.14.core 0xffffffff80224235 in cpu_reboot () (gdb) bt #0 0xffffffff80224235 in cpu_reboot () #1 0xffffffff809fe1cf in kern_reboot () #2 0xffffffff80a40649 in vpanic () #3 0xffffffff80a4070d in panic () #4 0xffffffff802266ad in trap () #5 0xffffffff8021ed43 in alltraps () #6 0xffffffff81f05091 in zfs_log_create () #7 0xffffffff81f1209a in zfs_netbsd_mkdir () #8 0xffffffff80ab1b89 in VOP_MKDIR () #9 0xffffffff8090e0e1 in nfsrv_mkdir () #10 0xffffffff80922482 in do_nfssvc () #11 0xffffffff80255cf9 in syscall () #12 0xffffffff802096ad in handle_syscall () ... So, for now, it doesn't seem to work at all for me on -current from 29/02/2020. The sharenfs attribute doesn't matter. If I use netbsd.gdb, it doesn't show the symbols from below alltraps - from modules, methinks. As the client had the filesystem mounted still, the panic became cyclic and I had to break single user and disable zfs and remove the filesystem from /etc/exports to be able to continue; the latter would have been enough. > .... > > BTW there is something wrong with showmount on -current, it is very slow: > > # time showmount -E ymir > /tank/t1 > /xcpng > ... > showmount -E ymir 0.00s user 0.00s system 0% cpu 20.098 total > > The same from a FreeBSD host: > time showmount -E ymir > /tank/t1 > /xcpng > ... > 0.000u 0.005s 0:00.04 0.0% 0+0k 3+0io 0pf+0w > > And from an old 8.99.2 host I also get quick: > ... > $ time showmount -e ymir > Exports list on ymir: > /tank/t1 192.168.0.0 > /xcpng 192.168.0.0 > ... > showmount -e ymir 0.03s user 0.03s system 65% cpu 0.089 total > ... > > > > > have fun > > Michael > > > > -- > ---- -- ----
