Re: nfs exporting my stacked fs

[David Chow <davidchow@shaolinmicro.com>]

>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