[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <20090119233651.GK3286@webber.adilger.int>
Date: Tue, 20 Jan 2009 07:36:51 +0800
From: Andreas Dilger <adilger@....com>
To: Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Cc: coly.li@...e.de, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Zippel <zippel@...ux-m68k.org>,
"Sergey S. Kostyliov" <rathamahata@...4.ru>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>,
Dave Kleikamp <shaggy@...tin.ibm.com>,
Bob Copeland <me@...copeland.com>,
Anders Larsen <al@...rsen.net>, reiserfs-devel@...r.kernel.org,
Phillip Lougher <phillip@...gher.demon.co.uk>,
Christoph Hellwig <hch@...radead.org>,
Evgeniy Dushistov <dushistov@...l.ru>, Jan Kara <jack@...e.cz>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 0/20] return f_fsid for statfs(2)
On Jan 19, 2009 13:28 -0600, Dave Kleikamp wrote:
> ext[234] return a portion of the uuid in f_fsid. There is a theoretical
> chance of those values being non-unique. Since there doesn't appear to
> be any case for the fsid to be persistent between boots, I guess
> huge_encode_dev() is probably a better choice. In practice it probably
> makes no difference.
I'm not sure what you mean about "no case for fsid to be persistent"?
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).
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists