lkml.org 
[lkml]   [1998]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Improving Ext2 Reliability
On Mon, 13 Apr 1998, Jordan Mendelson wrote:

[snip -- squid + 9 gig cache fs]

> Is there anything I can do to improve this? 30 minutes seems like an
> eternity for such an important service.

Given the nature of the data you're caching, the fact that you're allowing
fsck to blindly proceed with duplicating blocks is a disaster for your
users. Unless you can verify the integrity of the data stored in the
cache after an fsck (you should with, say, rpm for any executables that
fsck notes a fix with, or manual inspection for user data), just plain
toss the filesystem with mke2fs -- short sweet and painless for cache data
that's not cleanly unmounted.

Aside from your specific case, methinks there are several people working
on alternative fs's or even adding log extensions to ext2. (Personally,
I've been tinkering with the design of something off and on, but haven't
written the code for it yet...)

Yet-another alternative suggestion if you want to keep the data intact:
nfs and a pair of 100 mbps ethernet cards using a cross-over cable. The
disk server should never go down with users unable to attack it.

One question: why is your squid box crashing? If it's a kernel problem,
then we'd *really* like to know the details (esp Alan as he's doing a
great job of keeping track of 2.0 bug reports).

-ben


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.423 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site