True. But the key point is also that stopping file writes is
__no better__ than an unexpected shutdown for applications.
Once kernel people accept that it is identical to an unknown
shutdown state, they realize that as you said...
The people writing the code outside the kernel are the ones
responsible for the logic of handling "we don't know what
application writes made it to disk".
Remember that immediately after fsync(), the next write
can make the file inconsistent. For example, look at this
simple sales processing database type sequence:
write(sale_last_name_file, "Mackek"
write(sale_first_name_file, "Pavel")
fsync(sale_last_name_file)
fsync(sale_first_name_file)
...
write(sale_last_name_file, "Owens")
write(sale_first_name_file, "Jim")
fsync(sale_last_name_file)
FREEZEFS [defined to NOT allow file data writes]
So if we restart from that snapshot, the sales order
thinks the customer is "Pavel Owens"... unless there
is some mechanism such as seqence numbers that tie
the files together. And if they have such a mechanism
then it doesn't matter if we allow even more writes
such as:
write(sale_first_name_file, "Ted")
There just is no way inside the kernel to know a
freeze was triggered at a stable application point
such that data before the freeze must be on disk
and data after the freez must not go to disk.
This issue is not unique to freeze, it is also
present with filesystems that have snapshots and
cow/versioning built in.
jim
--
