[已解决]"系统盘"应该多大?

darrenlee

Post by RichardGv;2160861
80G给 / 太多了，wine会将模拟的Windows程序装在/home/里，因此wine对/的空间占用没有太大的影响。

/boot分区我也说过，太大了。100MB至多。

理论上说，世界上没有也绝对不会有从不丢失文件信息的文件系统。如果在磁盘写入信息时或者暂时保存于缓冲区中并未开始写入之前突然掉电，新写入的信息一定会丢失，至少部分丢失，但如果您在覆盖文件而非创建新文件，那么部分文件系统会保留旧的文件内容。从我看到的资料看，ext3的默认配置可以保证在5秒之内保存所有应写入磁盘的信息，也就是说，您至多会丢失5秒内写入的文件。出于性能考虑，ext4似乎放宽了这个限制，采用了新的一套写入策略，如果您的程序没有及时调用fsync()，您最多可能丢失一分钟左右时间内写入的内容，这使得ext4广受诟病，直到2.6.30之后的内核增加了几个patch，消除了大多数情况下ext4数据损失的风险 -- 遗憾是，只是“大多数情况下“。ext4的这一改变对性能有相当的提升，但它的安全性仍然逊于ext3一筹，鱼与熊掌，不可得兼。xfs、reiserfs等文件系统同样并未完美无缺，尽管xfs对磁盘内部的write-back cache施加了更多的控制以提高安全性。

但是，截至到现在，我没有看到关于任何主流文件系统掉电后普遍导致严重文件丢失问题的报告（<2.6.30内核的ext4除外）。正常使用时，我估计它们的非正常文件丢失（也就是说，刨除几乎无法避免的文件丢失情况）的概率可能要在十万分之一以下。平心而论，由于用户误操作导致文件损失的概率要远远高于掉电导致文件损失的概率。最危险的不是电源，而是您自己的键盘和鼠标。

我个人一直是ext3/4的用户，两年内使用ext4从未碰到掉电后非正常文件丢失的情况。当然，或许是我没有注意到。如果您对安全性要求极高，我建议您买个UPS，这是最彻底的方案。使用RAID或许也有助于安全性。如果您是一般用户，且不经常碰到掉电的情况，重视性能胜于安全风险，我的建议是ext4。当然，更保守的ext3、xfs也是不错的选择，尤其是对/boot分区来说。

另外，两个sysctl选项可以控制Linux的最大磁盘写入延迟，但注意同时它们也可能带来恐怖的性能损失：
/proc/sys/vm/dirty_expire_centisecs
/proc/sys/vm/dirty_writeback_centisecs

1个月前，我的.xmind文件出错，丢了绝大部分的图像文件。ext4分区，多次死机重启或断电重启。

xmind的.xmind文件就是个zip压缩包，在xmind里打开时会解压里面的xml和附件到eclipse的临时目录里，保存时在重新打包。丢的文件就是临时目录里绝大部分的图像文件。因为这些图像文件在死机/断电重启之前已被读到内存，没有写动作。所以我很怀疑是ext4本身的问题。(当然xmind程序写的也是有问题，临时文件和xml不能对应时应该严重提醒并告诉用户具体发生了什么并且不能保存文件才对)

我想做个实验，写程序分别比较断电文件损失情况：
C: none/fflush()/fsync()
java:none/flush()/sync()
fs:ext3,ext4,xfs,.....

现在问题是：直接kill qemu的进程能在多大程度上模拟断电？实在不想用真机。。。。。。(谁有多余的笔记本借我两台? ^_^ )

zhou3345

Post by RichardGv;2160878

xfs擅长处理大文件。对/home这类可能含有大量大文件的分区，xfs更适合。既然选了xfs，就所有分区都xfs吧，这样内核中ext4的功能就可以编译成模块（内核中的ext4支持向下兼容ext2/3），平时不必加载了。据说内核中ext2/3/4的代码很臃肿，xfs的代码很简洁。

xfs只是默认对大文件优化处理而已，也可以调整它使之对小文件进行优化。