cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] erofs: convert to use i_blockmask()
Date: Fri, 10 Mar 2023 04:05:08 +0000	[thread overview]
Message-ID: <20230310040508.GN3390869@ZenIV> (raw)
In-Reply-To: <20230310035121.56591-1-frank.li@vivo.com>

On Fri, Mar 10, 2023 at 11:51:21AM +0800, Yangtao Li wrote:
> Hi AI,
> 
> > Umm...  What's the branchpoint for that series?
> > Not the mainline - there we have i_blocksize() open-coded...
> 
> Sorry, I'm based on the latest branch of the erofs repository.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git/log/?h=dev-test
> 
> I think I can resend based on mainline.
> 
> > Umm...  That actually asks for DIV_ROUND_UP(i_size_read_inode(), i_blocksize(inode))
> > - compiler should bloody well be able to figure out that division by (1 << n)
> > is shift down by n and it's easier to follow that way...
> 
> So it seems better to change to DIV_ROUND_UP(i_size_read_inode(), i_blocksize(inode))?
> 
> > And the fact that the value will be the same (i.e. that ->i_blkbits is never changed by ocfs2)
> > is worth mentioning in commit message...
> 
> How about the following msg?
> 
> Use i_blockmask() to simplify code. BTW convert ocfs2_is_io_unaligned
> to return bool type and the fact that the value will be the same
> (i.e. that ->i_blkbits is never changed by ocfs2).
> 
> 
> 
> A small question, whether this series of changes will be merged
> into each fs branch or all merged into vfs?

Depends.  The thing to avoid is conflicts between the trees and
convoluted commit graph.

In cases like that the usual approach is
	* put the helper into never-rebased branch - in vfs tree, in this
case; I've no real objections against the helper in question.
	* let other trees convert to the helper at leisure - merging
that never-rebased branch from vfs.git before they use the helper, of
course.  Or wait until the next cycle, for that matter...

I can pick the stuff in the areas that don't have active development,
but doing that for e.g. ext4 won't help anybody - it would only cause
headache for everyone involved down the road.  And I'd expect the gfs2
to be in the same situation...


  reply	other threads:[~2023-03-10  4:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09 15:21 [Cluster-devel] [PATCH v3 1/6] fs: add i_blockmask() Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] [PATCH v3 2/6] erofs: convert to use i_blockmask() Yangtao Li
2023-03-10  3:15   ` Al Viro
2023-03-10  3:42     ` Gao Xiang
2023-03-10  3:47       ` Gao Xiang
2023-03-10  3:51     ` [Cluster-devel] " Yangtao Li
2023-03-10  4:05       ` Al Viro [this message]
2023-03-10  6:50         ` Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] [PATCH v3 3/6] gfs2: " Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] [PATCH v3 4/6] ext4: " Yangtao Li
2023-03-10  3:19   ` Al Viro
2023-03-10  3:32     ` Al Viro
2023-03-09 15:21 ` [Cluster-devel] [PATCH v3 5/6] ocfs2: " Yangtao Li
2023-03-10  3:26   ` Al Viro
2023-03-09 15:21 ` [Cluster-devel] [PATCH v3 6/6] fs/remap_range: " Yangtao Li

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=20230310040508.GN3390869@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    /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).