All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.