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 -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
