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.
Just my two cents... Paul
-----Original Message----- From: Eli Lopez [mailto:elopez@netapp.com] Sent: Sunday, May 13, 2001 4:38 AM To: Jay Soffian; toasters@mathworks.com Subject: Re: Copy on write - Netapp vs. others
Hi Jay,
You are right that the terminology is confusing.
One way to look at it is to think of two ways of copy-on-write: when you are updating a block of a file you can: 1) Either write the NEW UPDATED block to a new location 2) Or move the OLD block to a new location AND THEN write the new updated block in place of the old one.
Taking a snapshot with both methods involves copying the inode file BUT obviously there could be serious performance impact using the second method (for each update, the write request needs to 'wait' until the old block gets copied to a new location).
Network Appliance's WAFL uses the first method which does not have any impact on performance and is (IMVHO) much more elegant.
Thanks, Eli
______________________ Eli Lopez Systems Engineer Manager Network Appliance, Israel (+972) - 50 - 304 - 733 Eli.Lopez@Netapp.com ______________________
----- Original Message ----- From: Jay Soffian jay@loudcloud.com To: toasters@mathworks.com Sent: Thursday, May 10, 2001 7:00 PM Subject: Re: EMC IP4700 vs NetApp F740
"Ferd" == Ferd Berfl ferd_berfl@yahoo.com writes:
> re: snapshots, I thought that everyone else's snapshot > functionality other than Netapp's must be based on a "copy on > write" method because Netapp has a patent on continuously > writing new blocks.WAFL uses copy-on-write. Here, straight from the horse's mouth:
WAFL uses a copy-on-write technique to minimize the disk space that Snapshots consume.
http://www.netapp.com/tech_library/3002.html
Now, Netapp's implementation may be unique, but to say that WAFL doesn't use copy-on-write and to make a claim like "copy-on-write is slow, Netapp doesn't use it" is bogus.
j.
Jay Soffian jay@loudcloud.com System
Administrator
408 744 7584 Loudcloud,
Inc.
in some other vendor's snapshot function, not network appliance's, once a snapshot is taken, isn't every modified block a "copy on write?" since the original block has to be copied to the snapshot area and then the original block has to be modified, resulting in two operations for each block modified.
-----Original Message----- From: owner-dl-toasters@netapp.com [mailto:owner-dl-toasters@netapp.com]On Behalf Of Paul Timmins Sent: Sunday, May 13, 2001 7:06 PM To: 'Eli Lopez'; Jay Soffian; toasters@mathworks.com Subject: RE: Copy on write - Netapp vs. others
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.
Just my two cents... Paul-----Original Message----- From: Eli Lopez [mailto:elopez@netapp.com] Sent: Sunday, May 13, 2001 4:38 AM To: Jay Soffian; toasters@mathworks.com Subject: Re: Copy on write - Netapp vs. others
Hi Jay,
You are right that the terminology is confusing.
One way to look at it is to think of two ways of copy-on-write: when you are updating a block of a file you can: 1) Either write the NEW UPDATED block to a new location 2) Or move the OLD block to a new location AND THEN write the new updated block in place of the old one.
Taking a snapshot with both methods involves copying the inode file BUT obviously there could be serious performance impact using the second method (for each update, the write request needs to 'wait' until the old block gets copied to a new location).
Network Appliance's WAFL uses the first method which does not have any impact on performance and is (IMVHO) much more elegant.
Thanks, Eli
Eli Lopez Systems Engineer Manager Network Appliance, Israel (+972) - 50 - 304 - 733 Eli.Lopez@Netapp.com ______________________
----- Original Message ----- From: Jay Soffian jay@loudcloud.com To: toasters@mathworks.com Sent: Thursday, May 10, 2001 7:00 PM Subject: Re: EMC IP4700 vs NetApp F740
"Ferd" == Ferd Berfl ferd_berfl@yahoo.com writes:
> re: snapshots, I thought that everyone else's snapshot > functionality other than Netapp's must be based on a "copy on > write" method because Netapp has a patent on continuously > writing new blocks.WAFL uses copy-on-write. Here, straight from the horse's mouth:
WAFL uses a copy-on-write technique to minimize the disk space that Snapshots consume.
http://www.netapp.com/tech_library/3002.html
Now, Netapp's implementation may be unique, but to say that WAFL doesn't use copy-on-write and to make a claim like "copy-on-write is slow, Netapp doesn't use it" is bogus.
j.
Jay Soffian jay@loudcloud.com System
Administrator
408 744 7584
Loudcloud, Inc.
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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.
Just my two cents... Paul
Here is some more basic commentary for the newbies ...
By "checkpointed" I don't think that Paul is implying that the entire inode file is copied. It is handled just like any other file, i.e., only blocks that have changed are replaced with new blocks. Blocks containing unchanged data are not replaced. And as Paul points out, the inode file is only updated when WAFL writes a consistency point (snapshot).
WAFL never disturbs the blocks that comprise the current consistency point when writing a new C.P. Should the filer crash or lose power in the middle of writing the new C.P., the old C.P. is still intact. And WAFL keeps a log in NVRAM of all write requests since that last C.P. To recover, WAFL simply reverts to the most recent C.P. and replays the NVRAM log.
When a read request arrives over the net, WAFL tries to satisfy it using filesystem data cached in RAM. If the data isn't in RAM, then it is read from disk and cached in RAM.
When a write request arrives over the net, WAFL logs it in NVRAM. WAFL also updates the filesystem RAM cache, which makes the newly written data immediately available for reading. But WAFL waits awhile before committing the write to disk.
Once enough writes have accumulated in NVRAM, or 10 seconds has elapsed since the last C.P., WAFL emits a burst of writes to the disks, generating a new C.P. The committed write requests are cleared from the NVRAM log. If you ever watch the disk drive lights on a moderately loaded filer, you will notice that about every 10 seconds there is a flurry of activity. This is a new C.P. being written.
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
"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.
-
Ferd Berfl -
Jay Soffian -
Paul Timmins -
Steve Losen