Re: ZFS Howto first cut

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Mon, 2 Mar 2020 at 10:09, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> On Mon, 2 Mar 2020 at 05:45, Michael <macallan%netbsd.org@localhost> wrote:
> >
> > Hello,
> >
> > On Sun, 01 Mar 2020 11:32:46 -0500
> > Greg Troxel <gdt%lexort.com@localhost> 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
>
>
>
> --
> ----



-- 
----