From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: <dedekind1@gmail.com>, <richard.weinberger@gmail.com>,
<computersforpeace@gmail.com>
Cc: <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mkfs.ubifs: remove the check for UBIFS_MAX_LEB_SZ
Date: Mon, 24 Aug 2015 14:37:32 +0800 [thread overview]
Message-ID: <55DABBAC.9040401@cn.fujitsu.com> (raw)
In-Reply-To: <1440397943.15510.2.camel@gmail.com>
On 08/24/2015 02:32 PM, Artem Bityutskiy wrote:
> On Mon, 2015-08-24 at 09:07 +0800, Dongsheng Yang wrote:
>> On 08/18/2015 04:52 PM, Artem Bityutskiy wrote:
>>> On Tue, 2015-08-18 at 12:52 +0800, Dongsheng Yang wrote:
>>>> There is a commit 92ed6c0 to increase UBIFS_MAX_LEB_SZ
>>>> to 2MiB. But recently, as the leb size become larger and
>>>> larger, 2MiB is not a suitable limit any more.
>>>>
>>>> Then remove this check in mkfs.ubifs
>>>>
>>>> Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
>>>> ---
>>>> NOTE:
>>>> I am not sure the reason why we have to
>>>> limit the leb size in mkfs.ubifs. Because
>>>> I did not find any reason for it, I send
>>>> this patch out. It's very possible I am
>>>> mising something.
>>>
>>> Well, this is sanity check for the user input. If you accidentally
>>> added few zeroes, we want to spot this and inform you, and you may
>>> appreciate that we did not just created a bugus image for you.
>>> That's
>>> the idea.
>>
>> Sorry, Artem, I was trying to understand it, but I did not got the
>> point. Could you give me some more information about the idea? Maybe
>> an example?
>
> Well, this is defensive programming concept.
Ha, okey, got it. That's good.
But I got a device with ped_size=32M. (Although that would affect
ubi/ubifs performance negatively, that's another topic) I am
not sure increasing the MAX_LEB_SIZE to 32M is a good idea, at least
I don't think it's convincing to others that "I have a device with 32M
peb, so I will increase it to 32M". Could you give me some more suggestion?
Thanx
> Something goes wrong, due
> to bad user input and/or a bug we get to this place with an bogus size.
> This check catches it and errors out versus we just go forward,
> generate a bugus image, which you then flash and find that things do
> not work, and then spend your time for further investigations. Nothing
> more than that.
>
> Artem.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
next prev parent reply other threads:[~2015-08-24 6:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 4:52 [PATCH] mkfs.ubifs: remove the check for UBIFS_MAX_LEB_SZ Dongsheng Yang
2015-08-18 8:52 ` Artem Bityutskiy
2015-08-24 1:07 ` Dongsheng Yang
2015-08-24 6:32 ` Artem Bityutskiy
2015-08-24 6:37 ` Dongsheng Yang [this message]
2015-08-24 7:05 ` Artem Bityutskiy
2015-08-24 7:04 ` Dongsheng Yang
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=55DABBAC.9040401@cn.fujitsu.com \
--to=yangds.fnst@cn.fujitsu.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
/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).