[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86761077.40163293.1410990114756.JavaMail.zimbra@redhat.com>
Date: Wed, 17 Sep 2014 17:41:54 -0400 (EDT)
From: Rodrigo Freire <rfreire@...hat.com>
To: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Cc: Jörn Engel <joern@...fs.org>,
linux-mtd@...ts.infradead.org, Felix Fietkau <nbd@...nwrt.org>,
David Woodhouse <dwmw2@...radead.org>,
linux-kernel@...r.kernel.org,
Herton Krzesinski <hkrzesin@...hat.com>
Subject: Re: [PATCH V2] mtd: block2mtd: Present block2mtd timely on boot
time
Holas Ezequiel,
----- Original Message -----
From: "Ezequiel Garcia" <ezequiel@...guardiasur.com.ar>
> On 17 September 2014 21:28, Rodrigo Freire <rfreire@...hat.com> wrote:
>
> Using block2mtd sounds a bit unusual. I see that you are trying to get
> a more robust fs.... have you tried using f2fs instead of jffs2?
I see that it is still marked as Experimental as of latest (3.17-RC5)
kernel. But will take a look in the future, thanks for pointing.
> > Currently, a block MTD device is not presented to the system on time, in
> > order to start mounting the filesystems. This patch ensures that block2mtd
> > is presented at the right time, so filesystems can be mounted on boot time.
>
> It worries me a bit to add such a long delay to the boot. If for some
> reason the SD is not working, then the kernel will wait (by default) 3
> seconds now?
Not really; see the decision path:
IF block2mtd is not a module (is builtin), AND
IF there is a valid block2mtd= clause on kernel cmdline, AND
IF the device specified device on block2mtd= clause is still not present
THEN wait *up to* 3 seconds (or seconds=n if specified on block2mtd=
cmdline) to the device to show up. If the device shows up earlier,
the device is created and boot proceeds.
ELSE Fail to create the block2mtd device.
ELSE keep booting the kernel normally, without any further delays.
Best regards,
- RF.
--
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