Lots of people seem to be concerned that fsck is taking longer and longer as disks get larger and larger, but one thing that already is starting to be painful, that isn't mentioned so often, is creation of that filesystem in the first place.

Whilst mkfs should happen a lot less often than fsck's, mkfs of a 0.5TB ext3 filesystem on a 3 disk raid5 array already has me sitting around twiddling my thumbs. When we get to multi-terabyte disks, I might as well go shopping.

I wonder if something along the lines of chunkfs is perhaps the answer, where you mkfs chunks as you go along.

Talking with quite a few people at OLS last week, it seems there are still quite a few misconceptions about just how patched various kernels were throughout the history of Red Hat. One particularly egregious statement I heard was "Early Red Hat kernels had ~2000 patches".

Here's some hard facts on exactly how many patches were in each release.
(I don't have access to earlier kernels than these, but < RHL6, those kernels were probably even less patched).
Caveats:

• All stats are based on the last state that CVS was in when I ran the grep ^%patch *.spec | wc -l so may not match the kernel that ended up on the ISO for that release.
  
• Some releases contain -ac patches, which are roll-ups, sometimes of dozens of patches.
  In later releases, this practise has been deprecated (and also Alan rarely does -ac releases any more).
  

Release	Number of patches	Version
Red Hat Linux 7.0	70	2.2.24 !
Red Hat Linux 7.1	118	2.4.20
Red Hat Linux 7.2	118	2.4.20
Red Hat Linux 7.3	120	2.4.20
Red Hat Linux 8	117	2.4.20
Red Hat Linux 9	143	2.4.20

Wow, that takes me back. As the version number shows, these releases were all more or less the same kernel.
The big difference was RHL9 had nptl, and a few other 2.6 backports. These were pretty invasive patches.

Release	Number of patches	Version
Fedora Core 1	105	2.4.22
Fedora Core 2	78	2.6.10
Fedora Core 3	108	2.6.12
Fedora Core 4	85	2.6.17
Fedora Core 5	145	2.6.20
Fedora Core 6	191	2.6.20
Fedora 7	164	2.6.21
Fedora 8-devel (rawhide)	63	2.6.22-rc7

A few interesting points on the Fedora kernels.

• FC1 never rebased off of its original kernel, so there were quite a few > 2.4.22 patches backported to that.
  It still had nptl etc from RHL9, so rebasing was painful back then.
  
• FC5 & FC6 have quite high patchcounts, because currently they've stopped following mainline.
  After seeing the fallout from 2.6.21 during F7's development, we decided to skip a release, and hope that .22 works out to be better. When we rebase, approximately half those patches go away.
  
• F7 is carrying quite a few patches that really should get pushed through -stable. Some of them may even be pending inclusion. Lots of them are backports from 2.6.22-rc
  
• rawhide is still quite high. I need to do a patch bombing soon to try and get a bunch of the bits we're carrying pushed upstream. Should be able to get this back under 50 when the merge window opens up for 2.6.23
  

Now the fun ones..

Release	Number of patches	Version
AS 2.1	487	2.4.9
AS 2.1 (ia64)	272	2.4.18
RHEL3	395	2.4.21
RHEL4	1078	2.6.9
RHEL5	881	2.6.18

So over time, RHEL releases accumulate lots of patches. The pain-point of not rebasing means they tend to build up over time. RHEL4 being the 'winner', picking up just over a thousand patches in 2.5 years, though RHEL5 is catching up fast, nearly reaching that number already, after being released earlier this year.
This acceleration of patches may be related to the fact that upstream is moving a lot faster than it was around the time of earlier releases. We're finding and fixing a lot more stuff, a lot faster, and the upstream process seems to show no signs of slowing down (if anything, people are trying to make it go faster).

So, despite the claim that "Red Hat had thousands of patches" isn't true today, it might not be true once we freeze a future RHEL release.