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
next prev parent 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).