Improvements to fsck performance in -current ...?

From: Marc G. Fournier <>
Date: Tue, 30 Sep 2003 18:42:21 -0300 (ADT)
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

Now, CPU time is rising, so I figure its still working away, and fsck

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 ...
Received on Tue Sep 30 2003 - 12:43:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:24 UTC