On Tue, Jun 5, 2012 at 6:32 AM, Jim Klimov <jimkli...@cos.ru> wrote:
> I recently heard an argument from a colleague that "ZFS mis-uses
> the term COW" (Copy-On-Write). According to him, the original term
> was introduced by some vendors and was to be taken literally: that
> is, whenever a new write comes to update an existing logical block
> in the storage, the block's old contents are first copied away to
> another physical location (i.e. to be used for snapshotting or for
> recovery of untimely poweroff/panic), then the original on-disk
> location is rewritten with the new data.
This is what I have seen "traditional" filesystems (UFS, VxFS) do
in when dealing with snapshots. Once a snapshot is taken, for any data
that is being re-written, a copy of the original must be made before
committing the write.
> Arguably, while this incurs a hit when rewriting existing data,
The hit to write performance can be substantial and the space to
store each snapshot's data can also be large. This is one of the big
differences between ZFS and others. The cost (both write performance
and space) for snapshots in ZFS is minimal while for traditional
filesystems it can be huge (depending on the number of snapshots).
> this combats fragmentation and speeds up reads (i.e. all pieces of
> the file's "live" version are stored as contiguously as possible).
As long as the file has not grown beyond the original allocation
segment. Once you grow out of that you are (usually) fragmented.
> This may be important for large objects randomly updated "inside",
> like VM disk images and iSCSI backing stores, precreated database
> table files, maybe swapfiles, etc.
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Assistant Technical Director, LoneStarCon 3 (http://lonestarcon3.org/)
-> Sound Coordinator, Schenectady Light Opera Company (
-> Technical Advisor, Troy Civic Theatre Company
-> Technical Advisor, RPI Players
zfs-discuss mailing list