From owner-svn-src-all@FreeBSD.ORG Sun Sep 12 03:04: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 1D43B106564A; Sun, 12 Sep 2010 03:04:24 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A9C5C8FC12; Sun, 12 Sep 2010 03:04:23 +0000 (UTC) Received: by iwn34 with SMTP id 34so4333155iwn.13 for ; Sat, 11 Sep 2010 20:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=CFLTq4cyofDKMZYgo8WYoidVABqWc6Jnp2TaakudrcA=; b=nLBI/eh6YAn3zBD/jUy1y4bDM5YXueKCmxYgeQSTXa9v0R2+NJzPZjQ5FVj5VuRQK5 ukmEY/BaqnBlO6uEgthXj8lgcZIT6YdlSRRRPC4Ul5TEkoQy+ZnOnLPoiDBXlTFV3HJJ UucuV4eyk4oZHRt3m0pxjLKJBySqdWFp1Upd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Owe4i4UvSapdSmvulpOlubH1OsuUwq+l+wmXwG84+8o8X5m/BrrjcIXQ8nUbHCXeN/ eXe1U8KDfvkIPhSZWOIUeOLHKU996qto7vZOFBRN9upkrtPgtCKhm07j0xVQceV/cVYg Y9s7EJEpvaoITTazvZ359yOCMgnWgI9AZyg+s= MIME-Version: 1.0 Received: by 10.231.162.2 with SMTP id t2mr3748164ibx.57.1284260662922; Sat, 11 Sep 2010 20:04:22 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.130.34 with HTTP; Sat, 11 Sep 2010 20:04:22 -0700 (PDT) In-Reply-To: <1300087421.776986.1284252082593.JavaMail.root@erie.cs.uoguelph.ca> References: <20100911060111.GT2465@deviant.kiev.zoral.com.ua> <1300087421.776986.1284252082593.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 12 Sep 2010 03:04:22 +0000 X-Google-Sender-Auth: smkW1GnVZf6nUs70Q7PEyZJT9r4 Message-ID: From: mdf@FreeBSD.org To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rick Macklem 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 03:04:25 -0000 On Sun, Sep 12, 2010 at 12:41 AM, Rick Macklem wrote= : >> 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 > =A0 =A0 =A0 =A0 =A0of the entire structure, including the Xfid_len field. > =A0 =A0 =A0 =A0 =A0ZFS sets it to the size of the structure - sizeof(uint= 16_t) > =A0 =A0 =A0 =A0 =A0{ presumably subtracting out the size if Xfid_len? }. > =A0 =A0 =A0 =A0 =A0And xfs, well, it does weird stuff with it I can't fig= ure > =A0 =A0 =A0 =A0 =A0out, but it is definitely not the size of the entire s= truct. > > 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 { > =A0 =A0 =A0 uint8_t fid_data[MAXFIDSZ]; > }; Isilon would love a generic struct like this, as to fit our filesystem we had to make such a change locally anyways. :-) Cheers, matthew > 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 { > =A0 =A0 =A0 uint16_t fid_len; > =A0 =A0 =A0 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 >