All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] allow building a kernel without buffer_heads
Date: Thu, 20 Jul 2023 09:51:30 -0500	[thread overview]
Message-ID: <251d9862-e335-243e-d65a-c5538b4df253@redhat.com> (raw)
In-Reply-To: <20230720140452.63817-1-hch@lst.de>

On 7/20/23 9:04 AM, Christoph Hellwig wrote:
> Hi all,
> 
> This series allows to build a kernel without buffer_heads, which I
> think is useful to show where the dependencies are, and maybe also
> for some very much limited environments, where people just needs
> xfs and/or btrfs and some of the read-only block based file systems.
> 
> It first switches buffered writes (but not writeback) for block devices
> to use iomap unconditionally, but still using buffer_heads, and then
> adds a CONFIG_BUFFER_HEAD selected by all file systems that need it
> (which is most block based file systems), makes the buffer_head support
> in iomap optional, and adds an alternative implementation of the block
> device address_operations using iomap.  This latter implementation
> will also be useful to support block size > PAGE_SIZE for block device
> nodes as buffer_heads won't work very well for that.
> 
> Note that for now the md software raid drivers is also disabled as it has
> some (rather questionable) buffer_head usage in the unconditionally built
> bitmap code.  I have a series pending to make the bitmap code conditional
> and deprecated it, but it hasn't been merged yet.
> 
> Changes since v1:
>   - drop the already merged prep patches
>   - depend on FS_IOMAP not IOMAP
>   - pick a better new name for block_page_mkwrite_return
> 
Hi Christoph,

Gfs2 still uses buffer_heads to manage the metadata being pushed through 
its journals. We've been reducing our dependency on them but eliminating 
them altogether is a large and daunting task. We can still work toward 
that goal, but it will take time.

Bob Peterson


WARNING: multiple messages have this Message-ID (diff)
From: Bob Peterson <rpeterso@redhat.com>
To: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	Christian Brauner <christian@brauner.io>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	cluster-devel <cluster-devel@redhat.com>
Subject: Re: allow building a kernel without buffer_heads
Date: Thu, 20 Jul 2023 09:51:30 -0500	[thread overview]
Message-ID: <251d9862-e335-243e-d65a-c5538b4df253@redhat.com> (raw)
In-Reply-To: <20230720140452.63817-1-hch@lst.de>

On 7/20/23 9:04 AM, Christoph Hellwig wrote:
> Hi all,
> 
> This series allows to build a kernel without buffer_heads, which I
> think is useful to show where the dependencies are, and maybe also
> for some very much limited environments, where people just needs
> xfs and/or btrfs and some of the read-only block based file systems.
> 
> It first switches buffered writes (but not writeback) for block devices
> to use iomap unconditionally, but still using buffer_heads, and then
> adds a CONFIG_BUFFER_HEAD selected by all file systems that need it
> (which is most block based file systems), makes the buffer_head support
> in iomap optional, and adds an alternative implementation of the block
> device address_operations using iomap.  This latter implementation
> will also be useful to support block size > PAGE_SIZE for block device
> nodes as buffer_heads won't work very well for that.
> 
> Note that for now the md software raid drivers is also disabled as it has
> some (rather questionable) buffer_head usage in the unconditionally built
> bitmap code.  I have a series pending to make the bitmap code conditional
> and deprecated it, but it hasn't been merged yet.
> 
> Changes since v1:
>   - drop the already merged prep patches
>   - depend on FS_IOMAP not IOMAP
>   - pick a better new name for block_page_mkwrite_return
> 
Hi Christoph,

Gfs2 still uses buffer_heads to manage the metadata being pushed through 
its journals. We've been reducing our dependency on them but eliminating 
them altogether is a large and daunting task. We can still work toward 
that goal, but it will take time.

Bob Peterson


  parent reply	other threads:[~2023-07-20 14:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20 14:04 allow building a kernel without buffer_heads Christoph Hellwig
2023-07-20 14:04 ` [PATCH 1/6] fs: remove emergency_thaw_bdev Christoph Hellwig
2023-07-20 14:12   ` Johannes Thumshirn
2023-07-20 15:43   ` Hannes Reinecke
2023-07-24 19:54   ` Luis Chamberlain
2023-07-20 14:04 ` [PATCH 2/6] fs: rename and move block_page_mkwrite_return Christoph Hellwig
2023-07-20 14:13   ` Johannes Thumshirn
2023-07-20 15:45   ` Hannes Reinecke
2023-07-24 19:55   ` Luis Chamberlain
2023-07-20 14:04 ` [PATCH 3/6] block: open code __generic_file_write_iter for blkdev writes Christoph Hellwig
2023-07-20 14:14   ` Johannes Thumshirn
2023-07-20 15:46   ` Hannes Reinecke
2023-07-24 20:05   ` Luis Chamberlain
2023-07-20 14:04 ` [PATCH 4/6] block: stop setting ->direct_IO Christoph Hellwig
2023-07-20 14:15   ` Johannes Thumshirn
2023-07-20 15:46   ` Hannes Reinecke
2023-07-24 20:07   ` Luis Chamberlain
2023-07-20 14:04 ` [PATCH 5/6] block: use iomap for writes to block devices Christoph Hellwig
2023-07-20 15:48   ` Hannes Reinecke
2023-07-24 20:14   ` Luis Chamberlain
2023-07-27  9:14   ` Pankaj Raghav
2023-07-20 14:04 ` [PATCH 6/6] fs: add CONFIG_BUFFER_HEAD Christoph Hellwig
2023-07-20 14:45   ` Matthew Wilcox
2023-07-21  6:24     ` Christoph Hellwig
2023-07-20 15:53   ` Hannes Reinecke
2023-07-21  6:25     ` Christoph Hellwig
2023-07-24 20:16   ` Luis Chamberlain
2023-07-20 14:51 ` Bob Peterson [this message]
2023-07-20 14:51   ` allow building a kernel without buffer_heads Bob Peterson
2023-07-21  6:26   ` [Cluster-devel] " Christoph Hellwig
2023-07-21  6:26     ` Christoph Hellwig

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=251d9862-e335-243e-d65a-c5538b4df253@redhat.com \
    --to=rpeterso@redhat.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.