[
https://issues.apache.org/jira/browse/KUDU-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858411#comment-16858411
]
Todd Lipcon commented on KUDU-2713:
-----------------------------------
I think we could bump to 1.11. A relatively simple fix though would be to check
the reported block size during the format step, and if it reports more than 8kb
or 16kb or something we think reasonable, we could abort. Better fix would be
to use statvfs as suggested but that might take more than two lines of code :)
> FS misinterprets file block size as file system block size
> ----------------------------------------------------------
>
> Key: KUDU-2713
> URL: https://issues.apache.org/jira/browse/KUDU-2713
> Project: Kudu
> Issue Type: Bug
> Components: fs
> Reporter: Todd Lipcon
> Priority: Critical
>
> We recently saw a case where a cluster was using XFS with the 'largeio' mount
> option. This caused files on the drive to report a 4MB block size, even
> though the actual file system block size was the default 4kb. This caused the
> LBM to align all blocks up to 4MB and cause an enormous amount of wasted
> space.
> Instead of using the file's block size we should probably use statvfs() which
> reports the correct block size. Alternatively we could consider actually
> running a basic hole-punch test to determine the granularity of hole punches.
> Fixing this in a compatible way may also be a bit involved since changing the
> apparent block size of a system after the instance has been formatted will
> prevent it from starting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
