michallenc commented on PR #16624:
URL: https://github.com/apache/nuttx/pull/16624#issuecomment-3020422833
> @michallenc @xiaoxiang781216 I believe that the byte access flash of FTL
you mentioned is what I am currently working to implement. Please revisit issue
#16642, as some new patches related to FTL have been introduced. I have
attempted to incorporate file operations within FTL. When an MTD node is opened
in O_DIRECT mode, the previous process of reading back the entire sector before
writing with FTL will no longer be utilized. Instead, a streamlined writing
process will be adopted: erasure will occur when the size aligns with the erase
sector, and sequential writing will be employed prior to that.
>
> Let us compare the advantages and disadvantages of the two implementations:
>
> 1. Separate MTD driver
>
> 2. change the behavior of BCH/FTL layer
I think this is going in a right direction. Looking at the recent changes
(just a short look, I am on a children summer camp this week and don't have
much time), the only reservation I have is this part in `ftl_flush_direct`.
```C
if (offset == 0)
{
ret = ftl_mtd_erase(dev, starteraseblock);
if (ret < 0)
{
return ret;
}
}
```
While this is true for some (maybe most) use cases, it might not be for
others. And this basically requires the sequential access inside an erase page
(you can't write first write page after the others, otherwise the changes are
lost). This is a reasonable requirement for application access anyway, but
maybe I would keep it configurable, use some sort of ioctl that would toggle it?
Just to clarify the major reason of this PR and separate MTD driver, I was
trying to limit RAM memory usage. Our design has quite large number of
partition on NOR flash (several for logging, some for firmware update, etc) and
the buffers alone consumed about 60 kBs, almost 20 % of available RAM space. So
the main reason was to avoid buffering and limit unnecessary flash erases if
possible. I think your BCH/FTL changes will do that once finished, so I am
completely fine with it. And it is even better if it is (more) ready for NAND
flashes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
