When creating a PathInstanceMetadataFile (i.e. block_manager_instance file) on disk, we store the filesystem block size in it, for use by Kudu block managers later on. Since the file doesn't yet exist, we derive this block size from a stat(2) syscall on the parent directory.
Later, when we load an existing PathInstanceMetadataFile and compare the filesystem block size in it to the current filesystem's block size, we derive from a stat(2) on the PathInstanceMetadataFile itself.
This inconsistency is problematic on filesystems that advertise a different block size for directories than for files. For example, Vormetric's encrypted filesystem (secfs2) on ext4 advertises a block size of 1 in directories and a block size of 4096 in files.
We really shouldn't be considering directories at all, since to the extent that the filesystem block size matters to Kudu, it's for alignment of blocks inside files.