- 主题:请教一个ofstream的flush问题
zfs是唯一的，最终的文件系统
你这个问题不是你写程序的问题，是文件系统的问题，就好像你不可能直接操作cpu内部操作一样。如果真的是对原子性和数据完整性有要求的，要么上高端硬件，要么换zfs
如果对硬件有顾虑，热备是不够的，构架需要设计成双活
【 在 hongyan2022 的大作中提到: 】
: 在用ext4. 搜了一下zfs，好象评价不错。 性能好吗，维护比较麻烦吗？
: 个人的盘丢数据，我不在乎。 生产系统里，我们有大量的写和读。如果能提升硬盘性能，还有很有影响的。
:
--
修改:ziqin FROM 122.234.10.*
FROM 122.234.10.*
双活的成本太高了，也许金融银行之类的，撑的住。
我们也就是KAFKA 里存数据，定时备份，有事了重放数据。估计很多公司也是这么做。
【 在 ziqin 的大作中提到: 】
: 如果对硬件有顾虑，热备是不够的，构架需要设计成双活
: ...................
--
FROM 47.144.148.*
那就在文件系统上下功夫，zfs, mirror raid
【 在 hongyan2022 的大作中提到: 】
: 双活的成本太高了，也许金融银行之类的，撑的住。
: 我们也就是KAFKA 里存数据，定时备份，有事了重放数据。估计很多公司也是这么做。
:
--
FROM 115.199.107.*
raid 1 啊？互联网企业付不起。
【 在 ziqin 的大作中提到: 】
: 那就在文件系统上下功夫，zfs, mirror raid
:
--
FROM 47.144.148.*
性能不是很满意，也许是我们水平不行调的不好。
数据安全性很满意，经过了N次坏盘，目前都处理好了
【 在 hongyan2022 (hongyan2022) 的大作中提到: 】
: 在用ext4. 搜了一下zfs，好象评价不错。 性能好吗，维护比较麻烦吗？
: 个人的盘丢数据，我不在乎。 生产系统里，我们有大量的写和读。如果能提升硬盘性能，还有很有影响的。
--
FROM 219.238.250.*
你们如果调不快，估计我也调不好
这都要看fs的内功了，咱们调一调，也就是帮一帮，顶多是锦上添花，不可能无中生有。
我们的场景是大量同时的随机读写，持续时间也比较长。
【 在 mountainlion 的大作中提到: 】
: 性能不是很满意，也许是我们水平不行调的不好。
: 数据安全性很满意，经过了N次坏盘，目前都处理好了
:
--
FROM 47.144.148.*
多加内存，zfs用物理内存做一级读写缓存，还可以配置nvme的ssd做二级读写缓存。
如果是大量同时的随机读写，zfs应该是最合适的文件系统了。
另外，用zfs的话，尽量不要用硬件raid卡，让zfs直接管理硬盘，上raid z，或者raid z2，或者raid z+镜像。
【 在 hongyan2022 的大作中提到: 】
: 你们如果调不快，估计我也调不好
: 这都要看fs的内功了，咱们调一调，也就是帮一帮，顶多是锦上添花，不可能无中生有。
: 我们的场景是大量同时的随机读写，持续时间也比较长。
: ...................
--
FROM 115.199.107.*
用direct IO
--
FROM 106.11.41.*
前一段时间的遇到一个bug。。。之前以为是win11的问题，有可能是这个问题。。
【 在 fishingriver 的大作中提到: 】
: 我发现ofstream写文本时，即使加上flush，也不会立刻把数据写到文本文件里
: 文件close都执行完一段时间了，数据才会写完。
: 如果我想close返回时就写完，应该怎么做呢？
: ...................
--
FROM 39.88.13.*
谢谢大家，问题还没解决，请再支支招。
我现在的问题是这样的：
（1）我的程序里会产生数据，然后把数据以文本文件的方式写到硬盘上，然后我通知另一个人的程序，把数据读走。
数据量不确定，1G左右或更多。
现在的问题是，我的程序已经写完数据了,ofstream 已经执行完flush和close了，但文件还没写完。所以我现在不知道什么时候通知对方来读数据。
（2）我换一个方式去写这个本文文件，会不会写的更快，能不能解决掉这个close完还没写完的问题？
【 在 fishingriver 的大作中提到: 】
: 我发现ofstream写文本时，即使加上flush，也不会立刻把数据写到文本文件里
: 文件close都执行完一段时间了，数据才会写完。
: 如果我想close返回时就写完，应该怎么做呢？
: ...................
--
FROM 223.104.41.*