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

Kevin Oberman wrote:
>>Date: Wed, 01 Oct 2003 06:39:47 +0000
>>From: Jens Rehsack <rehsack_at_liwing.de>
>>
>>Kevin Oberman wrote:
>>
>>[...]
>>
>>
>>>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.
>>
>>Be careful what you promise :-)
>>Most new disks have an own disk cache and some of them have a
>>write cache enabled. In case of a hardware failure (or power
>>failure) this data may get lost and the disk's metadata isn't
>>consistent. It's only when no write cache below the system
>>is active.

[...]

> But thanks for bringing this up as it is important. And, yes, it has
> burned me, although it required a confluence of things all going wrong
> at exactly the right timing to catch a bunch of metadata in cache.
> (This could only have happened on a CURRENT system back in the 5.0
> time frame.) It could only happen when the file system had been very
> active with an installworld. But it did happen.

It happens to me in another circumstance. On my fileserver
runs a portupgrade and during that something nasty fails.
I couldn't determine what, but nearly the complete /usr/,
/var/ and some of the /export/ data was lost+found :-)
/var and /usr could be restored, and the rest came from
backup or restored from lost+found, but it showed me the
end of disk caching.

> The trade-off is a big performance hit. With disk cache on, I can copy
> my entire FreeBSD partition to another disk in about 15 minutes. With
> disk cache off, it took a few HOURS. This was a worst case example
> with dd on my laptop (slow disks).

Here you should try to use other block sizes. Try it with smaller
ranges, eg. 100MB. The result may be best somewhere between
8192 and 65536 bytes per block.

Best regards,
Jens