linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: NeilBrown <neilb@suse.de>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Chuck Lever <chuck.lever@oracle.com>, Chris Mason <clm@fb.com>,
	David Sterba <dsterba@suse.com>,
	linux-nfs@vger.kernel.org, Wang Yugui <wangyugui@e16-tech.com>,
	Ulli Horlacher <framstag@rus.uni-stuttgart.de>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH/RFC] NFSD: handle BTRFS subvolumes better.
Date: Thu, 15 Jul 2021 14:01:11 -0400	[thread overview]
Message-ID: <e1d9caad-e4c7-09d4-b145-5397b24e1cc7@toxicpanda.com> (raw)
In-Reply-To: <YPBvUfCNmv0ElBpo@infradead.org>

On 7/15/21 1:24 PM, Christoph Hellwig wrote:
> On Thu, Jul 15, 2021 at 01:11:29PM -0400, Josef Bacik wrote:
>> Because there's no alternative.  We need a way to tell userspace they've
>> wandered into a different inode namespace.  There's no argument that what
>> we're doing is ugly, but there's never been a clear "do X instead".  Just a
>> lot of whinging that btrfs is broken.  This makes userspace happy and is
>> simple and straightforward.  I'm open to alternatives, but there have been 0
>> workable alternatives proposed in the last decade of complaining about it.
> 
> Make sure we cross a vfsmount when crossing the "st_dev" domain so
> that it is properly reported.   Suggested many times and ignored all
> the time beause it requires a bit of work.
> 

You keep telling me this but forgetting that I did all this work when you 
originally suggested it.  The problem I ran into was the automount stuff 
requires that we have a completely different superblock for every vfsmount. 
This is fine for things like nfs or samba where the automount literally points 
to a completely different mount, but doesn't work for btrfs where it's on the 
same file system.  If you have 1000 subvolumes and run sync() you're going to 
write the superblock 1000 times for the same file system.  You are going to 
reclaim inodes on the same file system 1000 times.  You are going to reclaim 
dcache on the same filesytem 1000 times.  You are also going to pin 1000 
dentries/inodes into memory whenever you wander into these things because the 
super is going to hold them open.

This is not a workable solution.  It's not a matter of simply tying into 
existing infrastructure, we'd have to completely rework how the VFS deals with 
this stuff in order to be reasonable.  And when I brought this up to Al he told 
me I was insane and we absolutely had to have a different SB for every vfsmount, 
which means we can't use vfsmount for this, which means we don't have any other 
options.  Thanks,

Josef

  reply	other threads:[~2021-07-15 18:01 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210613115313.BC59.409509F4@e16-tech.com>
2021-03-10  7:46 ` nfs subvolume access? Ulli Horlacher
2021-03-10  7:59   ` Hugo Mills
2021-03-10  8:09     ` Ulli Horlacher
2021-03-10  9:35       ` Graham Cobb
2021-03-10 15:55         ` Ulli Horlacher
2021-03-10 17:29           ` Forza
2021-03-10 17:46             ` Ulli Horlacher
2021-03-10  8:17   ` Ulli Horlacher
2021-03-11  7:46   ` Ulli Horlacher
2021-07-08 22:17     ` cannot use btrfs for nfs server Ulli Horlacher
2021-07-09  0:05       ` Graham Cobb
2021-07-09  4:05         ` NeilBrown
2021-07-09  6:53         ` Ulli Horlacher
2021-07-09  7:23           ` Forza
2021-07-09  7:24             ` Hugo Mills
2021-07-09  7:34             ` Ulli Horlacher
2021-07-09 16:30               ` Chris Murphy
2021-07-10  6:35                 ` Ulli Horlacher
2021-07-11 11:41                   ` Forza
2021-07-12  7:17                     ` Ulli Horlacher
2021-07-09 16:35           ` Chris Murphy
2021-07-10  6:56             ` Ulli Horlacher
2021-07-10 22:17               ` Chris Murphy
2021-07-12  7:25                 ` Ulli Horlacher
2021-07-12 13:06                   ` Graham Cobb
2021-07-12 16:16                     ` Ulli Horlacher
2021-07-12 22:56                       ` g.btrfs
2021-07-13  7:37                         ` Ulli Horlacher
2021-07-19 12:06                           ` Forza
2021-07-19 13:07                             ` Forza
2021-07-19 13:35                               ` Forza
2021-07-27 11:27                             ` Ulli Horlacher
2021-07-09 16:06       ` Lord Vader
2021-07-10  7:03         ` Ulli Horlacher
     [not found]   ` <162632387205.13764.6196748476850020429@noble.neil.brown.name>
2021-07-15 14:09     ` [PATCH/RFC] NFSD: handle BTRFS subvolumes better Josef Bacik
2021-07-15 16:45       ` Christoph Hellwig
2021-07-15 17:11         ` Josef Bacik
2021-07-15 17:24           ` Christoph Hellwig
2021-07-15 18:01             ` Josef Bacik [this message]
2021-07-15 22:37               ` NeilBrown
2021-07-19 15:40                 ` Josef Bacik
2021-07-19 20:00                   ` J. Bruce Fields
2021-07-19 20:44                     ` Josef Bacik
2021-07-19 23:53                       ` NeilBrown
2021-07-19 15:49                 ` J. Bruce Fields
2021-07-20  0:02                   ` NeilBrown
2021-07-19  9:16               ` Christoph Hellwig
2021-07-19 23:54                 ` NeilBrown
2021-07-20  6:23                   ` Christoph Hellwig
2021-07-20  7:17                     ` NeilBrown
2021-07-20  8:00                       ` Christoph Hellwig
2021-07-20 23:11                         ` NeilBrown
2021-07-20 22:10               ` J. Bruce Fields
2021-07-15 23:02       ` NeilBrown
2021-07-15 15:45     ` J. Bruce Fields
2021-07-15 23:08       ` NeilBrown

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=e1d9caad-e4c7-09d4-b145-5397b24e1cc7@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=framstag@rus.uni-stuttgart.de \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=wangyugui@e16-tech.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).