Re: Improvements to fsck performance in -current ...?

> Date: Tue, 30 Sep 2003 18:42:21 -0300 (ADT)
> From: "Marc G. Fournier" <scrappy_at_hub.org>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> 
> 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 ...

Current has two major changes re speeding up fsck.

The most significant is the background operation of fsck on file
system with soft updates enabled. Because of the way softupdates
works, you are assured of metadata consistency on reboot, so the file
systems can be mounted and used immediately with fsck started up in
the background about a minute after the system comes up.

Until fsck runs it is possible (likely) that some free blocks on the
filesystem amy be unavailable until the fsck completes, but that
should be the only issue.

The other issue is significant speedup in the time fsck takes to
run. On my little 30 MB /usr/partition it now takes only seconds to
fsck vs. about 2 minutes when I was running V4 on the system. On huge
system, I suspect the speedup is even more significant, but don't know
for sure.

I suspect that these enhancements may both require that soft updates
be enabled for the file systems.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634