From: Oleg Drokin <green@linuxhacker.ru>
To: neilb@cse.unsw.edu.au
Cc: linux-fsdevel@vger.kernel.org
Subject: FS-specified FSID for non-device based filesystems?
Date: Wed, 12 Apr 2006 14:10:03 +0300 [thread overview]
Message-ID: <20060412111003.GZ26989@linuxhacker.ru> (raw)
Hello!
Right now NFSD depends on FS_REQUIRES_DEV to be set in sb->s_type->fs_flags
or manually set fsid= in /etc/exports in order to export filesystem.
But there are non-device based filesystems (Lustre for example ;) ) that
would like to be exported via NFS without guiding users through this
fsid= business. Of course it is easy to cheat through by setting
FS_REQUIRES_DEV, but this does not solve entire problem. While allowing
for single-node export of filesystem to work ok, more generic problem of
exporting same filesystem from several NFS servers in clustered manner
won't work because sb->s_dev might be different on different nodes.
This is not only Lustre problem, I believe same problem will happen
with GFS or OCFS2 or whatever other SAN-based fs if different nodes
have different device names (/dev/sda | /dev/sdb) for same SAN device,
in such a case fsid calculated would be different on different nodes too.
I wonder if e.g. another export op could be introduced to ask filesystem
for its unique id (if supported) and use that instead of sb->s_dev in
fsid calculations. Does this look sane?
I hope I am not missing anything?
Or are there better ideas?
Thanks.
Bye,
Oleg
next reply other threads:[~2006-04-12 11:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-12 11:10 Oleg Drokin [this message]
2006-04-14 20:22 ` FS-specified FSID for non-device based filesystems? Bryan Henderson
2006-04-14 20:45 ` Oleg Drokin
2006-04-14 20:59 ` J. Bruce Fields
2006-04-14 21:32 ` Bryan Henderson
2006-04-14 21:41 ` Oleg Drokin
2006-04-17 0:54 ` Neil Brown
2006-04-17 3:50 ` Greg KH
2006-04-17 4:32 ` Neil Brown
2006-04-18 18:07 ` Greg KH
2006-04-19 12:15 ` Miklos Szeredi
2006-04-20 11:35 ` Al Viro
2006-04-20 11:58 ` Miklos Szeredi
2006-04-20 12:30 ` Al Viro
2006-04-20 12:43 ` Miklos Szeredi
2006-04-17 8:00 ` Anton Altaparmakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060412111003.GZ26989@linuxhacker.ru \
--to=green@linuxhacker.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.