lkml.org 
[lkml]   [1999]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: fsck is dead (was: Some very thought-provoking ...)
Date
From
Pete Zaitcev writes:
> >From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
> >Date: Mon, 21 Jun 1999 15:55:51 +0100 (BST)
>
> >Pavel Machek writes:
> >> Or 3 hours of power fault and 3 hours of fsck... Which is exactly what
> >> happens on ~100Gig disks.
> >
> >Please don't guess/exaggerate: I've already posted fsck benchmark
> >times to this mailing list a month ago. In particular, fsck for a
> >43 GB ext2 filesystem (4K blocks) with 30 GB in use took 13 minutes.
>
> I heard one interesting presentation by John Mashey which basically
> maintains that the capacity of disks increases its growth rate and
> grows faster than the disk interconnect speed and faster than CPU
> speeds. Disk capacities reached rate of 60% per annum.
>
> So in the long run you will not be able to do traditional fsck
> which scans a volume, which is O(capacity). Journal commit, which
> is O(outstaning_data_size) may be done if we constrain journal size
> growth rate. May be I am getting something wrong but this is how
> I see things.
>
> Pavel sounds non-scientific and guesses perhaps. But strangely enough
> he got it right. We are going to see 144GB disks in two years time.

He didn't get it right; he didn't make predictions about the future
ad neither did I. He said that ext2 fsck right *now* would take 3
hours for a 100GB filesystem. I replied saying that I'd benchmarked
it at 13 minutes for a 75% full 43GB filesystem (and I now have 4 such
filesystems attached to our mail server cluster). Within a year, I
expect to see journalling support for ext2. Within that year, I don't
expect any system crashes and, if there is a crash, I find 13 minutes
to be an acceptable fsck time given the other advantages of the Linux
mail cluster.

My point is that fsck is adequate right *now* for large file systems
in many situations. People shouldn't avoid rolling out systems with
large ext2 filesystems *now* because by the time disk sizes grow large
enough to make fsck infeasible, ext2 (or XFS or reiserfs or whatever)
will have journalling support. ext2 fsck speed is poor but it is
adequate. People who read his message and gave credence to his figure
of 3 hours (who may well have taken it is an "accepted", "proved"
data point) are are being done a disservice.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [from the cache]
©2003-2011 Jasper Spaans