repair.strip and backups
mpm at selenic.com
Wed Aug 11 07:37:59 CDT 2010
On Wed, 2010-08-11 at 15:30 +0300, timeless wrote:
> On Wed, Aug 11, 2010 at 6:06 AM, Nicolas Dumazet <nicdumz at gmail.com> wrote:
> wrt strip artifacts, i sometimes need one of the bundles, and on rare
> occasions i think i want the one that went away. i know there was a
> time when i used to get both. but i can't remember what i was doing
> when i wanted this stuff, so that's not the point of this message.
> > == Compression ==
> > repair._bundle uses by default BZ2 compression.
> > For "full bundles", it makes sense, as those are likely to be kept
> > around. But partial bundles are temporary, merely an internal detail.
> > Compressing takes time when bundling, and needs time when unbundling.
> > I think that in ALL and NONE cases, where temp bundles are not kept, we
> > could get rid of compression, speeding up the related commands.
> > I have a patch doing this. Any comments?
> Sometimes compression is actually cheaper than disk i/o.
> This is going to depend on the individual file system (we can call
> this a repository i guess). But it will typically be fixed for a given
> user or install.
> Bad example:
> wam.umd.edu is part of /afs/umd.edu/
> on an average box there, you had:
> /tmp <ram disk = very fast> ~4gb
> ~ <afs = slow> ~25mb (in 1998)
> the computer itself was "fast", so compression for ~ made sense
> because reading/writing over the wire to reach ~ was more expensive
> than the cost for compression. for /tmp, compression mostly didn't
> make sense except to the extent that space used by /tmp competed w/
> space for other applications.
On a system with write-back cache, if we make things faster, we might
avoid the data ever hitting the disk.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel