snapshot implementation

[Jeff Roberson]

On Tue, 29 Dec 2009, Ronald Klop wrote:

> On Fri, 25 Dec 2009 15:29:53 +0100, patpro <patpro at patpro.net> wrote:
>
>> 
>> On Wed, 23 Dec 2009 14:56:18 -0600, Barry Pederson <bp at barryp.org> wrote:
>>> "...there's virtually no overhead at all due to the copy-on-write
>>> architecture. In fact, sometimes it is faster to take a snapshot rather
>>> than free the blocks containing the old data!"
>>> 
>>> That's certainly not the case with UFS snapshots, which can take a long
>>> time to complete (we're talking freezing your machine's disk activity
>>> for many minutes), and are limited to 20 total.
>> 
>> 
>> UFS uses copy on write. But you say many minutes to complete? Don't you
>> speak about dump(1), that uses snapshot as a basis to dump a live file
>> system?
>> I agree, UFS snapshot creation is not lightning-fast, but many minutes
>> seems a lot to me, and I never experienced such a long creation time.
>
> As far as I know UFS snapshots need to create a list of currently in use 
> blocks. This is O(n) on the size of the FS and pauses the FS during the 
> snapshot. On large FS's this can take a long time.
> ZFS always maintains this list so it only needs to mark this list as readonly 
> to create a snapshot. This is O(1).
>

This is not quite right.  It's the copy of cg blocks that takes so long. 
cg blocks are limited in size to one filesystem block which means on very 
large drives there are quite a lot of them.

When we create a snapshot we first make a copy of all cg blocks, then we 
suspend the filesystem and sync it, and then we copy all dirtied cg 
blocks and unsuspend.  We seem to be copying an excessive number of CGs 
once suspended so there may be a bug there.  A relatively straightforward 
improvement would be to also COW the cg blocks rather than copying them in 
a seperate step.

There's no reason the COW snapshot mechanism can't be fast theoretically. 
It's just a matter of the practical implementation.

Thanks,
Jeff

> Ronald.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"