three follow-up questions RE: UFS2 snapshots on large filesystems

[Scott Long]

user wrote:
> 
> thank you scott - see below:
> 
> On Fri, 4 Nov 2005, Scott Long wrote:
> 
> 
>>The UFS snapshot code was written at a time when disks were typically 
>>around 4-9GB in size, not 400GB in size =-)  Unfortunately, the amount
>>of time it takes to do the initial snapshot bookkeeping scales linearly
>>with the size of the drive, and many people have reported that it takes
>>considerable amount of time (anywhere from several minutes to several 
>>dozen minutes) on large drives/arrays like you describe.  So, you should
>>test and plan accordingly if you are interested in using them.
> 
> 
> 
> Testing is what I need to do.  I have a few follow up questions:
> 
> First, are there any sysctl or kernel tunables that change any of what you
> are discussing above ?

There doesn't appear to be any tunables in the snapshot code other than
for debugging.

> 
> Second, let's say I am willing to accept the long snapshot creation period
> ... are there other drawbacks as well during the course of _running with_
> the snapshot once it is created ?  Or are all costs paid initially ?

There is a slight performance penalty from tracking block changes and
copying them to the snapshot file.  It's fairly small, though, not
enough to impact normal use.

> 
> Finally, I have read the bsdcon3 paper that mccusick wrote where he
> addressed the dual problems of not enough kernel memory (10 megabytes) to
> cache disk pages, and the system deadlocking that occurs with two
> snapshots.  Is it true that both of the fixes he elucidated in that paper
> are built into what I see as fbsd 5.4 now ?
> 

That I do not know.  There have been a number of deadlock fixes in over 
the past few years, and some a few months ago in particular, but I 
haven't tracked them closely enough to know.

Scott