All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>
Cc: reiserfs-devel@vger.kernel.org
Subject: Re: [PATCH 2/2] reiser4: block_alloc: get rid of discard-related hack in reiser4_dealloc_blocks().,
Date: Sun, 07 Sep 2014 14:06:21 +0200	[thread overview]
Message-ID: <540C4A3D.6090404@gmail.com> (raw)
In-Reply-To: <2475166.I97gbrPMvH@intelfx-laptop>


On 09/06/2014 12:33 PM, Ivan Shapovalov wrote:
> On Sunday 31 August 2014 at 23:19:10, Edward Shishkin wrote:	
>> On 08/18/2014 01:31 PM, Ivan Shapovalov wrote:
>>> When discard was enabled, immediate deallocations were made deferred in order
>>> to record these extents in the atom's delete set and, consequently, allow
>>> their discarding.
>>>
>>> However, this is wrong in the following way. Immediate deallocations make use
>>> of target allocation stage and ancillary flags like BA_PERMANENT and BA_FORMATTED.
>>> By converting immediate deallocations to deferred, these flags are essentially
>>> dropped, and application of deferred deallocations in reiser4_post_write_back_hook()
>>> uses an equivalent of BLOCK_NOT_COUNTED stage and BA_FORMATTED flag.
>>>
>>> Dropping this hack does not hinder efficiency of the discard procedure, because
>>> immediate deallocations are now used only to deallocate "just allocated" and not
>>> yet written blocks, which actually do not need to be discarded.
>>
>> The idea to defer every "successful" deallocation regardless of discard
>> support status looks OK, but I don't like the first patch (1/2), so
>> let's try
>> to improve it..
>>
>> So, we want to defer also deallocations in the following 2 places:
>> 1) in  dealloc_tx_list();
>> 2) in dealloc_wmap_actor().
>>
>> Here we should take care about block stages.
>> Let's take a look where and how they were allocated. There are exactly
>> 2 places:
>>
>> a) in get_more_wandered_blocks() with block_stage = BLOCK_GRABBED;
>> b) in alloc_tx() with block_stage = BLOCK_GRABBED.
>>
>> Note, that alloc_blocks() with the stage BLOCK_GRABBED calls
>> grabbed2used(). This is exactly what we want in apply_dset() called by
>> post_write_back_hook.
>>
>> That is, just adding BA_DEFER to (1) and (2) with the patch 2/2 should work.
>> Please, make sure..
> This patchset does it exactly this way.
>
> The first patch does two things:
> - adds BA_DEFER to deallocations in dealloc_tx_list() and dealloc_wmap_actor()
>    (because we really want them deferred);
> - removes BA_FORMATTED from where BA_DEFER is used
>    (this is the thing you don't like).
>
> Let me explain why I've done the second thing. When BA_DEFER is specified,
> BA_FORMATTED is not checked for (there are even no assertions). While it may be
> semantically correct to specify BA_FORMATTED as well in these cases, it is not
> checked for and thus sooner or later we'll get a case when BA_FORMATTED flag is
> missing, and no one will notice that (because it does not influence the system
> behavior). So I've decided to force-expire that moment and preemptively remove
> the flags :)
>
> Of course, you are the maintainer. If you opt for keeping BA_DEFER | BA_FORMATTED
> combination, let's do it this way (but then it would sense to add an assertion).


It can happen, that we'll use BA_FORMATTED flag in deferred deallocations.
So I suggest to not touch it..


>
>> P.S. In (1)-(2) we allocate with stage BLOCK_GRABBED, but in (a)-(b) we
>> deallocate with stage BLOCK_NOT_COUNTED. It can confuse. Let's allocate
>> with stage BLOCK_NOT_COUNTED: from the standpoint of alloc_blocks() it
>> doesn't matter.
> This would be incorrect. The space for allocations in get_more_wandered_blocks()
> and alloc_tx() is already grabbed at the beginning of commit_tx() (see wander.c:1103),
> so these allocations have to be done with stage == BLOCK_GRABBED.


Ok, agreed..

Thanks,
Edward.

      reply	other threads:[~2014-09-07 12:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-18 11:31 [PATCH 0/2] reiser4: block deallocation fixes Ivan Shapovalov
2014-08-18 11:31 ` [PATCH 1/2] reiser4: sanitize deallocations throughout the code Ivan Shapovalov
2014-08-31 11:24   ` Edward Shishkin
2014-09-01 13:24     ` Ivan Shapovalov
2014-08-18 11:31 ` [PATCH 2/2] reiser4: block_alloc: get rid of discard-related hack in reiser4_dealloc_blocks() Ivan Shapovalov
2014-08-31 21:19   ` Edward Shishkin
2014-09-06 10:33     ` [PATCH 2/2] reiser4: block_alloc: get rid of discard-related hack in reiser4_dealloc_blocks()., Ivan Shapovalov
2014-09-07 12:06       ` Edward Shishkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540C4A3D.6090404@gmail.com \
    --to=edward.shishkin@gmail.com \
    --cc=intelfx100@gmail.com \
    --cc=reiserfs-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.