Re: [PATCHv6 3/5] reiser4: discard support: initial implementation using linked lists.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux