Jumping into the battle...
Advfs implemented freezefs and thawfs in 2001 so here is
the design rational from a commercial unix view.
Note - We already had built-in snapshots for local disk
consistent backups so some choices might be different on Linux.
NEED - provide way for SAN and hardware raid storage to do
its snapshot/copy function while the system was in-use and
get an image that could mount cleanly. Without freeze, at
a minimum we usually needed filesystem metadata recovery
to run, worst case is completely unusable snapshits :)
freezefs() is single-level:
ENOTSUPPOTED - by any other fs
EOK - done
As implemented, freezefs only ensures the metadata is
consistent so the filesystem copy can mount anywhere.
This means ONLY SOME metadata (or no metadata) is flushed and
then all metadata updates are stopped. User/kernel writes
to already allocated file pages WILL go to a frozen disk.
It also means writers that need storage allocation (not
delaloc or existing) and things that semantically must
force on-disk updates will hang during the freeze.
These semantics meet the need and has the advantage of the
best perfomance. The design specification for freezefs
provided flags on the api to add more consistency options
later if they were desired:
- flush all dirty metadata
- flush all existing dirty file data
- prevent new dirty file data to disk
but they would all add to the "kill the system" problem.
freezefs has the timeout argument and the default timeout
is a system config parameter:
> 0 specifies the timeout value
= 0 uses the default timeout
< 0 disable timeout
A program could call the freezefs/thawfs api, but the
only current use is the separate commands
# [do your hardware raid stuff]
This is either operator driven or script/cron driven
because hardware raid providers (especially our own)
are really unfriendly and not helpful.
NUMBER ONE RULE - freeze must not hang/crash the system
because that defeats the customer reason for wanting it.
WHY A TIMEOUT - need a way for operator to abort the
freeze because with a frozen filesystem they may not
even be able to do a login to thaw it!
Users get pissed when the system is hung for a long
time and our experience with SAN devices is that their
response to commands is often unreasonably long.
In addition to the user controllable timeout mechanism,
we internally implement AUTO-THAW in the filesystem
whenever necessary to prevent a kernel hang/crash.
If an AUTO-THAW occurs, we post to the log and an
event manager so the user knows the snapshot is bad.