All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Improve support for exporting btrfs subvolumes.
Date: Tue, 22 Jun 2010 16:16:28 -0400	[thread overview]
Message-ID: <4C211A1C.4010701@RedHat.com> (raw)
In-Reply-To: <19481.43625.476833.275104-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>



On 06/17/2010 12:54 AM, Neil Brown wrote:
> 
> If you export two subvolumes of a btrfs filesystem, they will both be
> given the same uuid so lookups will be confused.
> blkid cannot differentiate the two, so we must use the fsid from
> statfs64 to identify the filesystem.
> 
> We cannot tell if blkid or statfs is best without knowing internal
> details of the filesystem in question, so we need to encode specific
> knowledge of btrfs in mountd.  This is unfortunate.
> 
> To ensure smooth handling of this and possible future changes in uuid
> generation, we add infrastructure for multiple different uuids to be
> recognised on old filehandles, but only the preferred on is used on
> new filehandles.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> --
> This is a substantially revised version of a patch I posted a while
> ago.
> I tried to find a way to do it would hard coding knowledge of btrfs in
> nfs-utils, but it isn't possible.  For some filesystems, f_fsid is
> best, for some it is worst.  No way to tell the difference.
> 
> This patch add infrastructure so that if we find a better way to get a
> good uuid (e.g. a new syscall), we can slot it in for new filehandles,
> but old filehandles using the old uuid will still work.
> 
> I believe this is ready for inclusion upstream.

Committed...

steved.


  parent reply	other threads:[~2010-06-22 20:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17  4:54 [PATCH] Improve support for exporting btrfs subvolumes Neil Brown
     [not found] ` <19481.43625.476833.275104-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-06-22 20:16   ` Steve Dickson [this message]
2010-06-23 18:28   ` J. Bruce Fields
2010-06-23 21:31     ` Neil Brown
     [not found]       ` <20100624073157.743983ec-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-06-24  0:15         ` J. Bruce Fields

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=4C211A1C.4010701@RedHat.com \
    --to=steved@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.