mtd partitions limited to 4 GB?
In drivers/mtd/mtdpart.c, struct mtd_part has "u_int32_t offset", thus (apparently) limiting the partition start offset to 4 GiB. Similarly, struct mtd_partition in include/linux/mtd/partititions.h has "u_int32_t size" and "u_int32_offset".
Now that NAND FLASH device sizes have exceeded that, this appears to be a significant limitation.
Is anyone in the mtd community already addressing this?
Fixing the core infrastructure might be as simple as using "loff_t" instead of "u_int32_t" for those fields. However, all of the existing partition map parsers appear to have the same 32-bit limitation, so partitioning a >4GiB device will require a new or modified partition map format.
Quoted 4 lines · On Mon, 16 Jun 2008 14:04:06 -1000 Mitch Bradley <[email protected]> wrote:
In
drivers/mtd/mtdpart.c, structmtd_parthas "u_int32_toffset", thus (apparently) limiting the partition start offset to 4 GiB. Similarly, structmtd_partitionininclude/linux/mtd/partititions.hhas "u_int32_tsize" and "u_int32_offset".
This is not limited to partitions. The entire MTD subsystem is limited to 4 GiB sized devices.
Quoted 4 lines
Now that NAND FLASH device sizes have exceeded that, this appears to be a significant limitation.
Is anyone in the mtd community already addressing this?
There have been some that have offered to help in recent weeks. A brainstorming session of sorts happened on the list a couple of weeks ago. You might check there for what was decided.
Quoted 5 lines
Fixing the core infrastructure might be as simple as using "
loff_t" instead of "u_int32_t" for those fields. However, all of the existing partition map parsers appear to have the same 32-bit limitation, so partitioning a >4GiB device will require a new or modified partition map format.
IIRC, one of the outcomes of the discussion was to introduce a new interface so that chips are addressed in block+offset mappings. This will be better overall, but requires a bit more overhead in the initial implementation.
josh
Quoted 4 lines · On Tuesday 17 June 2008 12:04:06 Mitch Bradley wrote:
In
drivers/mtd/mtdpart.c, structmtd_parthas "u_int32_toffset", thus (apparently) limiting the partition start offset to 4 GiB. Similarly, structmtd_partitionininclude/linux/mtd/partititions.hhas "u_int32_tsize" and "u_int32_offset".
As Josh says it is not just an mtd_part issue, but the whole guts of mtd suffer from this. The actual mtd_xxx interface to the kernel is close enough for most purposes.
I am aware of people using Linux with >4GB of NAND for a long time now (well over a year). They did this by writing their own mtd drivers that just fit onto the existing interface. Many people do that anyway because the nand core stuff is slow relative to a tailor made driver.
Quoted 11 lines
Now that NAND FLASH device sizes have exceeded that, this appears to be a significant limitation.
Is anyone in the mtd community already addressing this?
Fixing the core infrastructure might be as simple as using "
loff_t" instead of "u_int32_t" for those fields. However, all of the existing partition map parsers appear to have the same 32-bit limitation, so partitioning a >4GiB device will require a new or modified partition map format.
It is more than just changing the 32 to 64 bit types.
Quoted 1 line
Quoted 1 line
In
drivers/mtd/mtdpart.c, structmtd_parthas "u_int32_toffset",
thus
Quoted 2 lines
Quoted 2 lines
(apparently) limiting the partition start offset to 4 GiB. Similarly, struct
mtd_partitionininclude/linux/mtd/partititions.hhas
"u_int32_t
Quoted 5 lines
Quoted 1 line
size" and "
u_int32_offset".As Josh says it is not just an
mtd_partissue, but the whole guts of mtdsuffer from this. The actual
mtd_xxxinterface to the kernel is close
enough
Quoted 2 lines
for most purposes.
<snip>
Quoted 2 lines
It is more than just changing the 32 to 64 bit types.
It is indeed more than just a type change, as I'm discovering :\. I'm currently working on a change that will allow greater than 2GiB size, but since my project isn't going to have any partitions in it, I wasn't aware of any limitations there. As I go through my work I'll try and keep it in mind, but I'm mired in the NAND layer and make no promises. I'm trying to do this in small increments rather than a wholesale change that introduces numerous bugs :).
Bruce