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
I wouldn't be that memory corruption bug (that was introduced in 2.0.33)
by any chance? I had problems with it myself when my squid server hit
the end of memory. (I'd selected too large a disk-cache for the amount
of memory I had available: 6GB of ram, but only 64MB of memory).

That neatly crashed the server at all-too-frequent intervals. I added
memory, which fixed it, and more recently backed down to 2.0.32.

D


Benjamin C.R. LaHaise wrote:
>
> 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

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@
------END GEEK CODE BLOCK------

-
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.075 / U:0.732 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site