You take an LVM snapshot of a mounted, actively written filesystem on a Linux host. What consistency does the resulting snapshot actually give you, and what does running `fsfreeze -f` on the mount point immediately before the snapshot add?

## Three layers, three kinds of state When a snapshot is taken, data relevant to "is this consistent?" lives in three places: 1. **The block device** — data already written to the logical volume. The snapshot captures this. 2. **The kernel page cache and filesystem journal** — data the filesystem has accepted but not yet written back. The snapshot captures only what happened to have been flushed. 3. **Application memory** — records, buffers and in-flight transactions the application has not handed to the filesystem at all. The snapshot captures none of this. LVM operates at layer 1. Creating the snapshot suspends the origin's device-mapper device long enough to flush in-flight block I/O and install the new mapping atomically, which is why you never see a torn half-old/half-new image at the block layer. It does not reach up into layers 2 and 3. ## Crash consistency, and why it is usually survivable The resulting image is exactly what the volume would look like if the power cable were pulled at that instant. Journalling filesystems are built for precisely this: ext4 and XFS write metadata changes to a journal before applying them, so mounting the snapshot replays the journal and yields a structurally sound filesystem. That is why crash-consistent snapshots "just work" most of the time. What survives the replay is a weaker statement than people assume. Structural integrity is restored; recent *content* may not be. A file that the application wrote and did not fsync may be absent, truncated, or present with stale contents. Two files that must be updated together may be captured in different states unless the application ordered its writes with fsync and expected a crash at any point. In short: crash consistency gives you what a crash-tolerant application would have survived, and nothing more. ## What `fsfreeze -f` adds `fsfreeze` (from util-linux) drives the kernel's filesystem freeze operation on a mount point: ``` fsfreeze -f /var/lib/app # flush and quiesce lvcreate -s -L 10G -n app-snap vg0/app fsfreeze -u /var/lib/app # thaw ``` Between the freeze and the thaw the kernel has written back the filesystem's dirty data and metadata and put the filesystem into a consistent, quiescent state; new write attempts block rather than proceeding. The snapshot taken in that window is therefore a *cleanly unmounted-looking* filesystem image: it mounts without journal replay, and it does not contain a half-finished metadata operation. ext4 and XFS both support this, and taking the snapshot is fast, so the window is milliseconds to a second or two. The operational rules around it are strict, and this is where an interviewer is listening: - **Freeze for as short a time as possible.** Every writer to that filesystem blocks while it is frozen. A frozen root filesystem can wedge the machine, including the very shell you would use to thaw it — always run freeze/snapshot/thaw as one scripted sequence, never as three interactive commands you might get distracted between. - **Always pair the thaw**, including on failure. Put the `fsfreeze -u` in a trap or an unconditional cleanup path so a failing `lvcreate` does not leave the filesystem frozen. - **Do not freeze what you cannot afford to block.** For a latency-sensitive service, even a second of blocked writes may be more disruptive than a journal replay on the restore side. ## What freeze still does not do Freezing quiesces the *filesystem*, not the *applications*. Anything holding state in its own memory — buffered records, an open write it intends to complete, a cache it plans to flush later — is not represented in the snapshot. Making a snapshot usable at the application level means telling the application to flush and reach a consistent point before you freeze, and only that application can define what such a point is. That coordination is the application's own problem and its own procedure; from the storage side, your obligation is to give it a window and to freeze after it says it is ready. ## Putting it together A defensible snapshot-backup sequence looks like: ask the application to quiesce or checkpoint → `fsfreeze -f` → `lvcreate -s` → `fsfreeze -u` (unconditionally) → release the application → mount the snapshot read-only → stream it off-host → verify → `lvremove`. The freeze window contains exactly one cheap command. And the honest fallback, when a freeze is impossible, is to accept crash consistency and to prove it works by actually restoring from it — a restore test is the only evidence that "the journal will replay" is true for your workload.