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. 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
