Comment by colanderman 4 years ago OS crashes do not cause acknowledged writes to be lost. They are already in the drive's queue. 4 comments colanderman Reply dathinab 4 years ago They do if you don't use F_FULLSYNC, even apple acknowledges it (quote apple man pages):> Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written.It's also worse then just write losses:> The disk drive may also re-order the data so that later writes may be present, while earlier writes are not. colanderman 4 years ago I'm using "acknowledged" in the sense of SCSI-level flush (per the thread OP), not mac OS's peculiar implementation of fsync. dathinab 4 years ago But the thread OS is about it not being a problem that SCSI-level flushes are supper slow, which is only not a problem if you don't do them (e.g. only use fsync on Mac)?But reading it again there might have been some confusion about what was meant. marcan_42 4 years ago macOS does issue an NVMe flush on standard kernel panics, although of course it's possible to have it die in a way where that doesn't work.
dathinab 4 years ago They do if you don't use F_FULLSYNC, even apple acknowledges it (quote apple man pages):> Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written.It's also worse then just write losses:> The disk drive may also re-order the data so that later writes may be present, while earlier writes are not. colanderman 4 years ago I'm using "acknowledged" in the sense of SCSI-level flush (per the thread OP), not mac OS's peculiar implementation of fsync. dathinab 4 years ago But the thread OS is about it not being a problem that SCSI-level flushes are supper slow, which is only not a problem if you don't do them (e.g. only use fsync on Mac)?But reading it again there might have been some confusion about what was meant. marcan_42 4 years ago macOS does issue an NVMe flush on standard kernel panics, although of course it's possible to have it die in a way where that doesn't work.
colanderman 4 years ago I'm using "acknowledged" in the sense of SCSI-level flush (per the thread OP), not mac OS's peculiar implementation of fsync. dathinab 4 years ago But the thread OS is about it not being a problem that SCSI-level flushes are supper slow, which is only not a problem if you don't do them (e.g. only use fsync on Mac)?But reading it again there might have been some confusion about what was meant.
dathinab 4 years ago But the thread OS is about it not being a problem that SCSI-level flushes are supper slow, which is only not a problem if you don't do them (e.g. only use fsync on Mac)?But reading it again there might have been some confusion about what was meant.
marcan_42 4 years ago macOS does issue an NVMe flush on standard kernel panics, although of course it's possible to have it die in a way where that doesn't work.
They do if you don't use F_FULLSYNC, even apple acknowledges it (quote apple man pages):
> Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written.
It's also worse then just write losses:
> The disk drive may also re-order the data so that later writes may be present, while earlier writes are not.
I'm using "acknowledged" in the sense of SCSI-level flush (per the thread OP), not mac OS's peculiar implementation of fsync.
But the thread OS is about it not being a problem that SCSI-level flushes are supper slow, which is only not a problem if you don't do them (e.g. only use fsync on Mac)?
But reading it again there might have been some confusion about what was meant.
macOS does issue an NVMe flush on standard kernel panics, although of course it's possible to have it die in a way where that doesn't work.