关于Linux struct super_block块大小成员类型设置合理性的疑问

首先纠正一个误解：文件系统块大小的字节数（比如512、4096）远大于对应的位数（9、12），不存在“位数的数值大于字节数”的情况。不过即便忽略这个表述问题，将两个成员的类型反过来设置也是完全不合理的，原因涉及内存布局、语义匹配、内核惯例和兼容性多个层面：

原结构体相关定义：

struct super_block {
    struct list_head    s_list;        /* Keep this first */
    dev_t            s_dev;        /* search index; _not_ kdev_t */
    unsigned char        s_blocksize_bits;
    unsigned long        s_blocksize;
    ...
};

• 内存对齐与空间效率
  结构体成员的类型顺序会影响内存填充。当前布局是先占1字节的unsigned char s_blocksize_bits，再占4/8字节的unsigned long s_blocksize，编译器会自动补充对齐字节以满足unsigned long的对齐要求。如果反过来先放unsigned long再放unsigned char，同样会产生对齐填充，空间上没有任何优势，甚至在某些场景下会导致结构体整体对齐逻辑更复杂。

• 类型语义与取值范围匹配
  内核中文件系统的块大小几乎都是2的幂，s_blocksize_bits是块大小的对数（比如4096字节对应12位），其取值范围通常在9（512字节）到16（64KB）之间，unsigned char（0-255）的范围完全足够容纳，根本不需要更大的类型。而s_blocksize是实际字节数，虽然最大64KB用unsigned int也能装，但内核中习惯用unsigned long表示内存大小类的数值，和其他API的参数类型保持一致，避免类型转换带来的潜在问题。

• 内核代码的实际使用逻辑
  内核中通常是先确定blocksize_bits，再通过s_blocksize = 1 << s_blocksize_bits计算出实际块大小，而不是反过来推导。这种计算逻辑下，s_blocksize_bits作为小整数用unsigned char存储完全合理，反而是用大类型存储会显得冗余。

• 历史兼容性与ABI稳定性
  Linux内核的结构体布局是长期稳定的ABI（应用二进制接口）的一部分，随便修改成员类型会导致依赖struct super_block的内核模块、第三方驱动无法正常工作，这是内核开发中绝对禁止的操作——兼容性优先于“看起来合理”的主观判断。

内容的提问来源于stack exchange，提问作者roeegg