reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Shishkin <edward.shishkin@gmail.com>
To: "Ivan Shapovalov" <intelfx100@gmail.com>,
	"Dušan Čolić" <dusanc@gmail.com>
Cc: reiserfs-devel <reiserfs-devel@vger.kernel.org>
Subject: Re: [patch] reiser4: port for Linux-4.1
Date: Tue, 9 Feb 2016 18:53:23 +0100	[thread overview]
Message-ID: <56BA2793.7090906@gmail.com> (raw)
In-Reply-To: <1436109206.6440.12.camel@gmail.com>

Hi all,

There is a pending patch for precise discarsd, which I can not merge
because it is incomplete. Just want to know, is there any progress on
this?

So we found that calculating discard params by mkfs and storing
them in superblock is a dirty option, so I suggest to reserve a
contiguous area (1 MiB?) on disk at "mkfs -d" time (just mark it busy
in the bitmap). And calculate erase unit size and offset at mount time.
If calculation failed for some reasons, then use non-precise discard.

So, I think, we'll need one d32 field in disk superblock, which indicates
number of reserved blocks (0 means no reservation) and a pair of
definitions in disk_format40.h:

#define FORMAT40_FIRST_RESERVED_FOR_PROBING \
       ((REISER4_MASTER_OFFSET / PAGE_CACHE_SIZE) + 6)
#define FORMAT40_MAX_BLOCKS_RESERVED_FOR_PROBING

If any questions, or technical stoppers, then let me know.

Thanks,
Edward.


On 07/05/2015 05:13 PM, Ivan Shapovalov wrote:
> On 2015-07-05 at 16:06 +0200, Dušan Čolić wrote:
>> On 5 Jul 2015 15:12, "Ivan Shapovalov"<intelfx100@gmail.com>  wrote:
>>> On 2015-07-05 at 02:33 +0800, Edward Shishkin wrote:
>>>> On 07/05/2015 01:53 AM, Ivan Shapovalov wrote:
>>>>> On 2015-07-04 at 15:53 +0800, Edward Shishkin wrote:
>>>>>> [...]
>>>>>> And how to test directly at mount time?
>>>>> Something along the lines of
>>>>> - allocate 1 MiB of contiguous space
>>>>> - fill it with non-zeros
>>>>> - for N = 1, 2, 4, ...:
>>>>>     - discard N sectors from the contiguous space
>>>>>     - check if anything in the discarded space became zero
>>>>> -filled
>>>>>     - if it did, infer alignnment from the first zero-filled
>>>>> block,
>>>>>       infer granularity from the zero-filled region size.
>>>> mkfs seems to be more suitable for this funny business
>>> Yeah, sure. So... new superblock format with two extra fields?
>>>
>> But what happens when someone makes an image of whole partition and
>> uses it
>> on new different ssd?
> Maybe we can make a tunefs.reiser4 (just) for that purpose.

--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-02-09 17:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-26 14:06 [patch] reiser4: port for Linux-4.1 Edward Shishkin
2015-06-29 17:54 ` Edward Shishkin
2015-06-30  7:13   ` Ivan Shapovalov
2015-06-30  7:30     ` Edward Shishkin
2015-06-30  8:06       ` Ivan Shapovalov
2015-06-30  8:58         ` Edward Shishkin
2015-07-01 23:35           ` Ivan Shapovalov
2015-07-04  7:53             ` Edward Shishkin
2015-07-04 17:53               ` Ivan Shapovalov
2015-07-04 18:33                 ` Edward Shishkin
2015-07-05 13:08                   ` Ivan Shapovalov
2015-07-05 13:46                     ` Edward Shishkin
2015-07-05 15:11                       ` Ivan Shapovalov
2015-07-05 15:43                         ` Edward Shishkin
     [not found]                     ` <CADW=+3=J7Rt1yxtTfW=ZCLC40-D1FPCFR7KGSyp_YLgcRcH3FQ@mail.gmail.com>
2015-07-05 15:13                       ` Ivan Shapovalov
2015-07-06  8:56                         ` Edward Shishkin
2016-02-09 17:53                         ` Edward Shishkin [this message]
2016-02-10  4:04                           ` Ivan Shapovalov
2016-02-10  9:01                             ` Edward Shishkin
2016-04-06 16:54                           ` Ivan Shapovalov
2016-04-06 18:03                             ` Edward Shishkin
2015-07-04 18:06               ` Ivan Shapovalov

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=56BA2793.7090906@gmail.com \
    --to=edward.shishkin@gmail.com \
    --cc=dusanc@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).