From: Yangtao Li <frank.li@vivo.com>
To: xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com,
jefflexu@linux.alibaba.com, tytso@mit.edu,
adilger.kernel@dilger.ca, rpeterso@redhat.com,
agruenba@redhat.com, mark@fasheh.com, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, viro@zeniv.linux.org.uk,
brauner@kernel.org
Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-ext4@vger.kernel.org, cluster-devel@redhat.com,
ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org
Subject: Re: erofs: convert to use i_blockmask()
Date: Fri, 10 Mar 2023 11:51:21 +0800 [thread overview]
Message-ID: <20230310035121.56591-1-frank.li@vivo.com> (raw)
In-Reply-To: <20230310031547.GD3390869@ZenIV>
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?
Thx,
Yangtao
WARNING: multiple messages have this Message-ID (diff)
From: Yangtao Li <frank.li@vivo.com>
To: xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com,
jefflexu@linux.alibaba.com, tytso@mit.edu,
adilger.kernel@dilger.ca, rpeterso@redhat.com,
agruenba@redhat.com, mark@fasheh.com, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, viro@zeniv.linux.org.uk,
brauner@kernel.org
Cc: linux-kernel@vger.kernel.org, cluster-devel@redhat.com,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com
Subject: Re: erofs: convert to use i_blockmask()
Date: Fri, 10 Mar 2023 11:51:21 +0800 [thread overview]
Message-ID: <20230310035121.56591-1-frank.li@vivo.com> (raw)
In-Reply-To: <20230310031547.GD3390869@ZenIV>
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?
Thx,
Yangtao
WARNING: multiple messages have this Message-ID (diff)
From: Yangtao Li via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
To: xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com,
jefflexu@linux.alibaba.com, tytso@mit.edu,
adilger.kernel@dilger.ca, rpeterso@redhat.com,
agruenba@redhat.com, mark@fasheh.com, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, viro@zeniv.linux.org.uk,
brauner@kernel.org
Cc: linux-kernel@vger.kernel.org, cluster-devel@redhat.com,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] erofs: convert to use i_blockmask()
Date: Fri, 10 Mar 2023 11:51:21 +0800 [thread overview]
Message-ID: <20230310035121.56591-1-frank.li@vivo.com> (raw)
In-Reply-To: <20230310031547.GD3390869@ZenIV>
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?
Thx,
Yangtao
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
WARNING: multiple messages have this Message-ID (diff)
From: Yangtao Li <frank.li@vivo.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] erofs: convert to use i_blockmask()
Date: Fri, 10 Mar 2023 11:51:21 +0800 [thread overview]
Message-ID: <20230310035121.56591-1-frank.li@vivo.com> (raw)
In-Reply-To: <20230310031547.GD3390869@ZenIV>
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?
Thx,
Yangtao
next prev parent reply other threads:[~2023-03-10 3:52 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 15:21 [PATCH v3 1/6] fs: add i_blockmask() Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] " Yangtao Li
2023-03-09 15:21 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-09 15:21 ` Yangtao Li
2023-03-09 15:21 ` [PATCH v3 2/6] erofs: convert to use i_blockmask() Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] " Yangtao Li
2023-03-09 15:21 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-09 15:21 ` Yangtao Li
2023-03-10 3:15 ` Al Viro
2023-03-10 3:15 ` [Cluster-devel] " Al Viro
2023-03-10 3:15 ` Al Viro
2023-03-10 3:15 ` [Ocfs2-devel] " Al Viro via Ocfs2-devel
2023-03-10 3:42 ` Gao Xiang
2023-03-10 3:42 ` [Cluster-devel] " Gao Xiang
2023-03-10 3:42 ` [Ocfs2-devel] " Gao Xiang via Ocfs2-devel
2023-03-10 3:42 ` Gao Xiang
2023-03-10 3:47 ` Gao Xiang
2023-03-10 3:47 ` [Cluster-devel] " Gao Xiang
2023-03-10 3:47 ` [Ocfs2-devel] " Gao Xiang via Ocfs2-devel
2023-03-10 3:47 ` Gao Xiang
2023-03-10 3:51 ` Yangtao Li [this message]
2023-03-10 3:51 ` [Cluster-devel] " Yangtao Li
2023-03-10 3:51 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-10 3:51 ` Yangtao Li
2023-03-10 4:05 ` Al Viro
2023-03-10 4:05 ` [Cluster-devel] " Al Viro
2023-03-10 4:05 ` Al Viro
2023-03-10 4:05 ` [Ocfs2-devel] " Al Viro via Ocfs2-devel
2023-03-10 6:50 ` Yangtao Li
2023-03-10 6:50 ` [Cluster-devel] " Yangtao Li
2023-03-10 6:50 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-10 6:50 ` Yangtao Li
2023-03-09 15:21 ` [PATCH v3 3/6] gfs2: " Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] " Yangtao Li
2023-03-09 15:21 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-09 15:21 ` Yangtao Li
2023-03-09 15:21 ` [PATCH v3 4/6] ext4: " Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] " Yangtao Li
2023-03-09 15:21 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-09 15:21 ` Yangtao Li
2023-03-10 3:19 ` Al Viro
2023-03-10 3:19 ` [Cluster-devel] " Al Viro
2023-03-10 3:19 ` Al Viro
2023-03-10 3:19 ` [Ocfs2-devel] " Al Viro via Ocfs2-devel
2023-03-10 3:32 ` Al Viro
2023-03-10 3:32 ` [Cluster-devel] " Al Viro
2023-03-10 3:32 ` Al Viro
2023-03-10 3:32 ` [Ocfs2-devel] " Al Viro via Ocfs2-devel
2023-03-09 15:21 ` [PATCH v3 5/6] ocfs2: " Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] " Yangtao Li
2023-03-09 15:21 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-09 15:21 ` Yangtao Li
2023-03-10 3:26 ` Al Viro
2023-03-10 3:26 ` [Cluster-devel] " Al Viro
2023-03-10 3:26 ` Al Viro
2023-03-10 3:26 ` [Ocfs2-devel] " Al Viro via Ocfs2-devel
2023-03-09 15:21 ` [PATCH v3 6/6] fs/remap_range: " Yangtao Li
2023-03-09 15:21 ` [Cluster-devel] " Yangtao Li
2023-03-09 15:21 ` [Ocfs2-devel] " Yangtao Li via Ocfs2-devel
2023-03-09 15:21 ` 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=20230310035121.56591-1-frank.li@vivo.com \
--to=frank.li@vivo.com \
--cc=adilger.kernel@dilger.ca \
--cc=agruenba@redhat.com \
--cc=brauner@kernel.org \
--cc=chao@kernel.org \
--cc=cluster-devel@redhat.com \
--cc=huyue2@coolpad.com \
--cc=jefflexu@linux.alibaba.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=rpeterso@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--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.