- 主题:请教一个ofstream的flush问题
你需要换文件系统，低成本的话，考虑一下zfs
【 在 hongyan2022 的大作中提到: 】
: 掉数据这问题挺讨厌的。
:
--
FROM 122.234.10.*
zfs是唯一的，最终的文件系统
你这个问题不是你写程序的问题，是文件系统的问题，就好像你不可能直接操作cpu内部操作一样。如果真的是对原子性和数据完整性有要求的，要么上高端硬件，要么换zfs
如果对硬件有顾虑，热备是不够的，构架需要设计成双活
【 在 hongyan2022 的大作中提到: 】
: 在用ext4. 搜了一下zfs，好象评价不错。 性能好吗，维护比较麻烦吗？
: 个人的盘丢数据，我不在乎。 生产系统里，我们有大量的写和读。如果能提升硬盘性能，还有很有影响的。
:
--
修改:ziqin FROM 122.234.10.*
FROM 122.234.10.*
那就在文件系统上下功夫，zfs, mirror raid
【 在 hongyan2022 的大作中提到: 】
: 双活的成本太高了，也许金融银行之类的，撑的住。
: 我们也就是KAFKA 里存数据，定时备份，有事了重放数据。估计很多公司也是这么做。
:
--
FROM 115.199.107.*
多加内存，zfs用物理内存做一级读写缓存，还可以配置nvme的ssd做二级读写缓存。
如果是大量同时的随机读写，zfs应该是最合适的文件系统了。
另外，用zfs的话，尽量不要用硬件raid卡，让zfs直接管理硬盘，上raid z，或者raid z2，或者raid z+镜像。
【 在 hongyan2022 的大作中提到: 】
: 你们如果调不快，估计我也调不好
: 这都要看fs的内功了，咱们调一调，也就是帮一帮，顶多是锦上添花，不可能无中生有。
: 我们的场景是大量同时的随机读写，持续时间也比较长。
: ...................
--
FROM 115.199.107.*
file close以后，另一个读不到文件？
感觉是你程序的bug，和文件系统无关。
【 在 fishingriver 的大作中提到: 】
: 谢谢大家，问题还没解决，请再支支招。
: 我现在的问题是这样的：
: （1）我的程序里会产生数据，然后把数据以文本文件的方式写到硬盘上，然后我通知另一个人的程序，把数据读走。
: ...................
--
FROM 115.199.110.*
讲真，这个水平，你们公司是认真的嘛？
文件系统的内部操作对使用者是透明的，这是基本原则，如果一个process close的句柄，另外一个process不能打开的话，要么是你的程序出错了，要么是你用的文件系统的API有问题，可能是异步api之类，这种情况你需要去读文件系统api的文档。但是总之，和文件系统没有关系
【 在 fishingriver 的大作中提到: 】
: 多谢回复，这样的话，就是说只要我写完，他就可以读了。
: 我之前没把我的应用讲清楚，是这样的：
: （1）对方并不在本地开打和读写我的文件，他会用把我写好的文件传到服务器上。这种情况，是不是我也可以在我close之后，立刻通知他，他就可以立刻上传了？
: ...................
--
FROM 115.199.99.*