On 08/16/2014 01:17 PM, Ivan Shapovalov wrote:
On Saturday 16 August 2014 at 10:09:44, Edward Shishkin wrote:
On 08/16/2014 02:44 AM, Ivan Shapovalov wrote:
On Monday 11 August 2014 at 13:39:12, Ivan Shapovalov wrote:
[...]
I've meant "grabbing all space and then allocating all space" -- so there won't
be multiple grabs or multiple atoms.
Then all processes grabbing space with BA_CAN_COMMIT will wait for the discard
atom to commit.
It seems such waiting will screw up the system. No?
I was afraid of such situations, but how would that happen? The discard atom's
commit will always be able to proceed as it doesn't grab space at all.
(Actually, there is a small race window between grabbing space
and creating an atom...)
Which one?
BA_CAN_COMMIT machinery does wait only for atoms, not for contexts. If
process X happens to grab space between us grabbing space and creating an atom,
it will get -ENOSPC even with BA_CAN_COMMIT.
I still don't see any "races" here. How atom creation is related to grabbing
space? Are we talking about races in the existing code? f so, please show
the racing paths..
Well, this is not a race per se - it does not involve locking. But it is
a race-like behavior.
taskA taskB
--------------------------------------------------------------------------
grab very much space
Ok, assume A wants X blocks.
grab some space with BA_CAN_COMMIT
Assume B wants Y blocks.
create an atom using the grabbed space
Please, specify which code is executing at this point.
Anyway, we don't need any reservation to _create_ an atom.
Reservation is expended when allocating blocks on the low level
(bitmaps). Reservation (grabbing space) is needed to avoid hard
ENOSPC (=no free bits in bitmaps) in situation, when we can not
fail (e.g. flush, commit, etc..,)
In this case, the taskB's grab will fail though it could wait for taskA's
not yet created atom.
I still don't see why somebody should fail if X+Y < free-space-on-disk.
If X+Y > free-space, then yes, someone will fail, and it is correct.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
