Hi Pintu, On Fri, 20 Aug 2021 at 15:25, Pintu Agarwal <pintu.ping@xxxxxxxxx> wrote: > > On Thu, 29 Jul 2021 at 22:41, Pintu Agarwal <pintu.ping@xxxxxxxxx> wrote: > > > > On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia > > <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger <richard@xxxxxx> wrote: > > > > > > > > Ezequiel, > > > > > > > > ----- Ursprüngliche Mail ----- > > > > > [snip] > > > > > > > > > > Ouch, so surprised that after all these years someone is doing squashfs/mtdblock > > > > > instead of using ubiblock :-) > > > > > > > > > > Can we patch either Kconfig or add some warn_once on mtdblock > > > > > usage, suggesting to use ubiblock instead? > > > > > > > > a hint in Kconfig makes IMHO sense. Do you want to send a patch? > > > > A warning is too much since on some tiny embedded system with NOR flash mtdblock is still > > > > a good choice. > > > > ubiblock is mostly useful for NAND flash. > > > > > > > > > I remember there was still some use case(s) for mtdblock but I can't remember > > > > > now what was it, perhaps we should document the expectations? > > > > > (Is that for JFFS2 to mount?) > > > > > > > > a long time ago mount didn't accept character devices, so you had to pass mtdblockX to mount > > > > JFFS2. > > > > This limitation is gone. > > > > > > Hi, > > Just a further follow-up on this discussion. > Whether to use /dev/mtdblock or /dev/ubiblock for rootfs (squashfs) > mounting during boot. > > As suggested here: > Instead of using this in kernel command line: > [ 0.000000] Kernel command line: ... rootfstype=squashfs > root=/dev/mtdblock44 ubi.mtd=40,0,30 ... > > I used this: > [ 0.000000] Kernel command line: ... rootfstype=squashfs > ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 ... > > The device is booting fine with ubiblock as well. > But, per say, I could not find any visible difference. > I just observed a slight improvement in boot time, but I need to > double-check on this, with few more reboot cycles. > That's a very good thing, it means we offered you a smooth transition :-) > Apart from this what are the other visible benefits of using ubiblock > which can be explained to be management or internal team ? > I could not find any documentation explaining the difference, except this one: > http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock > I'm not a flash expert here. In any case, you are expected to do your own research (just like we all did), design your own setup matching your use-case, design tests based on your workload and access patterns, etc. There are presentations on YouTube which discuss UBI, UBIFS and NAND-based designs on Linux, as well as white papers discussing NAND flashes challenges. Having said that... When you use UBI block, you are accessing the flash via the UBI layer. This is IMO the best way to design your system, since UBI addresses wear leveling and bad blocks, and offers atomic updates. In other words, IMO it's best to expose the NAND through UBI for both read-only and read-write access, using a single UBI device, and then creating UBI volumes as needed. This will allow UBI to spread wear leveling across the whole device, which is expected to increase the flash lifetime. For instance, just as some silly example, you could have something like this: | RootFS SquashFS | | UBI block | UBIFS User R-W area ------------------------------------------------------------------------ Kernel A | Kernel B | RootFS A | RootFS B | User ------------------------------------------------------------------------ UBIX ------------------------------------------------------------------------ /dev/mtdX This setup allows safe kernel and rootfs upgrading. The RootFS is read-only via SquashFS and there's a read-write user area. UBI is supporting all the volumes, handling bad blocks and wear leveling. > Can someone also point me to the respective driver code in case of > using /dev/mtdblock and /dev/ubiblock ? > Apart from theory I also want to check the impact at the code level.. > You can find all the UBI code in drivers/mtd/ubi of course. The differences between mtdblock and ubiblock are huge: one goes directly to the flash, and the other uses UBI. Good luck! Ezequiel
