All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Mingming Cao <cmm@us.ibm.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	ocfs2-devel@oss.oracle.com, linux-mm@kvack.org
Subject: generic_writepages & jbd2 and ext4
Date: Wed, 16 Nov 2022 14:50:16 +0100	[thread overview]
Message-ID: <20221116135016.GA9713@lst.de> (raw)

Hi all,

I've recently started looking into killing off the ->writepage method,
and as an initial subproject kill of external uses of generic_writepages.
One of the two remaining callers s in jbd2 and I'm a bit confused about
it.

jbd2_journal_submit_inode_data_buffers has two comments that explicitly
ask for ->writepages as that doesn't allocate data:

/*
 * write the filemap data using writepage() address_space_operations.
 * We don't do block allocation here even for delalloc. We don't
 * use writepages() because with delayed allocation we may be doing
 * block allocation in writepages().
 */

	/*
         * submit the inode data buffers. We use writepage
	 * instead of writepages. Because writepages can do
	 * block allocation with delalloc. We need to write
	 * only allocated blocks here.
	 */

and these look really stange to me.  ->writepage and ->writepages per
their document VM/VFS semantics don't different on what they allocate,
so this seems to reverse engineer ext4 internal behavior in some
way.  Either way looping over ->writepage just for that is rather
inefficient.  If jbd2 really wants a way to skip delalloc conversion
can we come up with a flag in struct writeback_control for that?

Is there anyone familiar enough with this code who would be willing
to give it a try?

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
To: Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Mingming Cao <cmm@us.ibm.com>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-ext4@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] generic_writepages & jbd2 and ext4
Date: Wed, 16 Nov 2022 14:50:16 +0100	[thread overview]
Message-ID: <20221116135016.GA9713@lst.de> (raw)

Hi all,

I've recently started looking into killing off the ->writepage method,
and as an initial subproject kill of external uses of generic_writepages.
One of the two remaining callers s in jbd2 and I'm a bit confused about
it.

jbd2_journal_submit_inode_data_buffers has two comments that explicitly
ask for ->writepages as that doesn't allocate data:

/*
 * write the filemap data using writepage() address_space_operations.
 * We don't do block allocation here even for delalloc. We don't
 * use writepages() because with delayed allocation we may be doing
 * block allocation in writepages().
 */

	/*
         * submit the inode data buffers. We use writepage
	 * instead of writepages. Because writepages can do
	 * block allocation with delalloc. We need to write
	 * only allocated blocks here.
	 */

and these look really stange to me.  ->writepage and ->writepages per
their document VM/VFS semantics don't different on what they allocate,
so this seems to reverse engineer ext4 internal behavior in some
way.  Either way looping over ->writepage just for that is rather
inefficient.  If jbd2 really wants a way to skip delalloc conversion
can we come up with a flag in struct writeback_control for that?

Is there anyone familiar enough with this code who would be willing
to give it a try?

_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

             reply	other threads:[~2022-11-16 13:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 13:50 Christoph Hellwig [this message]
2022-11-16 13:50 ` [Ocfs2-devel] generic_writepages & jbd2 and ext4 Christoph Hellwig via Ocfs2-devel
2022-11-16 15:36 ` Jan Kara
2022-11-16 15:36   ` [Ocfs2-devel] " Jan Kara via Ocfs2-devel

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=20221116135016.GA9713@lst.de \
    --to=hch@lst.de \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.ibm.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=tytso@mit.edu \
    /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.