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