linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-nfs@vger.kernel.org,
	cluster-devel@redhat.com, linux-xfs@vger.kernel.org,
	Miklos Szeredi <miklos@szeredi.hu>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-kernel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	David Howells <dhowells@redhat.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ext4@vger.kernel.org, ceph-devel@vger.kernel.org
Subject: [f2fs-dev] RFC: allow building a kernel without buffer_heads
Date: Mon, 24 Apr 2023 07:49:09 +0200	[thread overview]
Message-ID: <20230424054926.26927-1-hch@lst.de> (raw)

Hi all,

after all the talk about removing buffer_heads, here is a series that
shows how to build a kernel without buffer_heads.  And how unrealistic
it is to remove the entirely.

Most of the series refactors some common code to make implementing direct
I/O easier without use of the ->direct_IO method and the helpers based
around it.  It then switches buffered writes (but not writeback) for
block devices to use iomap unconditionally, but still using buffer_heads.

The final patch 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.

With this you can build a kernel with block device support, but without
buffer_heads.  This kernel supports xfs and btrfs as full blown block
based filesystems, and a bunch of read-only ones like cramfs, erofs and
squashfs.  Note that the md software raid drivers is also disabled as it
has some (rather questionable) buffer_head usage in the unconditionally
built bitmap code.

The series is based on Linux 6.3 and will need some rebasing before it
can be fed to the maintainers incrementally.  All but the last patch
definitively seem useful for me.  The last one I think is just to avoid
introducing new buffer_head dependencies, even if I suspect the real
life usefulness of a !CONFIG_BUFFER_HEAD kernel might be rather limited.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

             reply	other threads:[~2023-04-24  5:49 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24  5:49 Christoph Hellwig [this message]
2023-04-24  5:49 ` [f2fs-dev] [PATCH 01/17] fs: unexport buffer_check_dirty_writeback Christoph Hellwig
2023-05-19 14:17   ` Hannes Reinecke
2023-07-06  0:18   ` patchwork-bot+f2fs
2023-09-04 18:11   ` patchwork-bot+f2fs
2023-04-24  5:49 ` [f2fs-dev] [PATCH 02/17] fs: remove the special !CONFIG_BLOCK def_blk_fops Christoph Hellwig
2023-04-24 19:22   ` Randy Dunlap
2023-04-24 19:37     ` Keith Busch
2023-04-24  5:49 ` [f2fs-dev] [PATCH 03/17] fs: rename and move block_page_mkwrite_return Christoph Hellwig
2023-04-24 12:30   ` Matthew Wilcox
2023-04-24 12:42     ` Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 04/17] fs: remove emergency_thaw_bdev Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 05/17] filemap: update ki_pos in generic_perform_write Christoph Hellwig
2023-04-24 18:54   ` [f2fs-dev] [Cluster-devel] " Andreas Gruenbacher
2023-04-24  5:49 ` [f2fs-dev] [PATCH 06/17] filemap: add a kiocb_write_and_wait helper Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 07/17] filemap: add a kiocb_invalidate_pages helper Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 08/17] filemap: add a kiocb_invalidate_post_write helper Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 09/17] fs: factor out a direct_write_fallback helper Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 10/17] iomap: use kiocb_write_and_wait and kiocb_invalidate_pages Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 11/17] iomap: assign current->backing_dev_info in iomap_file_buffered_write Christoph Hellwig
2023-04-24  6:18   ` Darrick J. Wong
2023-04-24  6:22     ` Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 12/17] fuse: use direct_write_fallback Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 13/17] block: don't plug in blkdev_write_iter Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 14/17] block: open code __generic_file_write_iter for blkdev writes Christoph Hellwig
2023-05-24 22:23   ` Luis Chamberlain
2023-04-24  5:49 ` [f2fs-dev] [PATCH 15/17] block: stop setting ->direct_IO Christoph Hellwig
2023-04-24  5:49 ` [f2fs-dev] [PATCH 16/17] block: use iomap for writes to block devices Christoph Hellwig
2023-05-19 14:22   ` Hannes Reinecke
2023-05-23 22:27     ` Dave Chinner via Linux-f2fs-devel
2023-05-24 13:33       ` Matthew Wilcox
2023-07-20 12:09         ` Christoph Hellwig
2023-07-20 12:06     ` Christoph Hellwig
2023-07-20 12:16       ` Hannes Reinecke
2023-04-24  5:49 ` [f2fs-dev] [PATCH 17/17] fs: add CONFIG_BUFFER_HEAD Christoph Hellwig
2023-04-29  0:11   ` Luis Chamberlain
2023-04-29  1:20     ` Matthew Wilcox
2023-05-01  3:14       ` Luis Chamberlain
2023-05-01 15:46         ` Matthew Wilcox
2023-05-01 16:00           ` Pankaj Raghav

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=20230424054926.26927-1-hch@lst.de \
    --to=hch@lst.de \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=ceph-devel@vger.kernel.org \
    --cc=cluster-devel@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).