[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKYAXd-g_pq4biLmm+_-7DhZaR1EdGPx=kDxjxcYS1w3nthLSQ@mail.gmail.com>
Date: Tue, 20 Jan 2026 16:02:41 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, tytso@....edu,
willy@...radead.org, jack@...e.cz, djwong@...nel.org, josef@...icpanda.com,
sandeen@...deen.net, rgoldwyn@...e.com, xiang@...nel.org, dsterba@...e.com,
pali@...nel.org, ebiggers@...nel.org, neil@...wn.name, amir73il@...il.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
iamjoonsoo.kim@....com, cheol.lee@....com, jay.sim@....com, gunho.lee@....com,
Hyunchul Lee <hyc.lee@...il.com>
Subject: Re: [PATCH v5 06/14] ntfs: update file operations
On Tue, Jan 20, 2026 at 3:42 PM Christoph Hellwig <hch@....de> wrote:
>
> On Tue, Jan 20, 2026 at 02:11:24PM +0900, Namjae Jeon wrote:
> > By modifying iomap_begin, it seems possible to implement it using
> > iomap_seek_hole/data without introducing a new IOMAP_xxx type.
>
> Note that you can also use different iomap ops for different operations
> if needed.
Okay.
>
> > Since NTFS does not support multiple unwritten extents, all
> > pre-allocated regions must, in principle, be treated as DATA, not
> > HOLE. However, in the current implementation, region #2 is mapped as
> > IOMAP_UNWRITTEN, so iomap_seek_data incorrectly interprets this region
> > as a hole. It would be better to map region #2 as IOMAP_MAPPED for the
> > seek operation.
>
> So basically it optimizes for the case of appending on the end.
>
> Can you add the above to a code comment where you set IOMAP_UNWRITTEN?
I will do that. Thank you for the review!
>
Powered by blists - more mailing lists