You run `lvcreate -s -L 5G -n db-snap vg0/db` on a Linux host. What has LVM created, and what happens on disk the first time a block of the origin volume is overwritten afterwards?

## What exists after the command returns Three things now exist in `vg0`: - the origin logical volume `vg0/db`, unchanged in content; - a hidden copy-on-write logical volume of 5 GiB, carved from the volume group's free extents; - a new visible device, `/dev/vg0/db-snap`, which you can mount (normally read-only) and read as if it were a frozen clone of the origin. `lvs` will now report `db` with the origin/snapshot relationship and show `db-snap` with an `Origin` of `db` and a `Data%` that starts near zero: ``` $ lvs -o lv_name,lv_size,origin,data_percent vg0 LV LSize Origin Data% db 500.00g db-snap 5.00g db 0.01 ``` No bulk copy happened. That is the first thing to say out loud, because a lot of candidates assume snapshot creation duplicates data and are then confused about why it is instantaneous. ## The copy-on-write write path The origin and the snapshot are both fronted by device-mapper targets. The unit of work is a *chunk* — a fixed block size chosen at creation and adjustable with `--chunksize`. Device-mapper maintains an **exception table**: a map from "chunk N of the origin" to "chunk M of the COW area", holding the pre-snapshot contents of any chunk that has since been modified. A write to a chunk of the origin that has no exception yet triggers, in order: 1. read the current (old) contents of that chunk from the origin; 2. write those old contents into a free slot in the COW area; 3. commit the new entry in the exception table (metadata is also stored in the COW LV); 4. write the new data to the origin. A write to a chunk that already has an exception skips all of that and goes straight through — the old version is already preserved, so it only ever gets copied once. This is why a workload that repeatedly rewrites the same hot region pays the penalty briefly and then runs at close to normal speed, while a workload that touches fresh regions across the volume keeps paying. The cost is real: at worst one extra read and one extra write per chunk first-touched, plus metadata commits. Order-of-magnitude write slowdowns on a busy volume during a snapshot window are unremarkable, and the effect multiplies with the number of classic snapshots — each snapshot has its own COW area and needs its own copy of the old chunk, so N snapshots means up to N copies before the write can proceed. ## The read path Reading `/dev/vg0/db-snap` consults the exception table. If the chunk has an exception, the read is served from the COW area (the old, preserved contents). If it does not, the read is redirected to the origin, because that chunk has not changed since the snapshot was created and the origin still holds the correct point-in-time data. This redirect is exactly why the snapshot cannot outlive the origin. Reading the *origin* is unaffected — it is served directly, with no exception lookup on the read path. ## Chunk size, and what the 5G means The `-L 5G` sizes the COW area, not the visible size of the snapshot. `/dev/vg0/db-snap` presents the same logical size as the origin (500 GiB in the listing above); the 5 GiB is the budget for preserved old chunks. Sizing it is therefore a question about the origin's *write* volume during the snapshot's lifetime, never about the origin's capacity. Chunk size matters at the margins: larger chunks mean fewer, larger copies and a smaller exception table but more write amplification when writes are small and scattered (touching one 4 KiB block still copies a whole chunk). Smaller chunks reduce the copied volume but grow the metadata. You can set it explicitly with `lvcreate -s --chunksize`. ## The consequences worth naming - **Creation is O(1)**, deletion is O(1); the cost is spread over the origin's writes while the snapshot lives. - **The snapshot grows with change, not with data**, so a quiet volume can be snapshotted with a tiny COW area and a write-heavy one cannot. - **A full COW area is fatal to the snapshot** — device-mapper marks it invalid and reads from it fail, which is the classic production incident on this feature. - **Long-lived classic snapshots are a performance decision**, not a free one; this is the main reason thin snapshots, which redirect writes to newly allocated pool blocks instead of copying old ones, replaced them for anything long-running.