the callbacks are not activated by conditional compilation and are in
the middle of struct mtd_dev_s , so how are these optional?
Sebastien
Le 01/03/2023 à 15:36, Xiang Xiao a écrit :
On Wed, Mar 1, 2023 at 10:26 PM Sebastien Lorquet
<sebast...@lorquet.fr> wrote:
Hi,
Please dont break the mtd interface, make it compatible with the
previous one.
The new callbacks are optional: https://github.com/apache/nuttx/pull/8683.
Sebastien
Le 01/03/2023 à 14:53, Xiang Xiao a écrit :
> On Wed, Mar 1, 2023 at 8:43 PM Alan C. Assis <acas...@gmail.com>
wrote:
>
>> Hi Xiang Xiao,
>>
>> This is a great news, but I'm afraid yaffs is not a good option for
>> everybody because it uses GPL license.
>>
>>
> Yes, but you can pay some money to switch to a more friendly
license.
>
>
>> But yes, it could be an option for people and companies that can
>> release all their software as open-source. PX4 project for example
>> could use it.
>>
>>
> The enhancement in mtd_s is decoupled from yaffs, actually the new
> interface follows Linux MTD model.
> BTW, We plan to improve LittleFS to utilize the new interface.
>
>
>> BR,
>>
>> Alan
>>
>> On 2/28/23, Xiang Xiao <xiaoxiang781...@gmail.com> wrote:
>>> We are working on yaffs porting, mtd_s need a little bit of
extension to
>>> support NAND flash.
>>> Here is the patch: https://github.com/apache/nuttx/pull/8670
>>> LittleFS needs some modification to get the benefit.
>>>
>>> On Sun, Feb 26, 2023 at 10:14 PM Nathan Hartman <
>> hartman.nat...@gmail.com>
>>> wrote:
>>>
>>>> On Sat, Feb 25, 2023 at 8:53 AM Gregory Nutt
<spudan...@gmail.com>
>> wrote:
>>>>>> Maybe LittleFS or SmartFS could be extended to handle NAND.
>>>>> I believe that LittleFS has been used with NAND with a NAND
FLASH
>>>>> translation layer. I am not sure of the state of that work,
but I
>> know
>>>>> that people have tried it. Google "LittleFS on NAND flash"
and see
>> the
>>>>> hits.
>>>>>
>>>>> If a NAND flash translation layer (NFTL) were ported to
NuttX, then
>> you
>>>>> should be able to use almost any file system, although some
would be
>>>>> extremely inefficient with NAND. The NAND flash layer would
need to
>> do
>>>>> sparing, wear-leveling, ECC calculations, etc. as needed by
NAND.
>>>>>
>>>>> I have used NXFFS with NAND and it /almost /works.
>>>>>
>>>>> The basic filesystem issue is that all available filesystems
need to
>> do
>>>>> read-modify-write operations on flash sections. And they
assume that
>>>>> you can always write a '1' bit to a '0' bit. SmartFS and
NXFFS both
>>>>> assume this behavior explicitly. It is a good assumption
with NOR
>>>>> flash. The problem is that NAND can only be written a whole
sector at
>>>>> a
>>>>> time. This is because the error correction coding (ECC):
If you
>>>>> change
>>>>> even one bit in the NAND sector, you have to re-write the
whole sector
>>>>> with new ECC (because you can't change the '0' bits in the
ECC back
>>>>> into
>>>>> '1''s without erasing the sector).
>>>>>
>>>>> Since SmartFS and NXFFS both do bit twiddling in the sectors
they
>> would
>>>>> be very inefficient with an NFTL: Each bit twiddle would cause a
>> whole
>>>>> sector re-write. The same is probably true for LittleFS.
Other file
>>>>> systems like FAT could also be used if there were an NFTL,
however,
>> FAT
>>>>> would also be inefficient (each directory update or FAT
update and
>> each
>>>>> file data size change would cause another sector write).
>>>>>
>>>>> So the only real solution to support NAND efficiently is use
a file
>>>>> system that is designed specifically around the
peculiarities of NAND.
>>>>> That would require some research (Alan has suggested a couple of
>> places
>>>>> to start).
>>>>
>>>>
>>>> I seem to recall reading that in NAND flash, one of the
challenges is
>>>> that
>>>> modifying a bit causes a disturbance that can corrupt other
bits, even
>> in
>>>> unrelated sectors, and that even reading can have this
effect. The
>>>> disturbance only affects bits a little at a time, but after
some number
>>>> of
>>>> accesses, the affected sectors need to be written to new sectors,
>> keeping
>>>> track of bad sectors formed in the process, to avoid data
loss. This may
>>>> lead to a cascade effect in which reading a sector may cause
numerous
>>>> sectors to be re-written. This phenomenon is called write
amplification.
>>>> The takeaway from a usage perspective is that you want to
over-provision
>>>> the amount of NAND flash you install, to leave plenty of room
for all
>>>> this
>>>> swapping, and plenty of extra sectors to increase the amount
of accesses
>>>> before failure. The greater the over-provisioning, the longer
until
>>>> failure.
>>>>
>>>> I haven't tried yet, but I would like at some point to support a
>> micro-SD
>>>> and/or micro-MMC card as the backing store and use one that
has built in
>>>> hardware wear leveling, with some appropriate file system of
course.
>> This
>>>> may add $50 or more to the bill of materials depending on the
card
>>>> capacity, but makes it possible for users to replace the card
if it
>>>> fails,
>>>> in contrast to soldered-on flash chips, which can be replaced
too, but
>>>> only
>>>> with the appropriate tools and skills.
>>>>
>>>> Cheers
>>>> Nathan
>>>>
