All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, yebin <yebin10@huawei.com>,
	linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	Joseph Qi <joseph.qi@linux.alibaba.com>
Subject: Re: [PATCH RFC 2/2] block: Do not discard buffers under a mounted filesystem
Date: Tue, 25 Aug 2020 17:12:56 +0200	[thread overview]
Message-ID: <20200825151256.GD32298@quack2.suse.cz> (raw)
In-Reply-To: <20200825141020.GA668551@mit.edu>

On Tue 25-08-20 10:10:20, Theodore Y. Ts'o wrote:
> (Adding the OCFS2 maintainers, since my possibly insane idea proposed
> below would definitely impact them!)
> 
> On Tue, Aug 25, 2020 at 01:16:16PM +0100, Christoph Hellwig wrote:
> > On Tue, Aug 25, 2020 at 02:05:54PM +0200, Jan Kara wrote:
> > > Discarding blocks and buffers under a mounted filesystem is hardly
> > > anything admin wants to do. Usually it will confuse the filesystem and
> > > sometimes the loss of buffer_head state (including b_private field) can
> > > even cause crashes like:
> > 
> > Doesn't work if the file system uses multiple devices.  I think we
> > just really need to split the fs buffer_head address space from the
> > block device one.  Everything else is just going to cause a huge mess.
> 
> I wonder if we should go a step further, and stop using struct
> buffer_head altogether in jbd2 and ext4 (as well as ocfs2).

What about the cache coherency issues I've pointed out in my reply to
Christoph?

> This would involve moving whatever structure elements from the
> buffer_head struct into journal_head, and manage writeback and reads
> requests directly in jbd2.  This would allow us to get detailed write
> errors back, which is currently not possible from the buffer_head
> infrastructure.
> 
> The downside is this would be a pretty massive change in terms of LOC,
> since we use struct buffer_head in a *huge* number of places.  If
> we're careful, most of it could be handled by a Coccinelle script to
> rename "struct buffer_head" to "struct journal_head".  Fortunately, we
> don't actually use that much of the fs/buffer_head functions in
> fs/{ext4,ocfs2}/*.c.
> 
> One potentially tricky bit is that ocfs2 hasn't been converted to
> using iomap, so it's still using __blockdev_direct_IO.  So it's data
> blocks for DIO would still have to use struct buffer_head (which means
> the Coccinelle script won't really work for fs/ocfs2, without a lot of
> manual rework) --- or ocfs2 would have to switched to use iomap at
> least for DIO support.
> 
> What do folks think?

Otherwise yes, this would be doable although pretty invasive as you
mention.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2020-08-25 15:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-25 12:05 [PATCH RFC 0/2] Block and buffer invalidation under a filesystem Jan Kara
2020-08-25 12:05 ` [PATCH RFC 1/2] fs: Don't invalidate page buffers in block_write_full_page() Jan Kara
2020-08-25 12:05 ` [PATCH RFC 2/2] block: Do not discard buffers under a mounted filesystem Jan Kara
2020-08-25 12:16   ` Christoph Hellwig
2020-08-25 14:10     ` Theodore Y. Ts'o
2020-08-25 15:12       ` Jan Kara [this message]
2020-08-25 18:41         ` Matthew Wilcox
2020-08-25 18:49           ` Jan Kara
2020-08-25 14:50     ` Jan Kara
2020-08-27  7:16       ` Christoph Hellwig
2020-08-27 21:39         ` Al Viro
2020-08-28  0:07           ` Dave Chinner
2020-08-28  8:10             ` Jan Kara
2020-08-28  8:21     ` Andreas Dilger
2020-08-29  6:40       ` Christoph Hellwig
2020-08-31  7:48         ` Jan Kara

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=20200825151256.GD32298@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=jlbec@evilplan.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=tytso@mit.edu \
    --cc=yebin10@huawei.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.