public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: John Garry <john.g.garry@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>
Cc: djwong@kernel.org, Ojaswin Mujoo <ojaswin@linux.ibm.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc
Date: Thu, 08 May 2025 20:05:27 +0530	[thread overview]
Message-ID: <878qn7gogg.fsf@gmail.com> (raw)
In-Reply-To: <d031d255-b528-4870-b933-475b969aabdf@oracle.com>

John Garry <john.g.garry@oracle.com> writes:

> On 30/04/2025 06:20, Ritesh Harjani (IBM) wrote:
>> This is still an early preview (RFC v2) of multi-fsblock atomic write. Since the
>> core design of the feature looks ready, wanted to post this for some early
>> feedback. We will break this into more smaller and meaningful patches in later
>> revision. However to simplify the review of the core design changes, this
>> version is limited to just two patches. Individual patches might have more
>> details in the commit msg.
>> 
>> Note: This overall needs more careful review (other than the core design) which
>> I will be doing in parallel. However it would be helpful if one can provide any
>> feedback on the core design changes. Specially around ext4_iomap_alloc()
>> changes, ->end_io() changes and a new get block flag
>> EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS.
>
> I gave this a try and it looks ok, specifically atomic writing mixed 
> mappings.
>

Thanks John for taking a look.

> I'll try to look closer that the implementation details.

We are in the process of sending v3 (hopefully by tonight) which is an
improved version w.r.t error handling, journal credits and few other
changes. Although nothing has changed w.r.t the design aspect.

> But I do note 
> that you use blkdev_issue_zeroout() to pre-zero any unwritten range 
> which is being atomically written.

Yes, that is how internally ext4_map_blocks() with
EXT4_GET_BLOCKS_CREATE_ZERO will return us the allocated blocks. During
block allocation, on mixed mapping range, we ensure that the entire range
becomes a contiguous mapped extent before starting any data writes.
That means calling ext4_map_blocks() in a loop with
EXT4_GET_BLOCKS_CREATE_ZERO, so that it can zero out any unwritten
extents in the requested region.
I assume writing over a mixed mapping region is not a performance
critical path. 

Do you forsee any problems with the approach (since you said "But I do note...")?

-ritesh

  reply	other threads:[~2025-05-08 15:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-30  5:20 [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc Ritesh Harjani (IBM)
2025-04-30  5:20 ` [RFC v2 1/2] ext4: Add multi-fsblock atomic write support with bigalloc Ritesh Harjani (IBM)
2025-04-30  5:20 ` [RFC v2 2/2] ext4: Add support for EXT4_GET_BLOCKS_QUERY_LEAF_BLOCKS Ritesh Harjani (IBM)
2025-05-08 12:01 ` [RFC v2 0/2] ext4: Add multi-fsblock atomic write support using bigalloc John Garry
2025-05-08 14:35   ` Ritesh Harjani [this message]
2025-05-08 15:19     ` Darrick J. Wong

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=878qn7gogg.fsf@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=ojaswin@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox