On 07/20/2014 02:33 PM, Edward Shishkin wrote:
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.
Actually, this is not so simple. E.g. I got a deadlock..
Another option is to make head/tail paddings dirty with the
following update of the extent of the delete_set.
One more option is to not support such discard params.
Edward.
--
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
