--- title: "Cloned Files and Shared Blocks: Why Later Writes Can Need More Storage" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/reflink-clone-shared-extents-write-growth" last-updated: "2026-10-20" --- # Cloned Files and Shared Blocks: Why Later Writes Can Need More Storage Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. A supported filesystem reflink can give an artifact variant its own file identity while initially sharing the source's data extents. Later writes keep the changed contents private to the written file, but can require new backing even when neither file grows in length. Assess the shared data and the proposed write growth together: a small initial allocation does not show that later space has been reserved or that an independent recovery copy exists. ## Follow the shared data beneath the two files An artifact proposal might offer a base file and an editable variant without allocating a second full set of data immediately. The useful question is what the variant shares now and what its later edits will require. The Btrfs project's Reflink documentation describes separate file metadata pointing to shared data blocks. This is a shallow copy of the data: the files have distinct identities, while their references can lead to the same backing. Here, a data extent means a range of filesystem data backing; it is not a statement about SSD geometry. Linux man-pages 6.19, in its FICLONE reference dated February 8, 2026, describes sharing underlying storage on supporting filesystems. A write to a shared region must keep its changes private to the file being written. That applies whichever sibling receives the write. Copy-on-write preserves this separation of contents by providing new storage when shared data must diverge. The Linux interface requires the same filesystem and has file and range eligibility limits. Same-filesystem placement alone does not prove that a proposed clone is supported. The Btrfs page is a named implementation explanation, not a compatibility promise for every copy path. References: [B1](https://btrfs.readthedocs.io/en/latest/Reflink.html), [F1](https://man7.org/linux/man-pages/man2/FICLONE.2const.html) ## Count a 4 GiB artifact and its completed clone once Consider a fictional, stable artifact file A with exactly 4 GiB of logical length and exactly 4 GiB of data extents. On one supporting filesystem, a completed full-file reflink produces variant B, also 4 GiB long, initially referencing all the same data extents. One GiB equals 1,073,741,824 bytes. This model has no holes, compression, deduplication or other references, including snapshots. It excludes metadata, allocation rounding, transient allocation and work, and reclamation timing. Its accounting boundary is the unique filesystem data extents reachable from these two files. The numbers are stipulated assumptions, not measured allocation, device writes or a complete free-space requirement. Summing the file lengths gives 4 + 4 = 8 GiB. Counting the union of their data extents gives 4 GiB: the shared backing appears once in that union even though both files reference it. Under these assumptions, creating B adds no new data extents. The excluded metadata prevents interpreting that statement as a zero-cost real clone. The two totals answer different questions. Eight GiB describes the combined logical lengths presented by the files. Four GiB describes the unique data backing retained by this pair at this stage. References: [U1](https://physics.nist.gov/cuu/Units/binary.html) ## An overwrite can grow backing without lengthening either file Now B overwrites the range from offset 1 GiB up to, but excluding, 2 GiB with different bytes. Stipulate that this range is suitably aligned for the modeled filesystem and that the completed change allocates exactly 1 GiB of new private data backing. There is no append and no other change. A still references all 4 GiB of its original data. B references the unchanged 3 GiB of shared data plus its new 1 GiB for the overwritten range. Reading that range from A returns the original bytes; reading it from B returns the replacement bytes. The unique live data now consists of 3 GiB shared by A and B, 1 GiB referenced only by A, and 1 GiB referenced only by B. Count each part once: 3 + 1 + 1 = 5 GiB. The original range remains needed by A, so replacing B's reference does not remove that original backing from the union. Both logical lengths remain 4 GiB, totaling 8 GiB. Unique backing has nevertheless increased by 1 GiB, from 4 GiB to 5 GiB. The exact one-for-one increase follows from the stipulated new allocation; it is not a universal overwrite multiplier. This case illustrates the copy-on-write mechanism without predicting a real filesystem's allocation granularity or peak consumption. References: [F1](https://man7.org/linux/man-pages/man2/FICLONE.2const.html) ## Compare initial sharing with the space needed for later edits A proposal describing B as an independently editable 4 GiB file can match this model. A proposal that therefore counts another 4 GiB of unique data immediately would double-count the initially shared backing. Conversely, treating the clone's initially small incremental allocation as a reservation for later writes would miss the growth shown by the overwrite. The FICLONE manual explicitly identifies new-storage allocation as a copy-on-write requirement. Initial sharing supplies no evidence that the needed future space has been reserved. The buyer needs the storage owner's explanation of how the intended edits and retained variants fit the actual backing available to them. Ask that owner to identify the supported filesystem and clone behavior, the files and other references included in the allocation account, and the stage at which usage was observed. Connect any capacity undertaking to the intended write pattern and the variants that must remain present together. This example supplies no production sizing allowance. Do not infer unique usage by summing per-file block reports. Such a sum does not, by itself, identify the backing those files have in common. Btrfs's disk-usage reference distinguishes total, exclusive and set-shared values; the set-shared value accounts for overlapping shared extents. The worked result here comes from the known shared and private extent populations. The related sparse-file guide covers holes and file allocation; the thin-storage guide carries the separate volume-and-pool capacity question. References: [F1](https://man7.org/linux/man-pages/man2/FICLONE.2const.html), [B2](https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html) ## Private changes do not establish an independent recovery copy In the example, an edit to B leaves A's corresponding contents intact. That is a useful property for an artifact variant. Both files still depend on the 3 GiB they share after the edit, and they remain on the same filesystem. The consequence is that separate file identities and private changes cannot, by themselves, demonstrate independence from loss of the shared backing. A recovery claim needs evidence for its stated failure and recovery scope. The allocation example also supplies no evidence of coherent application state or a successful recovery. Use the related training-checkpoint-versus-storage-snapshot guide when the decision concerns which application state a retained copy contains. Use the container-storage guide when the claim concerns packaged layers and runtime storage. Those questions complement the shared-file accounting here without changing its 5 GiB result. References: [B1](https://btrfs.readthedocs.io/en/latest/Reflink.html) ## Carry any resulting equipment decision into a physical installation scope If the storage team's capacity review separately leads to equipment requiring physical installation, Leviathan's rack-and-stack service covers agreed equipment mounting, IT cabling, labels and physical installation records. The service and project inquiry below provide a place to discuss that actual hardware work. Share a nonconfidential equipment list, site, released rack positions, approved connection schedule and required physical handoff. Filesystem allocation, cloning and recovery decisions remain with the appointed storage and application teams. References: [L1](https://www.leviathansystems.co/services/rack-and-stack) ## Primary sources - [F1 — Linux man-pages 6.19: FICLONE(2const)](https://man7.org/linux/man-pages/man2/FICLONE.2const.html). Checked 2026-10-20. Manual dated February 8, 2026. Describes supported same-filesystem storage sharing, private later writes, eligibility limits and new copy-on-write allocation. The exact allocation in the worked case is stipulated. - [B1 — Btrfs project documentation: Reflink](https://btrfs.readthedocs.io/en/latest/Reflink.html). Checked 2026-10-20. Unversioned project reference explaining separate metadata pointing to shared data blocks and independent file changes. Its implementation constraints require a supported file and filesystem combination. - [B2 — Btrfs project documentation: Filesystem disk-usage accounting](https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html). Checked 2026-10-20. Unversioned reference distinguishing total, exclusive and set-shared usage, including overlapping shared extents. These definitions support the accounting distinction; no command or procedure is prescribed. - [U1 — NIST: Prefixes for binary multiples](https://physics.nist.gov/cuu/Units/binary.html). Checked 2026-10-20. Defines one GiB as 2^30 bytes, or 1,073,741,824 bytes, for the example's exact units. - [L1 — Leviathan Systems: Rack & Stack / Colocation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Defines the agreed equipment mounting, physical IT cabling, labeling and installation records relevant to a separate hardware installation project. ## Related Leviathan resources - [Sparse-file holes, logical length and allocated blocks](/articles/sparse-file-holes-logical-size-allocated-blocks) - [Thin-volume size and shared-pool backing](/articles/thin-storage-logical-volume-size-versus-pool-backing) - [Container layers, compressed pulls and runtime storage](/articles/gpu-container-compressed-layers-versus-runtime-storage) - [Training checkpoints and the contents of storage copies](/articles/gpu-training-checkpoint-versus-storage-snapshot) - [Rack-and-stack physical installation scope](/services/rack-and-stack) - [Discuss a separate storage-equipment installation](/contact?service=rack-and-stack&from=%2Farticles%2Freflink-clone-shared-extents-write-growth) ## Does the selected equipment need physical installation? Share the equipment list, site, released rack and connection plans, and required physical handoff to discuss installation scope and availability. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/reflink-clone-shared-extents-write-growth)