On Sun, Jan 17, 2021 at 11:06:24PM +0800, Eryu Guan wrote:
> On Thu, Jan 14, 2021 at 11:55:03AM +0800, Yang Xu wrote:
> > When testing arm machine, this case fails because ps > bs and kernel doesn't
> > introduced commit c8cc88163f40 ("ext4: Add support for blocksize < pagesize in dioread_nolock").
> > Only skip this case when mounting failed.
>
> Perhaps it's the kernel that should be fixed? i.e. backport the
> mentioned patch? Depends on if we treat it as a bug or a feature I
> think..
The dioread_nolock was introduced about ten years, and originally it
was an optimization that only worked when page size == block size. A
little over a year ago (October 2019, in v5.5) this was relaxed so
that the dioread_nolock mount option would be accepted when the block
size < page size.
ARM's page size can be 4k, 64k, or 1MB. At least on most ARM platform
that I've worked with (which are mobile handsets, admittedly) then
page size is 4k, and the default block size for ext4 file systems
created by ext4 is 4k. You *can* ask mke2fs to create a 64k block
size, and in theory it should work, but I don't have access to any
platforms with 64k block sizes, so 64k support has a tendency to
regress. We did fix some issues the last time someone tried to use an
ext4 file system with a 64k block sizes on an Itanium system, but that
was a couple of years ago.
As far as backporting dioread_nolock support to older kernels, it
requires a large restructuring of ext4 code to support it. It's not
something that won't be acceptable for upstream LTS kernels. I'm
assuming the issue here is that Fujitsu is trying to use some RHEL or
SLES kernel on a server-class ARM system with a 64k page size?
> At least we should check if it's really the bs < ps case before _notrun
> the test, otherwise we may fail to find dioread_nolock mount regression.
I'd tend to agree, but at least for ext4 upstream development, I run
the the full set of -g auto tests with dioread_nolock. So if there a
dioread_nolock mount regression, I'd certainly notice.
- Ted
