Date: Tue, 30 Sep 2003 18:42:21 -0300 (ADT) From: "Marc G. Fournier" <scrappy@hub.org> To: freebsd-current@freebsd.org Subject: Improvements to fsck performance in -current ...? Message-ID: <20030930183437.Y94686@ganymede.hub.org>
next in thread | raw e-mail | index | archive | help
Due to an electrician flipping the wrong circuit breaker this morning, I had my servers go down hard ... they are all -STABLE, with one of the four taking a *very* long time to fsck: jupiter# ps aux | grep fsck root 361 99.0 2.3 95572 95508 p0 R+ 4:21PM 121:13.21 fsck -y /dev/da0s1h jupiter# date Tue Sep 30 18:37:02 ADT 2003 jupiter# Now, CPU time is rising, so I figure its still working away, and fsck shows: jupiter# fsck -y /dev/da0s1h ** /dev/da0s1h ** Last Mounted on /vm ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts so it isn't finding any errors ... A friend of mine asked if we had a journalling file system, which I told him know, as I don't believe we do ... but are/have there been any improvements to fsck in -CURRENT to improve performance on large file systems (this is a 6x36G RAID5 system)? Does UFS2 address any of this? I've actually had a 6x18gig RAID5 file system once take 11+hrs to fsck ... and when it was completed, everything seemed fine, with no reports of any file or directory corruption ... it obviously did a good job of checking the file system, just hate the lengthy downtime ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030930183437.Y94686>