Snapshot ufs blocking

Eric Anderson anderson at centtech.com
Tue Mar 14 16:38:10 UTC 2006


Kris Kennaway wrote:
> On Tue, Mar 14, 2006 at 09:30:27AM -0600, Eric Anderson wrote:
>   
>> Robert Watson wrote:
>>     
>>> On Sun, 12 Mar 2006, Eric Anderson wrote:
>>>
>>>       
>>>>> Thanks.  There is an uncommitted patch being circulated that is 
>>>>> believed to address all remaining problems.  It relies on other 
>>>>> fixes in -CURRENT that are not yet merged, but if you're able to 
>>>>> test it let me know and I'll forward.
>>>>>           
>>>> I can definitely test it - I'm running 6-STABLE currently, but I 
>>>> suppose I could get -CURRENT on there for the testing..
>>>>         
>>> FYI, Jeff Roberson just did a large scale merge of 
>>> UFS/VFS/snapshot/... bug fixes from HEAD to RELENG_6, see my HEADS UP 
>>> post on -stable a day or so ago. It would be very useful to know if 
>>> these help, and if not, you may want to drop e-mail to Jeff Roberson 
>>> with a detailed description, since he's actively working on tracking 
>>> down and fixing these issues.
>>>
>>> Robert N M Watson
>>>       
>> Well, updating to the latest RELENG_6, I see that progress is definitely 
>> being made.  I don't seem to be deadlocked anymore.  Commands like ls 
>> and such work fine, until I ls the snapshot file itself, which blocked 
>> for about 10 minutes before finally completing, and once that command 
>> blocked (ufs) other ls -al commands blocked (ufs) on the root (/) 
>> directory and subsequent subdirs down to the snapshot.  A 'sync' also 
>> blocked during this time (blkrd?), but the difference this time is that 
>> they all completed.  The snapshot completed within about 22 minutes (2Tb 
>> filesystem, very little on this one), and commands returned before the 
>> snapshot finished at about the 10 minute mark, and subsequent commands 
>> (again, ls -al, etc), completed when the snapshot completed.  The 
>> machine in question is a dual Xeon 2.8GHz with 4Gb of memory, running 
>> SMP kernel (pretty much GENERIC), and was about 30% busy (cpu) mostly 
>> 'system' and 'io'.  The disk being snapshotted was very busy though..
>>     
>
> Yes, that's expected behaviour.
>   

ok - would you mind explaining it to me?  I'm very interested in 
understanding this technically, but I know it might be a drag to explain 
it. 

I suppose I would understand that the processes trying to access the 
snapshot file itself would block, but once that's blocked, why do 
processes accessing (stat) the / directory block also?  Tools like df 
complete, so the fsstat is returning with data, which touches the 
superblock, correct?  Then does that mean the root directory inode is 
locked during the snapshot?  If that's true, then maybe putting the 
snapshot two levels down (/.snap/2006-03/14.snap) would cure that?


Thanks!
Eric



-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------



More information about the freebsd-fs mailing list