Re: [PATCH RFC 2/2] block: Do not discard buffers under a mounted filesystem

[Jan Kara <jack@suse.cz>]

On Tue 25-08-20 19:41:07, Matthew Wilcox wrote:
> On Tue, Aug 25, 2020 at 05:12:56PM +0200, Jan Kara wrote:
> > 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?
> 
> If journal_heads pointed into the page cache as well, then you'd get
> coherency.  These new journal heads would have to be able to cope with
> the page cache being modified underneath them, of course.

I was thinking about this as well but IMHO it would be quite complex - e.g.
we could then have both buffer_heads (for block dev) and journal heads (for
fs) to have different opinions on block state (uptodate, dirty, ...) and
who now determines what the final page state is (e.g. for reclaim
purposes)? Sure we can all sort this out with various callbacks etc. but at
that point we are not really simplifying things anymore...

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