git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, David Kastrup <dak@gnu.org>
Subject: Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
Date: Fri, 03 Aug 2007 10:20:43 +0200	[thread overview]
Message-ID: <200708031020.43492.johan@herland.net> (raw)
In-Reply-To: <7v3az1samx.fsf@assigned-by-dhcp.cox.net>

On Friday 03 August 2007, Junio C Hamano wrote:
> David Kastrup <dak@gnu.org> writes:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >>  * With -l, as long as the source repository is healthy, it is
> >>    very likely that the recipient would be, too.  Also it is
> >>    very cheap.  You do not get any back-up benefit.
> >
> > Oh, but one does: an overzealous prune or rm -oopswrongoption in one
> > repo does not hurt the other.
> 
> That's not "back-up" benefit I was thinking about.  It is more
> about protecting your data from hardware failure.

If one is serious about backing up ones repo to protect it from hardware 
failure, there is not much use at all in cloning (by copy, hardlink, or 
otherwise) to a different location on the _same_ filesystem. In order for a 
backup to be at least marginally useful, it should be on a different disk 
drive (which you hint at below), or even better; on a different 
continent...

My point is as follows: One has to clone a repo onto (at least) a different 
filesystem if one is serious about backup. But if one is cloning to a 
different filesystem, hardlinking is no longer an option; git _has_ to make 
a copy of some sort. Therefore we might as well hardlink as long as we're 
on a single filesystem (since the extra copy would not be worth much, 
backup-wise).

> You physically have bits in two places, preferrably on separate disk
> drives.
> And that is what you do not get from hardlinked clone.

If the two copies are on separate disk drives (i.e. separate filesystems), 
you cannot make a hardlink in the first place. If the two copies are on the 
same filesystem, they're not much more worth than a single copy 
(backup-wise).

Given the clone-to-same-filesystem(-with-hardlink-capability) scenario 
(which is the only scenario where we have the option of using hardlinks), 
we have the following pros and cons when using hardlinks instead of 
copying:

Pros:
- Hardlink is _much_ faster (for big repos, we're talking orders of 
magnitude faster)

Cons:
- Hardlink will not leave two copies on the disk. But I'm arguing that the 
additional copy will have pretty much _no_ value from a redundancy POV, 
since the copy is still left on the _same_ filesystem. Some would even go 
as far as to say that the second copy provides a false sense of security as 
long as it is located on the same filesystem.


Have fun!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

  parent reply	other threads:[~2007-08-03  8:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-01  0:16 Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial Jakub Narebski
2007-08-01  2:14 ` Linus Torvalds
2007-08-01  5:50   ` Junio C Hamano
2007-08-01  8:48     ` David Kastrup
2007-08-01  9:24     ` Theodore Tso
2007-08-01 10:15       ` Junio C Hamano
2007-08-01 13:20         ` Alex Riesen
2007-08-01 13:20           ` Alex Riesen
2007-08-01 13:23             ` Alex Riesen
2007-08-01 15:49         ` Carl Worth
2007-08-01 17:03           ` Linus Torvalds
2007-08-01 18:17             ` David Kastrup
2007-08-01 20:36               ` Florian Weimer
2007-08-02  6:09             ` Junio C Hamano
2007-08-02 10:29               ` David Kastrup
2007-08-03  0:51                 ` Junio C Hamano
2007-08-03  6:14                   ` David Kastrup
2007-08-03  8:20                   ` Johan Herland [this message]
2007-08-01 22:03         ` Theodore Tso
2007-08-01 22:49           ` Brandon Casey
2007-08-02  4:02           ` Allan Wind
2007-08-02  4:13             ` Linus Torvalds
2007-08-01 22:18         ` Jakub Narebski
2007-08-02 11:19           ` Jakub Narebski
2007-08-02 18:08         ` Ramsay Jones
2007-08-01  8:33   ` Jakub Narebski
2007-08-01  8:48     ` Junio C Hamano
2007-08-01 23:51       ` Jakub Narebski
2007-08-01  2:17 ` Shawn O. Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200708031020.43492.johan@herland.net \
    --to=johan@herland.net \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).