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