From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: clm@fb.com, jbacik@fb.com, hch@infradead.org,
linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-kernel@vger.kernel.org, jeffm@suse.com, fdmanana@suse.com,
"Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [RFC v3 0/2] vfs / btrfs: add support for ustat()
Date: Fri, 15 Aug 2014 10:29:50 +0100 [thread overview]
Message-ID: <20140815092950.GZ18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1408071538-14354-1-git-send-email-mcgrof@do-not-panic.com>
On Thu, Aug 14, 2014 at 07:58:56PM -0700, Luis R. Rodriguez wrote:
> Christoph had noted that this seemed associated to the problem
> that the btrfs uses different assignments for st_dev than s_dev,
> but much as I'd like to see that changed based on discussions so
> far its unclear if this is going to be possible unless strong
> commitment is reached.
Explain, please. Whose commitment and commitment to what, exactly?
Having different ->st_dev values for different files on the same
fs is a bloody bad idea; why does btrfs do that at all? If nothing else,
it breaks the usual "are those two files on the same fs?" tests...
next prev parent reply other threads:[~2014-08-15 10:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-15 2:58 [RFC v3 0/2] vfs / btrfs: add support for ustat() Luis R. Rodriguez
2014-08-15 2:58 ` [RFC v3 1/2] fs/super.c: add new super block sub devices super_block_dev Luis R. Rodriguez
2014-08-15 2:58 ` [RFC v3 2/2] btrfs: use the new VFS super_block_dev Luis R. Rodriguez
2014-08-15 9:29 ` Al Viro [this message]
2014-08-17 23:41 ` [RFC v3 0/2] vfs / btrfs: add support for ustat() Luis R. Rodriguez
2017-08-23 22:31 ` Jeff Mahoney
2021-04-15 17:53 ` Luis Chamberlain
2021-04-15 18:17 ` Josef Bacik
2021-04-15 18:29 ` Luis Chamberlain
2021-04-16 17:20 ` Neal Gompa
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=20140815092950.GZ18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=clm@fb.com \
--cc=fdmanana@suse.com \
--cc=hch@infradead.org \
--cc=jbacik@fb.com \
--cc=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.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 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.