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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).