Re: ffs snapshots patch
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 ! -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: ffs snapshots patch
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. -- Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: ffs snapshots patch
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
Re: ffs snapshots patch
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 NetBSD: 26 ans d'experience feront toujours la difference --
Re: reading non-standard floppy formats
On Thu, Apr 28, 2011 at 12:02:51PM +0200, Edgar Fu? wrote: > > Is there a saner way of reading non-standard (e.g., 10 sectors per track) > > floppies than either > > a) building a custom kernel with modified fd_types in sys/dev/isa/fd.c > > b) writing a user-space program that sets the appropriate parameters with > > FDIOCSETFORMAT and then, holding the device open, writes the raw floppy > > data to a file? > No-one? > > Does this mean there is no saner way or am I missing something so obvious > that no-one wants to answer? More likely than either: nobody knows. -- David A. Holland dholl...@netbsd.org
