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.
hum, this is bad then, because a NFS server with home directories is seeing
mostly writes ...
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
