Skip to contentSkip to conversation

ext2 for read-only file system on UBI

DISCUSSION Hamish Moffatt 2 participants 7 messages May 19, 2008 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

My embedded device has a read-only root file system which is only replaced by writing a whole image (dd, flashcp, ubiupdatevol etc).

Using gluebi and mtdblock, I think I can put a traditional block file system (eg ext2) on top of NAND flash. What are the disadvantages of this? (For the read-only application only.)

Background: I've got older hardware which uses ext2 on top of compact flash in IDE mode, and new hardware which has replaced the compact flash with NAND. I'd like to share an ext2 image between the two if possible.

The read-write file systems use ubifs. I'm only considering this for the read-only volumes. One obvious disadvantage is lack of compression. Are there others? Do I still get the reliability of ubi?

ie what does "UBI is not an FTL" mean in practice?

thanks,
Hamish

Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
#1 lore raw

Hello Hamish,

Quoted 6 lines · Hamish Moffatt

My embedded device has a read-only root file system which is only replaced by writing a whole image (dd, flashcp, ubiupdatevol etc).

Using gluebi and mtdblock, I think I can put a traditional block file system (eg ext2) on top of NAND flash. What are the disadvantages of this? (For the read-only application only.)

For read-only it should be ok, although I am not sure mtdblock will like non power of 2 eraseblock sizes. But this should be trivial to fix.

Quoted 3 lines

Background: I've got older hardware which uses ext2 on top of compact flash in IDE mode, and new hardware which has replaced the compact flash with NAND. I'd like to share an ext2 image between the two if possible.

Should be possible for R/O. Different sizes of eraseblocks may add extra work though.

Quoted 3 lines

The read-write file systems use ubifs. I'm only considering this for the read-only volumes. One obvious disadvantage is lack of compression. Are there others? Do I still get the reliability of ubi?

No, should be fine. Well, you'll still have WL across whole NAND chip, yes. You'll still have bit-flip handling.

Quoted 1 line

ie what does "UBI is not an FTL" mean in practice?

In practice it means that /dev/ubiX_Y are not block devices, where you may directly put ext2 and the like.

Signature · 2 lines
Best regards,
Artem Bityutskiy (Битюцкий Артём)
#2 lore raw

Hi Artem, thanks for your response.

Quoted 18 lines · Artem Bityutskiy
Quoted 6 lines · Hamish Moffatt

My embedded device has a read-only root file system which is only replaced by writing a whole image (dd, flashcp, ubiupdatevol etc).

Using gluebi and mtdblock, I think I can put a traditional block file system (eg ext2) on top of NAND flash. What are the disadvantages of this? (For the read-only application only.)

For read-only it should be ok, although I am not sure mtdblock will like non power of 2 eraseblock sizes. But this should be trivial to fix.

Quoted 3 lines

Background: I've got older hardware which uses ext2 on top of compact flash in IDE mode, and new hardware which has replaced the compact flash with NAND. I'd like to share an ext2 image between the two if possible.

Should be possible for R/O. Different sizes of eraseblocks may add extra work though.

Quoted 6 lines
Quoted 3 lines

The read-write file systems use ubifs. I'm only considering this for the read-only volumes. One obvious disadvantage is lack of compression. Are there others? Do I still get the reliability of ubi?

No, should be fine. Well, you'll still have WL across whole NAND chip, yes. You'll still have bit-flip handling.

So, is there a benefit to Nancy's proposed ubi block layer as opposed to gluebi + mtdblock?
( http://lists.infradead.org/pipermail/linux-mtd/2008-May/021609.html )

regards
Hamish

Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
#3 lore raw
Quoted 6 lines · Hamish Moffatt
Quoted 2 lines

No, should be fine. Well, you'll still have WL across whole NAND chip, yes. You'll still have bit-flip handling.

So, is there a benefit to Nancy's proposed ubi block layer as opposed to gluebi + mtdblock?
( http://lists.infradead.org/pipermail/linux-mtd/2008-May/021609.html )

Yes, her layer is assumed to be R/W block device.

You could want to glance here as well:

http://www.linux-mtd.infradead.org/faq/general.html#L_ext2_mtd
http://www.linux-mtd.infradead.org/faq/ubi.html#L_ext2_over_ubi

Signature · 2 lines
Best regards,
Artem Bityutskiy (Битюцкий Артём)
#4 lore raw
Quoted 8 lines · Artem Bityutskiy
Quoted 6 lines · Hamish Moffatt
Quoted 2 lines

No, should be fine. Well, you'll still have WL across whole NAND chip, yes. You'll still have bit-flip handling.

So, is there a benefit to Nancy's proposed ubi block layer as opposed to gluebi + mtdblock?
( http://lists.infradead.org/pipermail/linux-mtd/2008-May/021609.html )

Quoted 6 lines

Yes, her layer is assumed to be R/W block device.

You could want to glance here as well:

http://www.linux-mtd.infradead.org/faq/general.html#L_ext2_mtd
http://www.linux-mtd.infradead.org/faq/ubi.html#L_ext2_over_ubi

Thanks for the links. So, read-write with mtdblock is dangerous (regardless of UBI) because it must erase and rewrite a whole block, right? Proposed ubiblk (linked from above) would use UBI ops to make the update operation safe.

Hamish

Signature · 1 line
Hamish Moffatt VK3SB <[email protected]> <[email protected]>
#5 lore raw
Quoted 10 lines · Hamish Moffatt
Quoted 6 lines

Yes, her layer is assumed to be R/W block device.

You could want to glance here as well:

http://www.linux-mtd.infradead.org/faq/general.html#L_ext2_mtd
http://www.linux-mtd.infradead.org/faq/ubi.html#L_ext2_over_ubi

Thanks for the links. So, read-write with mtdblock is dangerous (regardless of UBI) because it must erase and rewrite a whole block, right?

Yes, and you loose plenty of data in case of power-cuts.

Quoted 2 lines

Proposed ubiblk (linked from above) would use UBI ops to make the
update operation safe.

I have not looked that close at Nancy's patches because I did not like her unreasonable copy-paste stuff. But I assume she would do something like I proposed here:

http://lists.infradead.org/pipermail/linux-mtd/2008-January/020381.html

Signature · 2 lines
Best regards,
Artem Bityutskiy (Битюцкий Артём)
#6 lore raw
Quoted 6 lines · Artem Bityutskiy
Quoted 3 lines

Thanks for the links. So, read-write with mtdblock is dangerous (regardless of UBI) because it must erase and rewrite a whole block, right?

Yes, and you loose plenty of data in case of power-cuts.

Quoted 8 lines
Quoted 2 lines

Proposed ubiblk (linked from above) would use UBI ops to make the
update operation safe.

I have not looked that close at Nancy's patches because I did not like her unreasonable copy-paste stuff. But I assume she would do something like I proposed here:

http://lists.infradead.org/pipermail/linux-mtd/2008-January/020381.html

Basically the idea is to implement something as straightforward as mtdblock, but using the "atomic LEB change" [1] operation and do not loose data in case of power-cuts.

1. http://www.linux-mtd.infradead.org/doc/ubi.html#L_lebchange

Signature · 2 lines
Best regards,
Artem Bityutskiy (Битюцкий Артём)