| 2007-03-30 02:11:09 |
Martin Pool |
bug |
|
|
added bug |
| 2007-03-30 02:36:00 |
John A Meinel |
bzr: status |
Unconfirmed |
Confirmed |
|
| 2007-03-30 02:36:00 |
John A Meinel |
bzr: statusexplanation |
|
The error is at least improved with my patch to change "LockError" => "LockContention", which I've merged into both bzr.dev, and bzr-0.15.
I'm not sure what to do about the commit editor and such.
Things like this also happen if you do "bzr diff | less" with a large diff in one window, and "bzr add" in another.
To this point, read-locks have been a no-op, so it hasn't been a problem. |
|
| 2007-07-17 03:10:49 |
Martin Pool |
bzr: importance |
Undecided |
High |
|
| 2007-07-17 03:10:49 |
Martin Pool |
bzr: statusexplanation |
The error is at least improved with my patch to change "LockError" => "LockContention", which I've merged into both bzr.dev, and bzr-0.15.
I'm not sure what to do about the commit editor and such.
Things like this also happen if you do "bzr diff | less" with a large diff in one window, and "bzr add" in another.
To this point, read-locks have been a no-op, so it hasn't been a problem. |
|
|
| 2008-05-27 16:33:05 |
James Troup |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2009-03-03 04:22:29 |
Martin Pool |
description |
WorkingTree4 holds the dirstate lock while reading the commit message from the editor. So you can't run even readonly operations to see what it is going to be committed.
bzr: ERROR: bzrlib.errors.LockError: Lock error: [Errno 11] Resource temporarily unavailable
Traceback (most recent call last):
File "/home/mbp/lib/python/bzrlib/commands.py", line 638, in run_bzr_catch_errors
return run_bzr(argv)
File "/home/mbp/lib/python/bzrlib/commands.py", line 600, in run_bzr
ret = run(*run_argv)
File "/home/mbp/lib/python/bzrlib/commands.py", line 296, in run_argv_aliases
return self.run(**all_cmd_args)
File "/home/mbp/lib/python/bzrlib/commands.py", line 610, in ignore_pipe
result = func(*args, **kwargs)
File "/home/mbp/lib/python/bzrlib/builtins.py", line 1435, in run
old_label=old_label, new_label=new_label)
File "/home/mbp/lib/python/bzrlib/diff.py", line 357, in diff_cmd_helper
old_tree = tree.basis_tree()
File "/home/mbp/lib/python/bzrlib/workingtree.py", line 373, in basis_tree
revision_id = self.get_parent_ids()[0]
File "/home/mbp/lib/python/bzrlib/decorators.py", line 125, in read_locked
self.lock_read()
File "/home/mbp/lib/python/bzrlib/workingtree_4.py", line 562, in lock_read
state.lock_read()
File "/home/mbp/lib/python/bzrlib/dirstate.py", line 2216, in lock_read
self._lock_token = lock.ReadLock(self._filename)
File "/home/mbp/lib/python/bzrlib/lock.py", line 170, in __init__
raise errors.LockError(e)
LockError: Lock error: [Errno 11] Resource temporarily unavailable
bzr 0.16.0dev0 on python 2.5.0.final.0 (linux2)
arguments: ['/home/mbp/bin/bzr', 'dif']
** please send this report to bazaar@lists.ubuntu.com
/home/mbp/lib/python/bzrlib/lock.py:79: UserWarning: lock on <open file u'/home/mbp/bzr/hpss-faster-copy/.bzr/checkout/dirstate', mode 'rb' at 0x844f7b8> not released
warn("lock on %r not released" % self.f) |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
|
| 2009-03-03 04:22:29 |
Martin Pool |
title |
can't do readonly operations during a commit in a dirstate tree |
[MASTER] dirstate file write locks exclude readers and limit portability |
|
| 2009-03-03 04:26:05 |
Martin Pool |
description |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug, eg bug 305006
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
|
| 2009-06-22 04:13:07 |
Martin Pool |
description |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug, eg bug 305006
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug, eg bug 305006
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
* OS locks are not supported by Jython
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
|
| 2009-07-13 06:22:43 |
Martin Pool |
summary |
[MASTER] dirstate file write locks exclude readers and limit portability |
[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability |
|
| 2009-09-28 08:33:09 |
Robert Collins |
tags |
dirstate |
dirstate dirstate2 |
|
| 2009-09-29 05:26:26 |
Launchpad Janitor |
branch linked |
|
lp:~lifeless/bzr/dirstate2 |
|
| 2009-09-29 05:35:48 |
Robert Collins |
bzr: status |
Confirmed |
In Progress |
|
| 2009-09-29 05:35:51 |
Robert Collins |
bzr: assignee |
|
Robert Collins (lifeless) |
|
| 2010-06-24 06:43:36 |
Robert Collins |
bzr: assignee |
Robert Collins (lifeless) |
|
|
| 2010-06-24 06:54:52 |
Robert Collins |
description |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug, eg bug 305006
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
* OS locks are not supported by Jython
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
As of bzr 1.12 (and many previous versions) the dirstate working tree format uses an OS lock on the dirstate file. This was done so that we could safely make in-place updates to the dirstate file. Bzr also (and its tied to the OS lock usage) uses an edit-inplace approach to modifying the file.
However, this causes several problems:
* While the dirstate file is locked, it cannot be read: eg by info (bug 174055) or by diff
* OS locks don't work well on all platforms
* They are particularly problematic on network filesystems, which often don't have working file locking either inherently or because of a configuration problem, eg smb (bug 31006), AFP (bug 114528), nfs (bug 108605)
* OS lock behaviour varies between platforms therefore is harder to test and debug, eg bug 305006
* On some platforms, OS locks are implicitly shared across a process and this makes them harder to test and/or hides bugs
* OS locks can't be broken and don't show who is holding the lock
* OS locks are not supported by Jython
* When the disk is full or bzr crashes the dirstate file can be shorter than it should be.
All these bugs are collected into this one bug, as few of them can be fixed without fixing the OS lock issue, and fixing the OS lock issue will fix them all.
If the use of diff and stat while a commit editor is open is fixed in a different way - e.g. by a separate stat cache, then we can just modify this description to only list the remaining issues.
These bugs are somewhat distinct aspects so shouldn't be marked as dupes, but they can probably best be fixed together.
Totally fixing this requires changing the format not to rely on file locking, which requires a format that is safe if it is being read and written simultaneously. That format can't assume any particular behaviour if an attempt is made to rename a file while it's being read, because that can either fail, cause an error for the reader, or follow the rename, depending on the platform.
Some partial fixes may also be possible. |
|
| 2010-06-24 06:54:53 |
Robert Collins |
bzr: status |
In Progress |
Confirmed |
|
| 2010-08-21 22:03:01 |
Martitza |
bug |
|
|
added subscriber Martitza |
| 2010-09-23 21:05:41 |
Daniel Cordeiro |
bug |
|
|
added subscriber DanielCordeiro |
| 2010-11-09 21:02:44 |
Paul Sladen |
tags |
dirstate dirstate2 |
dirstate dirstate2 udd |
|
| 2011-02-07 07:52:20 |
Joseph Cassman |
removed subscriber joichiro |
|
|
|
| 2011-02-07 07:52:30 |
Joseph Cassman |
bug |
|
|
added subscriber joichiro |
| 2011-02-09 22:47:27 |
Sam Hartsfield |
bug |
|
|
added subscriber Sam Hartsfield |
| 2011-02-28 11:31:44 |
Francis Devereux |
bug |
|
|
added subscriber Francis Devereux |
| 2011-03-14 07:52:13 |
Matthew L Daniel |
bug |
|
|
added subscriber Matthew L Daniel |
| 2011-03-25 13:56:11 |
Arnaud Soyez |
bug |
|
|
added subscriber Arnaud Soyez |
| 2011-04-25 16:06:17 |
Danny van Heumen |
bug |
|
|
added subscriber Danny van Heumen |
| 2011-08-23 14:08:56 |
Eabin |
bug |
|
|
added subscriber Eabin |
| 2011-08-30 09:42:20 |
Eabin |
bug watch added |
|
http://bugzilla.kernel.org/show_bug.cgi?id=16277 |
|
| 2011-09-07 02:10:38 |
Bryce Harrington |
bug |
|
|
added subscriber Bryce Harrington |
| 2011-12-22 10:17:40 |
Bryce Harrington |
removed subscriber Bryce Harrington |
|
|
|
| 2012-03-20 19:26:49 |
cfidecaro |
bug |
|
|
added subscriber cfidecaro |
| 2012-03-20 19:26:56 |
cfidecaro |
removed subscriber cfidecaro |
|
|
|
| 2014-03-25 17:55:39 |
Harry Flink |
bug |
|
|
added subscriber Harry Flink |
| 2017-06-23 00:27:58 |
Jelmer Vernooij |
bug task added |
|
brz |
|
| 2017-06-23 00:28:11 |
Jelmer Vernooij |
brz: status |
New |
Triaged |
|
| 2017-06-23 00:28:16 |
Jelmer Vernooij |
brz: importance |
Undecided |
Low |
|
