From: Linus Torvalds <torvalds@osdl.org>
To: Git Mailing List <git@vger.kernel.org>
Subject: Careful object writing..
Date: Tue, 3 May 2005 12:15:08 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0505031204030.26698@ppc970.osdl.org> (raw)
I just pushed out the commit that tries to finally actually write the sha1
objects the right way in a shared object directory environment.
I used to be lazy, and just do "O_CREAT | O_EXCL" on the final name, but
that obviously is not very nice when it can result in other people seeing
objects that haven't been fully finalized yet.
So now I do it "right", and create a temporary file in the "top" object
directory, and then when it's all done, I do a "link()" to the final place
and unlink the original.
I also change the permission to 0444 before it gets its final name.
Two notes:
- because the objects all get created initially in .git/objects rather
than in the subdirectory they get moved to, you can't use symlinks
to other filesystems for the 256 object subdirectories. The object
directory has to be one filesystem (but it doesn't have to be the same
one as you actually keep your working ddirectories on, of course)
- The upside of this is that filesystem block allocators should do the
right thing. Instead of spreading the objects out (because they are in
different directories), they should be created together.
Anyway, somebody should double-check the thing. It _should_ now work
correctly over NFS etc too, and everything should be nice and atomic (and
with any half-way decent filesystem, it also means that even if you have a
system crash in the middle, you'll never see half-created objects).
NOTE NOTE NOTE! I have _not_ updated all the helper stuff that also write
objects. So things like "git-http-pull" etc will still write objects
directly into the object directory, and that can cause problems with
shared usage. Same goes for "write_sha1_from_fd()" that rpull.c uses. I
hope somebody will take a look at those issues..
Anyway, at least the really core operations should now really be
"thread-safe" in a shared object directory environment.
Linus
next reply other threads:[~2005-05-03 19:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-03 19:15 Linus Torvalds [this message]
2005-05-03 19:27 ` Careful object writing Chris Wedgwood
2005-05-03 19:47 ` Linus Torvalds
2005-05-03 19:47 ` Chris Wedgwood
2005-05-03 19:56 ` Linus Torvalds
2005-05-03 20:02 ` Daniel Barkalow
2005-05-03 20:00 ` Jan Harkes
2005-05-03 20:11 ` Linus Torvalds
2005-05-03 20:59 ` Jan Harkes
2005-05-03 22:13 ` Linus Torvalds
2005-05-03 22:37 ` Linus Torvalds
2005-05-03 22:40 ` H. Peter Anvin
2005-05-03 23:04 ` Alex Riesen
2005-05-03 23:22 ` Linus Torvalds
2005-05-03 23:25 ` Alex Riesen
2005-05-03 23:22 ` Junio C Hamano
2005-05-04 4:07 ` [PATCH] Careful object pulling Daniel Barkalow
2005-05-04 9:35 ` Morten Welinder
2005-05-04 16:16 ` Daniel Barkalow
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=Pine.LNX.4.58.0505031204030.26698@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
/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).