On 07/20/2014 12:06 PM, Ivan Shapovalov wrote:
20 июля 2014 г., в 1:20, Edward Shishkin <edward.shishkin@xxxxxxxxx> написал(а):
On 07/14/2014 03:56 AM, Edward Shishkin wrote:
On 07/13/2014 09:18 PM, Ivan Shapovalov wrote:
[...]
Nothing seems to call at least check_free_blocks(begin, end)...
Oh, bad... I thought all this time that extents of the delete sets are still dirty
in the working bitmap at the moment of discard.
Hmm, I definitely don't want to check the whole extents for discard...
False alarm, actually..
Nothing is wrong if someone makes them dirty before issuing our discard
requests: his changes will be committed in the next sessions of possessing
the commit_mutex _after_ our discard. Everything is isolated.. For the same
reason we don't care if someone allocate blocks in head and tail paddings
before issuing our padded discard extents.
I was just thinking about the very same possible race...
But well, isn't the call to current_atom_complete_writes() placed before acquisition of commit_mutex? I was under impression of that relocate sets could be written while another atom is being committed under the mutex.
take the commit_mutex before flush if discard_enabled && should_check_heads.
--
Ivan Shapovalov / intelfx /
(Sent from a phone. Havoc may be wreaked on the formatting.)
We only need to make sure that
they were clean at _our_ commit session.
Anyway, let's use delayed deallocation. I like it better than aux_delete_set.
After all, we can roll everything back at every moment, if any problems..
Edward.
--
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
