Opened on 02/13/15 at 20:42:43
Closed on 08/13/17 at 23:57:35
#2267 closed defect (wontfix)
Increase maximum block size allowed by IMFS
Reported by: | Joel Sherrill | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | Indefinite |
Component: | unspecified | Version: | |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
In imfs_initsupp.c, there is code to limit the maximum block size for the IMFS to a power of two <= 512. This code was written a long time ago (at least 15 years) and at that point having a lot of RAM was inconceivable. I am proposing to increase the limit to at least 8192.
I am not proposing we change the default which is currently 128 bytes. This gives a maximum file size of ~1GB.
Increasing it to 8192 would make the limit approximately 16GB.
Change History (4)
comment:1 Changed on 02/13/15 at 20:46:51 by Sebastian Huber
comment:2 Changed on 02/13/15 at 20:50:47 by Joel Sherrill
I was just asking if the limit needs to be increased since it was set 15 years ago. There are no users needing this. When designed 16MB was more RAM than I had seen on an RTEMS system. Now we see much more than that on USD35 boards.
You are right that we don't want to overflow a 32-bit integer. That may mean the practical limit is 1024 (2GB filesystem) or 2048.
But do we want to do this at all?
comment:3 Changed on 02/13/15 at 23:22:34 by Chris Johns
For large RAM based file systems I use a RAM disk formatted with the RFS. For example I currently has a 32M RAM disk on a board with the RFS and this avoids fragmenting of the heap.
I do not see a need for this change.
comment:4 Changed on 08/13/17 at 23:57:35 by Chris Johns
Milestone: | 5.0 → Indefinite |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Version: | 4.11 |
Please reopen if this issue is still valid.
Are you sure that there are no 32-bit integer overflows in this case? How can you test this? Is there a demand for such a large IMFS file?