Re: [PATCH 0/20] return f_fsid for statfs(2)

[Coly Li <coly.li@suse.de>]

Andreas Dilger Wrote:
> On Jan 19, 2009  20:39 -0600, Dave Kleikamp wrote:
>> On Tue, 2009-01-20 at 07:36 +0800, Andreas Dilger wrote:
>>> The whole point of fsid (for NFS) is that this identifies the filesystem
>>> over reboot, even if the block device ID changes, or if the filesystem
>>> doesn't have a block device at all (e.g. cluster filesystem).
>> I guess that just demonstrates how little I know about what the fsid is
>> about.  Would it be preferable for file systems that have a uuid to use
>> that instead?  Of course anything is an improvement over zeroes.
> 
> Yes, that is what the ext* patches do - fold the 128-bit UUID into a 64-bit
> fsid so that it is constant across reboots.  The chance of UUID collision
> is about 1/2^32 due to birthday paradox, which is fairly low, and in case
> this happens one of the filesystem UUIDs can be regenerated.
> 
Ext[234] is sophisticated to have on-disk uuid record. Most file systems in the patches (except jfs
and reiser3) do not have a persistent uuid, a reasonable/feasible solution without media format
modification is fsid in boot/mount life cycle. That's why huge_encode_dev(sb->s_bdev->bd_dev) is
used here.
For jfs and reiserfs3, is there any use case for persistent fsid cross boots ?

Thanks for your reviews.
-- 
Coly Li
SuSE Labs