From owner-freebsd-current@FreeBSD.ORG Sat Aug 20 05:29:25 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62886106564A; Sat, 20 Aug 2011 05:29:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id B1C338FC14; Sat, 20 Aug 2011 05:29:24 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p7K5TA6t080379; Sat, 20 Aug 2011 14:29:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p7K5T8QF092205; Sat, 20 Aug 2011 14:29:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 20 Aug 2011 14:28:59 +0900 (JST) Message-Id: <20110820.142859.319295417241413417.hrs@allbsd.org> To: rmacklem@uoguelph.ca From: Hiroki Sato In-Reply-To: <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca> <1623060518.69434.1313764367817.JavaMail.root@erie.cs.uoguelph.ca> References: <20110819.224310.740411147168584392.hrs@allbsd.org> <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Aug_20_14_28_59_2011_946)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 20 Aug 2011 14:29:22 +0900 (JST) X-Spam-Status: No, score=-103.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_ZERO,QENCPTR1,RDNS_NONE,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: pjd@FreeBSD.org, current@FreeBSD.org Subject: Re: fsid change of ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 05:29:25 -0000 ----Security_Multipart(Sat_Aug_20_14_28_59_2011_946)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in <1565511281.69213.1313764157732.JavaMail.root@erie.cs.uoguelph.ca>: rm> Hiroki Sato wrote: rm> > fsid_guid = dmu_objset_fsid_guid(zfsvfs->z_os); rm> > ASSERT((fsid_guid & ~((1ULL<<56)-1)) == 0); rm> > vfsp->vfs_fsid.val[0] = fsid_guid; rm> > vfsp->vfs_fsid.val[1] = ((fsid_guid>>32) << 8) | rm> > vfsp->mnt_vfc->vfc_typenum & 0xFF; rm> > rm> > Since the vfc_typenum variable is incremented every time a new vfs is rm> > installed, loading order of modules that call vfs_register() affects rm> > ZFS's fsid. rm> > rm> > Anyway, possibility of fsid change is troublesome especially for an rm> > NFS server with a lot of clients running. Can zeroing or setting a rm> > fixed value to the lowest 8-bit of vfs_fsid.val[1] be harmful? rm> > rm> > -- Hiroki rm> Well, the problem is that the fsid needs to be unique among all mounts. rm> The vfs_typenum field is used to try and ensure that it does not end up rm> the same value as a non-ZFS file system. rm> rm> (A) I think making that field a fixed constant should be ok, if the function rm> checks for a conflict by calling vfs_getvfs() to check for one. rm> See vfs_getnewfsid() for how this is done. (There is a mutex lock that rm> needs to be held while doing it.) Alternately, if ZFS can call vfs_getnewfsid() rm> instead of doing its own, that might be nicer? rm> rm> (B) Another way to fix this would be to modify vfs_register() to look up rm> file systems in a table (by vfc_name) and used a fixed, assigned value rm> from the table for vfc_typenum for entries found in the table. Only do rm> the "maxvfsconf++" when there isn't an entry for the fstype in the table. rm> (VFS_GENERIC can be set to the size of the table. That's what happened rm> in the bad old days when vfsconf was a table built at kernel config time.) rm> rm> If you guys think (B) is preferred, I could come up with a patch. I don't rm> know enough about ZFS to do (A). rm> Oh, and I think other fs types will suffer the same fate, except that rm> they usually avoid it, because they are compiled into the kernel and rm> the assignment of vfs_typenum happens in the same order-->same value. Yes, using vfs_getnewfsid() does not solve the issue. I noticed that Solaris looked up a fixed array vfssw[] exactly for the purpose. I think a table like it is a good solution for fixing fsid for each file system. -- Hiroki ----Security_Multipart(Sat_Aug_20_14_28_59_2011_946)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5PRhwACgkQTyzT2CeTzy05OgCgg+cc8WedeU1yStBv1tj+Tu50 a+YAnjCz/s/kWr+lg2tOrNZANgmZlXw/ =5Ck0 -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Aug_20_14_28_59_2011_946)----