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. BTW, Kudu requires hole punching if its using LBM which is the recommended setting because it is efficient and scalable as opposite to file block manager where hole punching is not required. -- 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 15:14:15 +0000 Gerrit-HasComments: No