On Mon, Feb 07, 2000 at 03:22:55PM +0000, Riley Williams wrote:
> Hi Stephen.
>
> >>> Probably it is too late for 2.4.0, but beyond that the answer is
> >>> yes only if somebody takes on the job of getting it in shape: is
> >>> e2compr still being maintained, and is there a robust 2.3
> >>> version?
>
> >> No idea re a robust 2.3 version, but I'm using the 2.2 version
> >> atm, and that appears to be rock solid.
>
> > We still get problem reports trickling in for e2compr. It doesn't
> > appear to be quite 100% solid just yet.
>
> Do you have any of the problem reports to hand? If so, let me have
> them and I'll see if I can sort out what the problems are, and also
> how to fix them.
Well, we've used it for years now on our "backup" server (big SCSI
software RAID with ext2 compressed filesystem). Every night it copies in
parallel from every server with "cpbk" (so it can only update what is
needed), and then every so often we dump the whole thing to tape. It has
been _very_ nice for us, and we've never really had any problems with it
other than there seems to be some sort of race/locking problem that
causes these messages many times during a backup run:
Jan 26 07:21:11 alfie kernel: Whoops: end_buffer_io_async: async io complete on unlocked page
Jan 27 02:27:41 alfie kernel: Whoops: end_buffer_io_async: async io complete on unlocked page
Jan 28 03:34:44 alfie kernel: Whoops: end_buffer_io_async: async io complete on unlocked page
We have yet to find any corruption related to this problem (although
there may be some). There has never been a problem where we can't
restore something we need (and we have, many times :) ). It's really
nice being able to just copy it back to the server with scp. It only
needs about half of the number of hard drives as in all of the other
servers to store the backup, too.
The backup server is a single processor PII 350 with 128 MB of RAM.
Interactive performance is horrible when copying from the 33 servers in
parallel, but it's nice this way as all of the servers get a little
strain throughout the whole backup rather than each one getting heavily
strained for a short time.
Simon-
[ Stormix Technologies Inc. ][ NetNation Communcations Inc. ]
[ sim@stormix.com ][ sim@netnation.com ]
[ Opinions expressed are not necessarily those of my employers. ]
-
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/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:15 EST