From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>
Cc: ReiserFS development mailing list <reiserfs-devel@vger.kernel.org>
Subject: Re: [PATCH] reiser4: precise discard - general case
Date: Sun, 08 Mar 2015 23:43:28 +0100 [thread overview]
Message-ID: <54FCD090.3000005@gmail.com> (raw)
In-Reply-To: <3C7880EC-12E3-4621-A3BE-353EFA032293@gmail.com>
On 02/12/2015 07:14 AM, Ivan Shapovalov wrote:
>> You mean that sometimes we perform unneeded checks?
>> I see nothing criminal, as we don't exceed announced (2N_e)
>> number of checks, where N_e is number of extents in the
>> discard set.
>>> No, I didn't talk about that.
>>>
>>>> As to fixup: I think that we need to set up the local variable
>>>> head_is_known_dirty properly..
>>> Hmm, head_is_known_dirty is an optimization: either known dirty
>>> (in which case we skip checking and cut the head), or unknown
>>> (in which case we do the check).
>>>
>>> I'm talking about a different scenario:
>>> - tail padding of an extent is clean
>>> - head padding of the next extent is clean
>>> - these two paddings overlap in terms of disk blocks
>>>
>>> In this case, the head padding check will yield false ("dirty") because
>>> part of it has been already allocated for the tail padding, but in fact
>>> it is clean. Thus a false negative: the head will be cut while it can be
>>> padded.
>>
>> Ah, you suspect non-preciseness (leak of "garbage")?
>>
>> If tail padding of the current extent overlaps with the head padding of
>> the next extent, then the end of the current extent and the beginning
>> of the next extent are in the same erase unit. Otherwise we'll end with
>> contradiction. Correct?
> Correct, but I'm talking about a different situation where the end of the current extent and the beginning of the next extent are in distinct erase units but in the same disk block. Then we'll end up checking that disk block twice.
You correctly pointed out the possibility of garbage leak
in the case of block_size > erase_unit_size. However, the
current gluing policy prevents such leak.
Indeed, let AB be a current extent, and CD - next extent
----*-----*-----*-----*-----*-----*-----*---> units
--|-----------|-----------|-----------|-----> blocks
A B C D
Note that since extents are sorted and merged, distance
between any 2 extents are not smaller than block_size.
In particular, |BC| >= block_size. (1)
Suppose that tail padding of the current extent and head
padding of the next extent are in the same disk block.
However, in this case, in accordance with the definitions
of tail and head paddings, we have that |BC| <= block_size. (2)
From (1) and (2) we have that |BC| == block_size, and
p_end + p_tailp == C == start-of-next-extent. Note, that
this satisfies the "gluing condition" (discard.c, line 362).
That is, we'll try to glue the current and the next extent.
It means that we'll check BC only once:
If BC is dirty, than gluing failed, and we don't allocate BC.
If BC is clean, than we allocate BC, jump to the next
extent and don't check its head padding (because it was
"glued" with the previous one).
Did I miss something?
Thanks,
Edward.
next prev parent reply other threads:[~2015-03-08 22:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-20 20:24 [PATCH] reiser4: precise discard - general case Edward Shishkin
2015-02-10 20:42 ` Ivan Shapovalov
2015-02-11 8:23 ` Edward Shishkin
2015-02-11 10:09 ` Ivan Shapovalov
2015-02-11 23:40 ` Edward Shishkin
2015-02-12 6:14 ` Ivan Shapovalov
2015-03-08 22:43 ` Edward Shishkin [this message]
2015-03-09 1:46 ` Ivan Shapovalov
2015-03-09 10:38 ` Edward Shishkin
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=54FCD090.3000005@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).