Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758575AbZATEZK (ORCPT ); Mon, 19 Jan 2009 23:25:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754494AbZATEYx (ORCPT ); Mon, 19 Jan 2009 23:24:53 -0500 Received: from ns.suse.de ([195.135.220.2]:48065 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753980AbZATEYv (ORCPT ); Mon, 19 Jan 2009 23:24:51 -0500 Message-ID: <49755376.3000100@suse.de> Date: Tue, 20 Jan 2009 12:30:46 +0800 From: Coly Li Reply-To: coly.li@suse.de Organization: SuSE Labs User-Agent: Thunderbird 2.0.0.19 (X11/20090106) MIME-Version: 1.0 To: Andreas Dilger Cc: Dave Kleikamp , linux-kernel@vger.kernel.org, Andrew Morton , Roman Zippel , "Sergey S. Kostyliov" , OGAWA Hirofumi , Mikulas Patocka , Bob Copeland , Anders Larsen , reiserfs-devel@vger.kernel.org, Phillip Lougher , Christoph Hellwig , Evgeniy Dushistov , Jan Kara , linux-fsdevel Subject: Re: [PATCH 0/20] return f_fsid for statfs(2) References: <4974B8C4.3070703@suse.de> <1232393334.5893.42.camel@norville.austin.ibm.com> <20090119233651.GK3286@webber.adilger.int> <1232419149.19468.3.camel@norville.austin.ibm.com> <20090120041349.GL3286@webber.adilger.int> In-Reply-To: <20090120041349.GL3286@webber.adilger.int> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1548 Lines: 32 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/