2.0 upgrade experiences

Robert Collins robert.collins at canonical.com
Thu Aug 13 06:59:08 BST 2009


On Thu, 2009-08-13 at 13:35 +0800, Martin Pool wrote:
> Also, it doesn't seem that unreasonable to me that rather than even
> try to work out when it is safe, we transiently use a bit more disk
> space that will later be collected.  So I think it's partly a problem
> of communication.  On the other hand if the behaviour is too
> complicated to explain in a single line, perhaps it must change.

I agree up to the single line heuristic :).

> In other words the user problem is not so much "help I'm out of disk"
> but "I thought this would shrink it but it grew, wtf?"

One thing we could do is delete the pack command.

> Also, the protection we get from doing this is somewhat idealistic.
> If your machine does crash and record an incoherent filesystem, it's
> probably not going to happen in a nice tidy way, but in a way that
> surprises bzr and makes it error.  There may be enough data there for
> a bzr developer to help you recover, but bzr won't always recover well
> itself.  At least some users will shrug and restore from backups, or
> just feel helpless.

While I agree our approach doesn't fix every case, I believe it catches
most of them. Machine crashes are actually pretty orderly, most of the
time. scribbling garbage over the FS is pretty rare. Things like power
failures though that will not complete operations (and with things like
data=writeback, which is roughly what ext4 turns on) operations can be
written to disk in fairly arbitrary orders - so the point that the
writes stopped at is hard to predict. All of which we try to accomodate
in our design - though I do have a few ideas for things we can tweak to
deal with even more edge-of-the-standard systems. We used to regularly
get NFS related data corruption bugs, where a workstation crash lead to
bad data on NFS - they have entirely (? perhaps not on dirstate, our
bad-boy remaining format) gone away.

-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/1d361fcc/attachment-0001.pgp 


More information about the bazaar mailing list