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/16/2014 12:23 PM, Edward Shishkin wrote:

On 07/15/2014 01:42 PM, Ivan Shapovalov wrote:
On Monday 14 July 2014 at 03:56:43, Edward Shishkin wrote:
[...]

Why not to delay the actual deallocation (in the working bitmap)?
Anyway, in the situations of disk space pressure (on the first "soft
ENOSPC")
everyone waits for commit-everything completion. Let's think in this
direction...
That's a good idea, actually. Let's outline what is needed for this:

- move reiser4_post_commit_hook() after the call to discard;


To be precise, not the post_commit_hook itself, only its current content.

Those hooks are undocumented, but I think that
- pre_commit_hook is something that should be called before journal
  writes;
- post_commit_hook is something that should be called after journal
  writes completion and before overwrites;
- post_write_back_hook is something that should be called after issuing
  the overwrites.

I suggest to use the post_write_back_hook for discard with the following
cleaning working bitmap. Move this hook to suitable place (make sure it is
after write_tx_back() and journal's "immediate" dealocations).


This will also move it outside of reiser4_write_logs(), after
reiser4_post_write_back_hook() and various immediate deallocations done by the
journal code. I suppose this is OK for we're under commit mutex anyway.

- defer journal's immediate deallocations until discard.

This is more interesting. Inside of the journal code, blocks are deallocated
in four places:
* dealloc_tx_list()
* dealloc_wmap() -> dealloc_wmap_actor()
* add_region_to_wmap() /* in error path */
* alloc_tx() /* seems like in error path, len == 0 in case of normal exit */

That is, blocks are deallocated after all meaningful work


We want those 4 deallocations to be after pre_commit_hook. In this
case they won't affect commit bitmap if we make them deferred.


  and so relative
order of these deallocations seems to not matter.

Given that point 1 is done, i. e. delete_set is applied to WORKING BITMAP after reiser4_write_logs(), we can simply make these deallocations deferred
(BA_DEFER flag). This way, we also get rid of aux_delete_set.


Yes, make reiser4_block_alloc() jump to "defer" branch if discard mode

^reiser4_block_alloc^reiser4_dealloc_blocks

is on.


The only thing to check is deallocation attributes. All journal's deallocations are done with target_stage == BLOCK_NOT_COUNTED. This happily coincides with
what's done in apply_dset(), so no problems here.

Is this correct?

Looks OK.

Thanks,
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