Date: Thu, 16 Jun 2011 23:47:48 +0200 From: Adrian Penisoara <ady@freebsd.ady.ro> To: freebsd-fs@freebsd.org Cc: Pawel Jakub Dawidek <pjd@freebsd.org> Subject: ZFS sharenfs mangling NFS options Message-ID: <BANLkTimw9kJbgoRTb6_HsxgMKAeii8t8_g@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, I was nicely surprised to see that the "sharenfs" option for a ZFS dataset does the expected trick and automatically shares on NFS the dataset via /etc/zfs/exports. However, I had some not so pleasant experiences customizing the NFS sharing parameters -- e.g. when the contents of the "sharenfs" property was automatically translated into [/etc/zfs/]exports entries: * whatever hostname contains a "-" (dash) it gets malformed by being split over the dash character * whatever NFS parameter is prefixed with a "-" (dash) and it's not the first in the list it gets transformed into a hostname entry After some hunting into the CDDL sources I have been able to pinpoint the exact (library) code doing the translation as function translate_opts() in src/cddl/compat/opensolaris/misc/fsshare.c : while ((o = strsep(&s, "-, ")) != NULL) { if (o[0] == '\0') continue; for (i = 0; known_opts[i] != NULL; i++) { len = strlen(known_opts[i]); if (strncmp(known_opts[i], o, len) == 0 && (o[len] == '\0' || o[len] == '=')) { strlcat(newopts, "-", sizeof(newopts)); break; } } strlcat(newopts, o, sizeof(newopts)); strlcat(newopts, " ", sizeof(newopts)); } If I'm able to read C correctly, then it looks like the code above fails to take into consideration the case of hostnames containing dashes and the case of options prefixed with dashes (although it is advertised as valid format in the comments). On the other hand, I'm not too convinced that the contents of the sharenfs property should be translated at all (when different from values "on" and "off") -- I can't seem to find a good documentation reference for [Open]Solaris, but it looks like they are expecting share(1M) style options. I would assume then that for FreeBSD it would await exports(5) style options, so then why was this translation step needed anyway ? Take into account that known_opts[] is a statically assigned vector of strings identifying valid exports(5) keywords -- thus it needs to be kept in sync with mountd code, which was already the case recently with new NFSv4 option(s). If any translation should be occurring at all then I would expect a single common syntax for sharenfs among all OSes (e.g. share(1M) style options) and the translation to be done over to the OS'es native exports(5) format. Thank you for your time, Adrian Penisoara <ady (at) freebsd.ady.ro> EnterpriseBSD.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimw9kJbgoRTb6_HsxgMKAeii8t8_g>