我的理解是 linux及其文件系统会将文件“砍掉”成4KB的块大小,这些块大小将被传递给块设备驱动程序,这需要用来从设备中物理填充块(例如,用于写入)
我也知道内核页面大小在此限制中起作用,因为它设置为4KB.
对于实验,我想知道是否有办法实际增加这个块大小,这样我们将节省一些时间(而不是多次4KB写入,我们可以用更大的块大小来做).
有没有FS或任何现有的项目我可以看看这个？
如果没有,那么做这个实验需要什么 – 需要修改linux的哪些部分？
试图找出所需的困难和资源水平.或者,如果甚至不可能这样做和/或我们甚至不需要这样做的任何原因.任何评论表示赞赏.
谢谢.
解决方法
另外,让我们假设系统存在巨大的内存压力,我们需要写出最后一页;如果没有足够的内存可用于实例化32k块的其他28k,那么我们可以执行读 – 修改 – 写周期只是为了在偏移20000处更新那个脏的4k页？
这些问题都可以解决,但需要在VM层进行大量手术. VM层需要知道对于这个文件系统,页面需要一次以8个页面的块进行实例化,如果有内存压力推出特定页面,则需要写出所有8个页面同时如果它是脏的,然后同时从页面缓存中删除所有8个页面.所有这些都意味着您希望跟踪页面使用情况和页面脏污,而不是在4k页面级别,而是在复合32k页面/“块”级别.它基本上将涉及对VM子系统的几乎每个部分的更改,从页面清理器到页面错误处理程序,页面扫描程序,写回算法等等等.
还要考虑一下,即使你雇用一个Linux VM专家来完成这项工作(硬盘供应商会非常喜欢你,因为他们也希望能够部署具有32k或64k物理扇区大小的HDD),它将会在这样一个经过修改的VM层出现在Red Hat Enterprise Linux内核或SuSE或Ubuntu的等效企业或LTS内核之前5到7年.因此,如果您正在一家希望将您的SSD产品销售到企业市场的初创公司工作 – 您现在也可以放弃这种方法.在资金耗尽之前,它不会起作用.
现在,如果您正在为一家正在制作自己的硬件(如Facebook,亚马逊,谷歌等)的大型云公司工作,也许您可以走这条特定的道路,因为他们不使用添加新的企业内核以冰川的速度运行 – 但出于这个原因,他们希望相对靠近上游内核,以最大限度地降低维护成本.
如果您为这些大型云计算公司之一工作,我强烈建议您联系同一领域的其他公司,也许您可以与他们合作,看看您是否可以一起完成这种开发工作尝试在上游进行这种改变.实际上,这确实不是一个微不足道的变化 – 特别是因为上游Linux内核开发人员会要求这不会对常见情况下的性能产生负面影响,而不会涉及> 4k块设备在不久的将来的任何时间.如果你在Facebook,谷歌,亚马逊等地工作,这不是你想要作为内核的私人改变而维护的那种改变,而是你想要上游的东西,因为其他方面它将是一个巨大的,侵略性的变化,支持它作为一个树外补丁将是一个巨大的头痛.