Messages in this thread | | | Date | Mon, 7 Feb 2000 11:05:06 -0500 | From | Simon Kirby <> | Subject | Re: 2.4 Features |
| |
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/
| |