From: Josef Bacik <jbacik@fusionio.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Josef Bacik <jbacik@fusionio.com>, Mark Fasheh <mfasheh@suse.de>,
<viro@ZenIV.linux.org.uk>, <linux-fsdevel@vger.kernel.org>,
<linux-btrfs@vger.kernel.org>,
Chris Mason <chris.mason@fusionio.com>,
Andrew Vagin <avagin@gmail.com>
Subject: Re: [PATCH][RESEND] vfs: allow /proc/PID/maps to get device from stat
Date: Thu, 8 Aug 2013 09:02:07 -0400 [thread overview]
Message-ID: <20130808130207.GA16712@localhost.localdomain> (raw)
In-Reply-To: <20130808121349.GC5180@infradead.org>
On Thu, Aug 08, 2013 at 05:13:49AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 07, 2013 at 04:51:46PM -0400, Josef Bacik wrote:
> > Not possible, this will break other things as subvolumes have their own inode
> > space, it will confuse applications that get multiples of an inode number for
> > different devices with the same st_dev. Each subvolume has it's own anonymous
> > dev to segregate things. Thanks,
>
> Yes, it's the same old issue of btrfs volumes misbehaving, and the
> solution is still the same as 5 years ago: make sure each subvolume
> has it's own sb, vfsmount and gets automounted, similar to what nfs4
> does for this case.
This won't work, try having 10000 subvolumes with dirty inodes and do sync then
go skiing, you'll have time :). Thanks,
Josef
next prev parent reply other threads:[~2013-08-08 13:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 19:57 [PATCH][RESEND] vfs: allow /proc/PID/maps to get device from stat Mark Fasheh
2013-08-07 20:18 ` Christoph Hellwig
2013-08-07 20:51 ` Josef Bacik
2013-08-08 12:13 ` Christoph Hellwig
2013-08-08 13:02 ` Josef Bacik [this message]
2013-08-08 13:48 ` Christoph Hellwig
2013-08-08 15:31 ` Josef Bacik
2013-08-08 15:44 ` Josef Bacik
2013-08-12 11:47 ` Christoph Hellwig
2013-09-10 15:36 ` Mark Fasheh
2013-09-10 15:56 ` Josef Bacik
2013-09-10 21:21 ` Jeff Mahoney
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=20130808130207.GA16712@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=avagin@gmail.com \
--cc=chris.mason@fusionio.com \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mfasheh@suse.de \
--cc=viro@ZenIV.linux.org.uk \
/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.