InquiringMind, NTFS does not support out of order writes. What is does support is journaling, which is completely different thing. Windows also supports delayed writes, but they are journaled and in order.
What is out of order write?
* You do some I/O, and what needs to be written down is in block, block 1, block 2, block 1, block 3, block 1, block 4 so it's 1,2,1,3,1,4
What each OS is going to do, is write in that exact order: 1,2,1,3,1,4
What PrimoCache is going to do is change order before writing to disk to : 2,3,1,4
This is since 'block 1' would be changed multiple times, and due it not being yet written, it will not write in that order to reduce I/O.
However, let's consider situation where crash occurs, and it happens exactly when 'block 3' is actually written do disk.
On 'regular' system, blocks written would be: 1,2,1, and after that '3,1,4' would be lost due to crash.
With PrimoCache what would be lost is 'block 2', and 'block 1', which should be written already twice would not be changed on disk itself, but rather lost.
What this mean in practice, or real world scenario?
This means that some block might not be written to disk in order that filesystem would expect. This is due to PrimoCache being layer in between filesystem and disk itself.
Next thing this means: in case of deferred writes in PrimoCache, and if delayed cache was not empty, in case of crash there is data loss. Data loss is expected, and that is fine. However, data was NOT written in order to disk, so some data that would be expected to be on disk is missing.
This means that in some cases 'chkdsk' might say filesystem is fine, or repaired either by 'full scan' or just by replaying logs, but in reality you might have missing changes on disk, which means data corruption.
Again, what I did test is do changes on some files, or copy files, or delete, and copy files, and if using deferred writes, I could get errors afterwards, and this is in a way of:
* chkdsk said FS is fine
* I actually missed some files, or some files that were existing were corrupt. Wort of all, it's silent corruption - as chkdsk does not know there is corruption.
Filesystems such as ZFS would report errors due to checksum errors, but NTFS does not support that.
Bottom line, deferred writes can speed things up on slow HDD's, but it has quite dangerous risk. Worst of all is silent corruptions you can have.
This all could be mitigated if deferred writes used only L2 as an option, and used journaling/could recover/empty deferred write buffer upon crash. This is option that for example bcache on Linux has.
Another option is possibility in PrimoCache to disable out of order writes (aka data consolidation, as called in PrimoCache), so in previous example 'block 1' would be written multiple times, and in cace of crash data it written in order and filesystem checks can repair to proper state filesystem.