2.0 upgrade experiences

[Robert Collins]

On Thu, 2009-08-13 at 10:31 +1000, Andrew Cowie wrote:
> On Wed, 2009-08-12 at 07:36 +1000, Robert Collins wrote:
> > You will have content in .bzr/repository/obsolete-packs that will get
> > cleaned up when you make subsequent commits. We do this to deal with
> > various edge cases without requiring fsync/fdatasync operations (which
> > are either a) expensive, or b) [on XFS and MacOSX] don't work).
> 
> So I get why you have to do this on broken platforms, but why oh why are
> those of us running good operating systems penalized for it?

See under 'userspace file system barriers'. The basic goal is this: keep
the data that has been saved by you available. When we combine
previously saved data into new files and discard the files, there is the
opportunity for race conditions. If we could express to the file system
'all the operations I've done so far must hit disk before any of the
operations I'm about to do now hit disk', then we could do this very
simply:
write new files
fbarrier()
write new root node
fbarrier()
delete old files

And - I'd be extremely happy to write the alternate code path to do this
conditionally based on having such a syscall available. It would improve
robustness well over what we have today and not cause unnecessary disk
IO when on the train.

The problem though, is that Linux is one of the broken platforms.
http://lwn.net/Articles/326471/. Linus doesn't like fbarrier - but note
that git also doesn't fsync.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090813/d375824a/attachment.pgp