From owner-svn-src-all@FreeBSD.ORG Sun Sep 12 00:41:25 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 466EA106566B; Sun, 12 Sep 2010 00:41:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id ACF0D8FC08; Sun, 12 Sep 2010 00:41:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEALe+i0yDaFvO/2dsb2JhbACDGJ8hrRqRBoEigyd0BIog X-IronPort-AV: E=Sophos;i="4.56,353,1280721600"; d="scan'208";a="93571162" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 11 Sep 2010 20:41:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 9F181B3EA8; Sat, 11 Sep 2010 20:41:22 -0400 (EDT) Date: Sat, 11 Sep 2010 20:41:22 -0400 (EDT) From: Rick Macklem To: Kostik Belousov Message-ID: <1300087421.776986.1284252082593.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100911060111.GT2465@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: svn-src-head@freebsd.org, Rick Macklem , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212439 - head/sys/fs/nfs X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 00:41:25 -0000 > Then, fid_reserved is no more reserved ? Should we rename it ? > > Comment for fid_reserved about longword alignment is wrong. Well, it's actually more broken than that. fid_len - Most file systems set it to the size of their variant of the entire structure, including the Xfid_len field. ZFS sets it to the size of the structure - sizeof(uint16_t) { presumably subtracting out the size if Xfid_len? }. And xfs, well, it does weird stuff with it I can't figure out, but it is definitely not the size of the entire struct. As such, exposing fid_len above the VOP_xxx() doesn't make much sense. (After my commit yesterday, nothing above the VOP_VPTOFH() uses it.) Personally, I'd lean towards a generic struct fid like... struct fid { uint8_t fid_data[MAXFIDSZ]; }; with MAXFIDSZ increased appropriately, but this will require changes to xfs and zfs, since they both set the generic fid_len. If you go with... struct fid { uint16_t fid_len; uint8_t fid_data[MAXFIDSZ]; }; then the hash functions in the two NFS servers need to be changed (they assume 32bit alignment of fid_data), but they should be fixed anyhow, since they mostly hash to 0 for ZFS at this time. (From what I see ZFS file handles looking like.) Or, you could just rename fid_reserved to fid_pad and not worry about it. Maybe the ZFS folks could decide what they would prefer? rick