From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>
Cc: reiserfs-devel@vger.kernel.org
Subject: Re: [PATCH 0/6] reiser4: discard support: "precise discard" aka padding of extents to erase unit boundaries.
Date: Mon, 15 Dec 2014 20:30:29 +0100 [thread overview]
Message-ID: <548F36D5.4000402@gmail.com> (raw)
In-Reply-To: <1847370.hWhlfNze1m@intelfx-laptop>
On 12/14/2014 09:03 AM, Ivan Shapovalov wrote:
> On Saturday 13 December 2014 at 23:38:02, Edward Shishkin wrote:
>> On 12/12/2014 10:10 PM, Ivan Shapovalov wrote:
>>> So, this patchset uses your algorithm of padding/gluing extents to be discarded.
>>> I've added exact allocation primitives (is it what you've been talking about?
>>
>> So, we found out that the old bitmap primitives don't allow us to implement
>> precise discard, and I asked for new ones. Also we wanted to implement the
>> general case, when precise discard works for any pair (offset, unit).
>> Currently
>> it works only for ones determined by the function convert_lattice_params().
>> For some reasons (that I don't remember) I was sure, that the general case
>> should be obtained from this partial case by a small transformation of the
>> function discard_sorted_merged_extents().
>>
>> Well, I'll try to dive into details and generalize things on the holidays.
>> If generalization is impossible, then we'll switch to non-precise
>> discard every
>> time when convert_lattice_params() fails.
> I don't quite understand you here... Do you mean that some non-insane combinations
> of discard unit, discard offset and blocksize are not handled (but worth
> handling)?
Yes. As you can see, if (discard_offset % block_size != 0), then we
don't issue discard requests. Neither precise, nor non-precise.
It is hard to implement the precise discard support in the generic case
straight away.
>
> TBH, convert_lattice_params() looks magic-ish to me...
OK, I'll try to provide some background (geometric minimum).
Edward.
next prev parent reply other threads:[~2014-12-15 19:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 21:10 [PATCH 0/6] reiser4: discard support: "precise discard" aka padding of extents to erase unit boundaries Ivan Shapovalov
2014-12-12 21:10 ` [PATCH 1/6] reiser4: block_alloc: split block allocation accounting logic into separate functions for re-use Ivan Shapovalov
2014-12-12 21:10 ` [PATCH 2/6] reiser4: block_alloc, plugin/space/bitmap: add a method for "exact" block allocation Ivan Shapovalov
2014-12-19 15:43 ` Edward Shishkin
2014-12-12 21:10 ` [PATCH 3/6] reiser4: iterate over extents in discard_atom Ivan Shapovalov
2014-12-12 21:10 ` [PATCH 4/6] reiser4: discard: don't be overly smart when gluing extents in discard_sorted_merged_extents() Ivan Shapovalov
2014-12-19 20:24 ` Edward Shishkin
2014-12-12 21:10 ` [PATCH 5/6] reiser4: blocknrlist: add operations blocknr_list_del() and blocknr_list_update_extent() Ivan Shapovalov
2014-12-12 21:10 ` [PATCH 6/6] reiser4: discard: allocate extent paddings Ivan Shapovalov
2014-12-13 22:38 ` [PATCH 0/6] reiser4: discard support: "precise discard" aka padding of extents to erase unit boundaries Edward Shishkin
2014-12-14 8:03 ` Ivan Shapovalov
2014-12-15 19:30 ` Edward Shishkin [this message]
2014-12-19 15:46 ` 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=548F36D5.4000402@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.