reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Shishkin <edward.shishkin@gmail.com>
To: intelfx@intelfx.name, "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: Wed, 06 Apr 2016 20:03:34 +0200	[thread overview]
Message-ID: <57054F76.1000701@gmail.com> (raw)
In-Reply-To: <1459961644.5177.6.camel@intelfx.name>



On 04/06/2016 06:54 PM, Ivan Shapovalov wrote:
> On 2016-02-09 at 18:53 +0100, Edward Shishkin wrote:
>> 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.
> I guess it would be nicer to allocate the needed space dynamically at
> mount time.


And if no enough space, then switch to non-precise discard mode? OK.
Since the probing code is for SSD drives, it shouldn't lead to long mounts
in the case of big terabyte partitions, which are full of data.


>   However, there is a problem: where to put the probing code
> in the fill_super() (I suppose?) sequence?


Put it in try_init_format40(), right after the sa_init_allocator():
seems to be a right place.

Thanks,
Edward.


>   We want the allocator to be
> intact, but nothing should be written to the filesystem so far.
>
> --
> Ivan Shapovalov / intelfx /
>
>>
>> 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>  wro
>>>> te:
>>>>> 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

  reply	other threads:[~2016-04-06 18:03 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
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 [this message]
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=57054F76.1000701@gmail.com \
    --to=edward.shishkin@gmail.com \
    --cc=dusanc@gmail.com \
    --cc=intelfx100@gmail.com \
    --cc=intelfx@intelfx.name \
    --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).