linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Zhang Yi <yi.zhang@huawei.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: fix FS_IOC_GETFSMAP handling
Date: Fri, 25 Oct 2024 11:42:13 -0400	[thread overview]
Message-ID: <20241025154213.GD3307207@mit.edu> (raw)
In-Reply-To: <cf776ce1-596f-4b04-a79b-2fe7b5b83f6e@huawei.com>

On Fri, Oct 25, 2024 at 03:06:07PM +0800, Zhang Yi wrote:
> 
> Now it seems to be able to handle all the necessary metadata in the
> query range here, can we remove the processing of info->gfi_meta_list
> in ext4_getfsmap_datadev_helper() as well?

Not without further code refactoring; we still need it if there are
metadata blocks in the middle of the block group.  My main emphasis
was keeping the code changes as simple so it would be easy to
backport, and so I didn't do further optimizations.

As a related observation, I'm not entirely sure the current set of
abstractions, where we pass exactly one set of helper/callback
functions down through multiple functions is the best match for ext4.
It should be possible to significantly simplify the call stack by
reworking the GETFSMAP support.

On the other hand, the current, more complicated design might be
useful if at some point in the future, we were to add support for
reverse mapping for online fsck and/or if we add reflink support.
(See how Darrick implemented GETFSMAP for xfs.)

     	 	 	     	      	  - Ted

  reply	other threads:[~2024-10-25 15:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-23 13:59 [PATCH] ext4: fix FS_IOC_GETFSMAP handling Theodore Ts'o
2024-10-25  7:06 ` Zhang Yi
2024-10-25 15:42   ` Theodore Ts'o [this message]
2024-10-28  1:47     ` Zhang Yi
2024-10-28  3:59       ` Theodore Ts'o
2024-10-29  2:20         ` Zhang Yi

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=20241025154213.GD3307207@mit.edu \
    --to=tytso@mit.edu \
    --cc=djwong@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=yi.zhang@huawei.com \
    /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).