"Paul" == Paul Timmins paul@ptimmins.com writes:
> Not to nit-pick... but what being described is the behavior of a > log-structured file system (of which WAFL is one). There are > many other implementations of log-structured file systems.
> IMO, calling that copy-on-write is dead-wrong, not merely > confusing. There's no copy going on. The inode file is copied > (checkpointed) when a snapshot is initiated, not when a write > occurs.
This is turning into a semantics discussion. I don't think we've agreed on a definition for 'copy-on-write' to compare/contrast what WAFL does.
If your definition of copy-on-write with respect to filesystems means that whenever a modification to a file occurs, the entire file is copied, but new modified blocks are written out, I would agree, WAFL does not meet this definition.
However, there is work to be done by WAFL when a file is modified besides just writing out a new data block. In addition, all of the block pointers, all the way up to the root inode need to be updated. Of course, this is all intrinsic to the design WAFL.
I guess my point is that a discussion of WAFL performance versus <some_other_filesystem> performance based upon the copy-on-write technique in use is silly. You have to look at the complete design of each solution. (Just like it's silly to say RAID-4 is not as good as RAID-5, Netapp uses RAID-4, hence Netapp is bad; an argument I've heard before.)
Finally, you could argue that WAFL uses a copy-on-write technique that delegates the "copying" to the NFS/CIFS client.
j.