Ashwani Raina has posted comments on this change. (
http://gerrit.cloudera.org:8080/20680 )
Change subject: KUDU-3523 Use f_bsize as Kudu block size instead of st_blksize
......................................................................
Patch Set 4:
> > The reason behind 64K block size on XFS could be because the
> > filesystem was created with "-b size=64K" mkfs option. Could you
> > confirm that?
> >
> > Also, in such cases, even though user is able to create a
> > filesystem with block size greater than general page size on
> linux
> > i.e. 4K, default mount API may not work because kernel is
> compiled
> > with 4K default page size and it doesn't allow a filesystem with
> > more than 4K block size to be mounted.
> > This could be one of the possibilities.
> >
> > Could you please share the following information:
> > 1. Output of command -> "getconf PAGE_SIZE" on the node where
> xfs
> > filesystem is hosted
> > 2. mkfs command used to create xfs filesystem (i.e. /dev/vdb)
> > 3. Check if punch hole is supported on a filesystem with block
> size
> > more than 4K.
>
> Ashwani,
> You can easily set up the environment, just use the
> cloudera-systest-base-rhel-8.8-hvm-arm-grp image (Virginia/public)
> in cloudcat.
> This will run a 64k rhel kernel on a filesystem created by "-b
> size=4k".
> (on public aws I can only select 4k kernel for arm rhel, so it is
> trickier there).
> Use "grep -ir pagesize /proc/self/smaps" to check kernel size.
>
> There is the following 4 combinations:
>
> Case1. 4k kernel with "-b size=4k" disk: Kudu works fine.
>
> Case2. 64k kernel with "-b size=4k" disk: This is the case that
> Wang Xixu is trying to fix. To my best understanding kudu kind of
> works without encryption (maybe does not preallocated properly, or
> there are other hidden issues, but I could start a server and use
> it). Kudu breaks with encryption.
>
> Case3. 64k kernel with "-b size=64k" disk: Status CheckHolePunch(…)”
> in dir_util.cc fails. Kudu is absolutely broken.
>
> Case4. 4k kernel with "-b size=64k": system refuses to mount the
> disk (mount(2) system call failed: Function not implemented.).
>
> Do we need to support 64k kernel? I guess we have to. But then do
> we also want to support Case3 (it would be logical)?
Case 4 is simply not supported from filesystem itself for good reasons. So, we
don't need to worry about that.
Case 3: We need to find out what is failing there. If it is underlying fs that
is throwing error, we may not be able to fix it.
If it is Kudu, we can look into it. It is likely that this is a
straightforward fix.
Case 2: Does Kudu with encryption break due to the same issue being fixed here
by Wang Xixu or you hit some other error?
To answer your question about supporting 64K kernel, I guess that would depend
on whether following conditions are met:
1. Filesystems (ext4, xfs, etc) that Kudu uses, support hole punching
irrespective of whether block size is 4K or 64K.
2. Filesystems (ext4, xfs, etc) that Kudu uses, support mount operation with
different mount flags.
3. Filesystems (ext4, xfs, etc) that Kudu uses, support different block sizes
on 64K kernel.
In a nutshell, Kudu most likely doesn't need to do anything to support 64K
kernel other than ensuring there is no restriction in code to disallow
configuration with 64K page sized kernel.
--
To view, visit http://gerrit.cloudera.org:8080/20680
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I04343caf5fe377a4fa9b57e6e450307e6b995928
Gerrit-Change-Number: 20680
Gerrit-PatchSet: 4
Gerrit-Owner: Wang Xixu <1450306...@qq.com>
Gerrit-Reviewer: Alexey Serbin <ale...@apache.org>
Gerrit-Reviewer: Ashwani Raina <ara...@cloudera.com>
Gerrit-Reviewer: Attila Bukor <abu...@apache.org>
Gerrit-Reviewer: Kudu Jenkins (120)
Gerrit-Reviewer: Wang Xixu <1450306...@qq.com>
Gerrit-Reviewer: Yifan Zhang <chinazhangyi...@163.com>
Gerrit-Reviewer: Yingchun Lai <laiyingc...@apache.org>
Gerrit-Reviewer: Zoltan Martonka <zmarto...@cloudera.com>
Gerrit-Comment-Date: Thu, 14 Dec 2023 14:33:37 +0000
Gerrit-HasComments: No
