Re: ffs snapshots patch

[Ignatios Souvatzis <is%netbsd.org@localhost>]

On Fri, Apr 29, 2011 at 01:56:01PM +0200, Juergen Hannken-Illjes wrote:
> On Fri, Apr 29, 2011 at 01:48:39PM +0200, Manuel Bouyer wrote:
> > With your last changes, things are much better now:
> > /usr/bin/time fssconfig fss0 /home /home/snaps/snap0
> >       149.85 real         0.00 user         1.16 sys
> > /home: suspended 0.040 sec, redo 0 of 2556
> > /usr/bin/time fssconfig fss1 /home /home/snaps/snap1
> >       227.49 real         0.00 user         1.90 sys
> > /home: suspended 0.040 sec, redo 0 of 2556
> > /usr/bin/time fssconfig fss2 /home /home/snaps/snap2
> >       263.58 real         0.00 user         2.97 sys
> > /home: suspended 0.040 sec, redo 0 of 2556
> > /usr/bin/time fssconfig fss3 /home /home/snaps/snap3
> >       353.23 real         0.00 user         3.88 sys
> > /home: suspended 0.040 sec, redo 0 of 2556
> > 
> > Taking a snapshot will still probably require a lot of time on
> > large filesystems with a dozen snapshots, but at last the server
> > won't hang for a long time.
> > thanks !
> 
> Not really.  Any thread ending up in ffs_copyonwrite() or ffs_snapblkfree()
> will block.  If this server runs NFS it could be possible that all NFS
> server threads block.

Oh - I might have seen this on Monday - 5.99.47 on sparc64. All I saw
was [tstile], and the quickest way out after a couple of minutes was to
hard reboot the machine and let wapbl / fsck sort it out - and to move
back to the pre-snapshot rsync script.

Sorry, no core dump.

Regards,
        -is