>>     It's time to bite the bullet and admit that fsck is no longer
>>     scalable for modern storage capacities.
>
> To the extent that this statement is true, it's a statement about user
> expectations, not a statement about the technology.
>
> The time it takes to fsck a "big disk" now is approximately the time
> it took to fsck a "big disk" 10 years ago, and approximately the time
> it took to fsck a "big disk" 20 years ago: relevant speeds have kept a
> remarkably even pace with storage density.

Disk speeds haven't increased in a practical way in the past 5 years.
While 15K drives are available, they are not in common use due to cost
and noise+heat issues.  At best, some systems have 10K RPM disks, but
most only have 7200 RPM disks, if even that.  A fast drive 5 years ago
could sustain about 30MB/sec.  Now a fast drive can sustain 60-70MB/sec.
Of course, seek times are what really count, and the lack of significant
improvement in RPMs or head servos means that seek times have basically
stayed the same.  The only reason for any speedup is that more data is
packed into each track, and the drive makers have figured out cute ways
to beat the benchmarks at the expense of reliability.  And don't even
get me started on the death of SCSI and the speed advantage that tagged
queueing had; whether that actually gets resurrected in SATA2 or SAS is
anyone's guess.  Today's SATA drives might spin as fast as a SCSI drive,
but the difference in _real_ performance is significant.

Meanwhile, storage capabities have exploded.  5 years ago a mid-sized
drive was 18GB; now it's 80-100MB.  5 years ago, building a terabyte of
disk storage was possible but quite expensive and hard to do.  Now,
building 5TB of storage is trivial.  So capacities have basically gone
up 5x in 5 years, while speed has, at best, gone up 2.5x in five years.
And Hitachi just last week announced a new technology that will increase
densities not just 5x, but 10x in the next 5 years.  The prospects of
speed keep up with capacity doesn't look good, even if you factor in the
marginal improvements that hardware RAID caches give.

In any case, production systems cannot wait 1 or 2 or 3 hours for a fsck
to complete.  Embedded systems are even less tolerant of this; imagine
if suddenly pulling a power plug meant that you couldn't watch anything
on your Tivo for an hour, or your intelligent router couldn't route
packets for an hour.  Heck, even 5 minutes would be unacceptable.  Yes,
user perception in an important factor here, and it cannot be avoided.
Pining for the good old days of fast drum storage doesn't do anything to
address the problems now, unfortunately =-)

Scott