From owner-freebsd-fs@FreeBSD.ORG Thu Jun 16 22:11:52 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A07A106566C for ; Thu, 16 Jun 2011 22:11:52 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0BCF38FC0A for ; Thu, 16 Jun 2011 22:11:51 +0000 (UTC) Received: by ewy1 with SMTP id 1so1028907ewy.13 for ; Thu, 16 Jun 2011 15:11:50 -0700 (PDT) Received: by 10.14.127.68 with SMTP id c44mr618087eei.103.1308260892681; Thu, 16 Jun 2011 14:48:12 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.14.27.205 with HTTP; Thu, 16 Jun 2011 14:47:48 -0700 (PDT) From: Adrian Penisoara Date: Thu, 16 Jun 2011 23:47:48 +0200 X-Google-Sender-Auth: shoRHM4eIOD7aZII6oGRM765p78 Message-ID: To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Pawel Jakub Dawidek Subject: ZFS sharenfs mangling NFS options X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 22:11:52 -0000 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 EnterpriseBSD.com