On Wed, Aug 18, 2010 at 02:20:13PM -0600, Andreas Dilger wrote:
>
> Ah, that is also a major user of memory, and not necessarily one
> that optimizing the internal bitmap will help significantly. It may
> well be that your swap cannot be used if a single allocation is in
> the same neighbourhood as the total RAM size.
Something which *might* help (but will take a long time) is to add to
your /etc/e2fsck.conf (if you have one; if not create one wiht these
contents):
[scratch_files]
directory = /var/cache/fsck
(And then make sure /var/cache/fsck exists.)
Unfortunately, as it turns out tdb (from Samba) doesn't scale as much
as I would have liked, so it's on my todo to replace this with
something else. The problem with that berk_db has non-standard
interfaces and varies from version to version. So I've avoided using
it up until now.
But try it, and see if this will help.... it may still be way too
slow.
A related blog entry:
http://thunk.org/tytso/blog/2009/01/12/wanted-incremental-backup-solutions-that-use-a-database/
- Ted
P.S. I recently was told about a new backup system that meets the
requirements detailed in my post:
http://sites.google.com/site/hashbackup/home/features
I haven't tried it yet, but it looks interesting. Let me know if you
do try it and what you think of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
