From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chow Subject: Re: nfs exporting my stacked fs Date: Thu, 05 Jun 2003 23:38:04 +0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3EDF63DC.4080305@shaolinmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from [202.94.238.145] ([202.94.238.145]:12991 "EHLO mail.shaolinmicro.com") by vger.kernel.org with ESMTP id S264719AbTFEPYg (ORCPT ); Thu, 5 Jun 2003 11:24:36 -0400 Received: from shaolinmicro.com (cm61-15-171-82.hkcable.com.hk [61.15.171.82]) by mail.shaolinmicro.com (8.12.8/8.12.5) with ESMTP id h55Fc5GL026838 for ; Thu, 5 Jun 2003 23:38:05 +0800 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org >Agreed, but note that you're talking specifically about a very recent Linux >system with a careful system administrator. I was talking about the world >of NFS in general -- the practical world. > > > >>For most setups, this should not be necessary (since device numbers >>will suffice). Those that don't have permanently allocated device >>numbers (e.g. fibre channel), should use the fsid export option in >>order to provide a permanent value... >> >> OK, I think I'd ask Trond a similar question long ago about fsids. One good example of the need of fsid is high availability NFS . When a shared volume over fibre-channel, SAN or shared SCSI will definitely alter the device numbers without having to recabling . IBM's SAN unit does support virtual LUNs (I had a go with FastT 200 and Bryan should know better than me do) which device number has no sense at all. One or more machines can share the same physical volume with different LUNs (seen by the OS) and of course, device numbers are just junk. I think SAN is a subsystem designed for server farms, it is a bit difficult to make cluster of servers to maintain universal global device numbers, otherwise failover doesn't work though. May be for apps but unfortunately not NFS without fsid . >But now you're talking about sufficiency, whereas I was talking about >actually implementing unique fsids. Device number is clearly sufficient, >since people have been using it for decades. But it does not come close to >being a real fsid. No device numbers in Linux (on architectures I know >about) are permanently associated with physical devices. Lots of things, >including recabling, can change them. Moreover, filesystems are not >permanently associated with physical devices. You can move a filesystem >from one device to another. > >The fsid export option, while a leap ahead of what we had before, is >clearly not the ultimate solution to the fsid problem, because it requires >too much human participation. System administrators don't normally have to >administrate at that level. It's like choosing device addresses and IRQ >levels when you install network cards. > > Why not? We did that in the old days didn't we? A unversity graduate from computer course should well understand what is an address or IRQ. If I am a careful sys admin or settting up a HA cluster failover solution, I'll need it. I strongly support the fsid option as there is no point to remove it. For other users (admin who don't care or standalone nfs servers), nfsd can still use the device numbers to generate file handles. Referring the subject of this mail, I did wrote a nfsd exportable consistent stacked fs . I simply register a dummy block device in my fs module to fool the nfsd I had one (in sense I don't use it at all). However, a change in fstab can change everything. Whether you guys want to rely on fsid in nfsd export identification, its up to you as I am not the maintainer of it. However, I do find it useful and especially for stacked fs and in many situation disregarding your fs is stacked or not. Or fsid should have save some device numbers (as they will run out soon) at least I don't have to waste a couple of them. regards, David Chow