From: "Wesley J. Landaker" <wjl@icecavern.net>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org
Subject: Re: git fsck not identifying corrupted packs
Date: Tue, 20 Oct 2009 10:20:18 -0600 [thread overview]
Message-ID: <200910201020.18676.wjl@icecavern.net> (raw)
In-Reply-To: <200910201741.50764.robin.rosenberg@dewire.com>
On Tuesday 20 October 2009 09:41:50 Robin Rosenberg wrote:
> måndag 19 oktober 2009 21:27:48 skrev Wesley J. Landaker:
> > (Not CCing everyone, since this is mostly curiosa in the "using git as
> > it was never intended" section):
[...]
> > Filesystems are mostly reliable, but only until your crazy users do
> > strange and terrible things. I have a real, non-toy environment where I
> > use this stack as a [horrible] workaround for some issues beyond my
> > control:
> >
> > git -> ext4 -> lvm -> dmcrypt -> loop -> sshfs -> cygwin sshd -> SMB
> > share
My main point was to illustrate that having "git fsck" do a REALLY GOOD
CHECK is still desirable, as we still haven't reached the days of file-
system utopia where nothing ever gets corrupted (even with a smaller,
simpler stack).
The actual application where I use this stack is because of odd requirements
and circumstances like data must be physically stored on a particular
Windows server on the network that uses a weird authentication method that
samba doesn't support, and it has to go over the network encrypted anyway,
there are lots of holes in the data, so I want ext4 for the extent support,
file-size limitations on the target, etc.
It's a really an exotic love-hate mix between an off-by-one-please-no-never-
again kind of situation coupled with a bit of "because I can".
> The obvious follow up question here is: Why?
If you are both nerdy and morbidly curious enough to care, send me a "but,
no ... really, WHY?!" with the git list CC dropped and we can talk about
details and/or other crazy stuff. (I don't want to get wildly off-topic on
this list.)
next prev parent reply other threads:[~2009-10-20 16:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 7:56 git fsck not identifying corrupted packs Sergio Callegari
2009-10-19 9:11 ` Johannes Sixt
2009-10-19 10:04 ` Johannes Schindelin
2009-10-19 19:03 ` Junio C Hamano
2009-10-19 19:27 ` Wesley J. Landaker
2009-10-20 15:41 ` Robin Rosenberg
2009-10-20 16:20 ` Wesley J. Landaker [this message]
2009-10-20 6:26 ` Matthieu Moy
2009-10-20 6:45 ` Junio C Hamano
2009-10-20 9:25 ` Alex Riesen
2009-10-20 10:22 ` Johannes Schindelin
2009-10-20 11:56 ` Matthieu Moy
2009-10-20 18:46 ` [RFC/PATCH] fsck: default to "git fsck --full" Junio C Hamano
2009-10-20 19:00 ` Nicolas Pitre
2009-10-20 19:11 ` Junio C Hamano
2009-10-20 18:39 ` git fsck not identifying corrupted packs Nicolas Pitre
2009-10-20 20:49 ` Alex Riesen
2009-10-19 10:56 ` Sergio Callegari
2009-10-19 19:07 ` Wesley J. Landaker
2009-10-20 6:24 ` Matthieu Moy
2009-10-19 18:36 ` Gabor Gombas
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=200910201020.18676.wjl@icecavern.net \
--to=wjl@icecavern.net \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg@dewire.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.