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 EINPROGRESS EALREADY 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 # freezefs # [do your hardware raid stuff] # thawfs 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. jim -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
