From owner-freebsd-current@FreeBSD.ORG Sat Aug 20 22:07:43 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 F39B8106566B; Sat, 20 Aug 2011 22:07:42 +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 827F08FC15; Sat, 20 Aug 2011 22:07:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAC8vUE6DaFvO/2dsb2JhbABBhEukQYFAAQEFIwRSGw4KAgINGQJZBhMbr1OQQoEshAyBEASTFJES X-IronPort-AV: E=Sophos;i="4.68,257,1312171200"; d="scan'208";a="135035488" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 20 Aug 2011 18:07:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0BA51B3FC2; Sat, 20 Aug 2011 18:07:40 -0400 (EDT) Date: Sat, 20 Aug 2011 18:07:40 -0400 (EDT) From: Rick Macklem To: Hiroki Sato Message-ID: <1522286016.115315.1313878060040.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110820.142859.319295417241413417.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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 22:07:43 -0000 Hiroki Sato wrote: > 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 If anyone thinks using a fixed table to assign vfc_typenum for known file system types is a bad idea, please let us know. Otherwise I will make up a patch, rick