| |||||||||||||
There are better ways to snapshottingThere are better ways to snapshottingPosted May 10, 2009 0:05 UTC (Sun) by butlerm (subscriber, #13312)In reply to: There are better ways to snapshotting by anton Parent article: The two sides of reflink()
One of the advantages of ZFS style snapshotting is it is a constant time
operation that is far more efficient than walking a directory tree and creating thousands of new inodes. It doesn't work for making a (writable) snapshot of a snapshot, however, and that is a very important use case for virtualization, for example.
Copy-on-write filesystems could use a good interface (like this one) to make
(Log in to post comments)
There are better ways to snapshotting Posted May 10, 2009 18:36 UTC (Sun) by anton (guest, #25547) [Link] One of the advantages of ZFS style snapshotting is it is a constant time operation that is far more efficient than walking a directory tree and creating thousands of new inodes. It doesn't work for making a (writable) snapshot of a snapshot, howeverThat may be a limitation of ZFS, but it's not a necessary limitation. LLFS can do it, and nothing I have read about Btrfs indicates that it cannot do it. Copy-on-write filesystems could use a good interface (like this one) to make efficient *copies* of files in the same (extended) filesystem.Yes, implementing cp more efficiently seems to be the main benefit I see from this system call.
There are better ways to snapshotting Posted May 11, 2009 5:22 UTC (Mon) by butlerm (subscriber, #13312) [Link]
Netapp does writable snapshots of writable snapshots. The advantage of the
ZFS scheme is you can have an unlimited number of snapshots, where with Netapp these days I believe you get 256.
The ZFS scheme is based on logical sequence numbers, Netapp uses block maps.
|
|||||||||||||