[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A865258.5090903@gmail.com>
Date: Sat, 15 Aug 2009 09:14:48 +0300
From: Artem Bityutskiy <dedekind1@...il.com>
To: Denys Vlasenko <vda.linux@...glemail.com>
CC: Robert Schwebel <r.schwebel@...gutronix.de>,
linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
Arjan van de Ven <arjan@...ux.intel.com>,
Tim Bird <tim.bird@...sony.com>, kernel@...gutronix.de
Subject: Re: New fast(?)-boot results on ARM
On 08/14/2009 11:04 PM, Denys Vlasenko wrote:
>> [ 2.742628]< 0.016050> 0x000000360000-0x000004000000 : "root"
>> [ 3.058610]< 0.315982> UBI: attaching mtd7 to ubi0
>> [ 3.062878]< 0.004268> UBI: physical eraseblock size: 16384 bytes (16 KiB)
>> [ 3.070601]< 0.007723> UBI: logical eraseblock size: 15360 bytes
>> [ 3.070665]< 0.000064> UBI: smallest flash I/O unit: 512
>> [ 3.078564]< 0.007899> UBI: VID header offset: 512 (aligned 512)
>> [ 3.078609]< 0.000045> UBI: data offset: 1024
>> [ 5.006609]< 1.928000> UBI: attached mtd7 to ubi0
>> [ 5.013157]< 0.006548> UBI: MTD device name: "root"
>
> As others commented, ubi looks slow and you probably need to find out why.
Right. UBI is rather slow in attaching MTD devices. Everything is explained
here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_scalability
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_scalability
There is not very much you can do to speed it up but implement UBI2. UBIFS
would stay intact. There were discussions about this and it does not seem
to be impossibly difficult to do UBI2. Here are few ideas:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_attach_faster
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists