From: Christoph Hellwig <hch@lst.de>
To: Namjae Jeon <linkinjeon@kernel.org>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, hch@lst.de,
tytso@mit.edu, willy@infradead.org, jack@suse.cz,
djwong@kernel.org, josef@toxicpanda.com, sandeen@sandeen.net,
rgoldwyn@suse.com, xiang@kernel.org, dsterba@suse.com,
pali@kernel.org, ebiggers@kernel.org, neil@brown.name,
amir73il@gmail.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, iamjoonsoo.kim@lge.com,
cheol.lee@lge.com, jay.sim@lge.com, gunho.lee@lge.com,
Hyunchul Lee <hyc.lee@gmail.com>
Subject: Re: [PATCH v5 07/14] ntfs: update iomap and address space operations
Date: Fri, 16 Jan 2026 10:14:51 +0100 [thread overview]
Message-ID: <20260116091451.GA20873@lst.de> (raw)
In-Reply-To: <20260111140345.3866-8-linkinjeon@kernel.org>
First, a highlevel comment on the code structure:
I'd expect the mft handling (ntfs_write_mft_block, ntfs_mft_writepage
and ntfs_bmap which is only used by that and could use a comment
update) to be in mft.c and not aops.c. I'm not sure if feasible,
but separate aops for the MFT (that's the master file table IIRC) would
probably be a good idea as well.
Similarly, ntfs_dev_read/write feel a bit out of place here.
> +void ntfs_bio_end_io(struct bio *bio)
> {
> + if (bio->bi_private)
> + folio_put((struct folio *)bio->bi_private);
> + bio_put(bio);
> +}
This function confuses me. In general end_io handlers should not
need to drop a folio reference. For the normal buffered I/O path,
the folio is locked for reads, and has the writeback bit set for
writes, so this is no needed. When doing I/O in a private folio,
the caller usually has a reference as it needs to do something with
it. What is the reason for the special pattern here? A somewhat
more descriptive name and a comment would help to describe why
it's done this way. Also no need to cast a void pointer.
> + if (bio &&
> + (bio_end_sector(bio) >> (vol->cluster_size_bits - 9)) !=
> + lcn) {
> + flush_dcache_folio(folio);
> + bio->bi_end_io = ntfs_bio_end_io;
> + submit_bio(bio);
If the MFT is what I think it is, the flush_dcache_folio here is not
needed, as the folio can't ever be mapped into userspace.
> +static void ntfs_readahead(struct readahead_control *rac)
> +{
> + struct address_space *mapping = rac->mapping;
> + struct inode *inode = mapping->host;
> + struct ntfs_inode *ni = NTFS_I(inode);
>
> + if (!NInoNonResident(ni) || NInoCompressed(ni)) {
> + /* No readahead for resident and compressed. */
> + return;
> + }
Not supporting readahead for compressed inodes is a bit weird, as
they should benefit most from operating on larger ranges. Not really
a blocker, but probably something worth addressing over time.
> +static int ntfs_mft_writepage(struct folio *folio, struct writeback_control *wbc)
> +{
Instead of having a ntfs_mft_writepage, maybe implement a
ntfs_mft_writepages that includes the writeback_iter() loop? And then
move the folio_zero_segment into ntfs_write_mft_block so that one
intermediate layer can go away?
> +int ntfs_dev_read(struct super_block *sb, void *buf, loff_t start, loff_t size)
Do you want the data for ntfs_dev_read/write cached in the bdev
mapping? If not simply using bdev_rw_virt might be easier. If you
want them cached, maybe add a comment why.
next prev parent reply other threads:[~2026-01-16 9:14 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-11 14:03 [PATCH v5 00/14] ntfs filesystem remake Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 01/14] Revert "fs: Remove NTFS classic" Namjae Jeon
2026-01-16 8:00 ` Christoph Hellwig
2026-01-11 14:03 ` [PATCH v5 02/14] ntfs: update in-memory, on-disk structures and headers Namjae Jeon
2026-01-16 8:23 ` Christoph Hellwig
2026-01-18 4:54 ` Namjae Jeon
2026-01-19 7:05 ` Christoph Hellwig
2026-01-20 4:27 ` Namjae Jeon
2026-01-20 6:40 ` Christoph Hellwig
2026-01-20 7:03 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 03/14] ntfs: update super block operations Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 04/14] ntfs: update inode operations Namjae Jeon
2026-01-16 8:30 ` Christoph Hellwig
2026-01-18 4:54 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 05/14] ntfs: update directory operations Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 06/14] ntfs: update file operations Namjae Jeon
2026-01-16 8:53 ` Christoph Hellwig
2026-01-18 4:56 ` Namjae Jeon
2026-01-19 7:10 ` Christoph Hellwig
2026-01-20 5:11 ` Namjae Jeon
2026-01-20 6:42 ` Christoph Hellwig
2026-01-20 7:02 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 07/14] ntfs: update iomap and address space operations Namjae Jeon
2026-01-16 9:14 ` Christoph Hellwig [this message]
2026-01-18 5:00 ` Namjae Jeon
2026-01-19 7:17 ` Christoph Hellwig
2026-01-20 4:28 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 08/14] ntfs: update attrib operations Namjae Jeon
2026-01-16 9:18 ` Christoph Hellwig
2026-01-18 5:00 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 09/14] ntfs: update runlist handling and cluster allocator Namjae Jeon
2026-01-16 9:21 ` Christoph Hellwig
2026-01-18 5:00 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 10/14] ntfs: add reparse and ea operations Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 11/14] ntfs: update misc operations Namjae Jeon
2026-01-16 9:28 ` Christoph Hellwig
2026-01-18 5:00 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 12/14] ntfs3: remove legacy ntfs driver support Namjae Jeon
2026-01-16 9:28 ` Christoph Hellwig
2026-01-11 14:03 ` [PATCH v5 13/14] ntfs: add Kconfig and Makefile Namjae Jeon
2026-01-16 9:30 ` Christoph Hellwig
2026-01-18 5:08 ` Namjae Jeon
2026-01-19 7:19 ` Christoph Hellwig
2026-01-20 4:27 ` Namjae Jeon
2026-01-11 14:03 ` [PATCH v5 14/14] MAINTAINERS: update ntfs filesystem entry Namjae Jeon
2026-01-16 9:30 ` Christoph Hellwig
2026-01-16 9:33 ` [PATCH v5 00/14] ntfs filesystem remake Christoph Hellwig
2026-01-18 5:19 ` Namjae Jeon
2026-01-19 7:02 ` Christoph Hellwig
2026-01-20 4:26 ` Namjae Jeon
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=20260116091451.GA20873@lst.de \
--to=hch@lst.de \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=cheol.lee@lge.com \
--cc=djwong@kernel.org \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=gunho.lee@lge.com \
--cc=hyc.lee@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=jay.sim@lge.com \
--cc=josef@toxicpanda.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neil@brown.name \
--cc=pali@kernel.org \
--cc=rgoldwyn@suse.com \
--cc=sandeen@sandeen.net \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=xiang@kernel.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 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.