lfs_disk_entry

[aldot]

alen and elen seem to be a bit superfluous.
I'd fold them in some spare bits in type
or trim nlen (and thus LFS_NAME_MAX) to put them there.
Eventually.

[geky]

Ah, these are good ideas. Though this turns into a tradeoff between storage-consumption and flexibility.

alen is reserved for potential future use. The original goal was to allow entries to have a section for custom attributes as an alternative to the fixed set of attributes you find in most filesystems (timestamps, permissions, etc). However, adding attributes would require significant changes to the driver, so I don't think they will be supported anytime soon.

elen is independent from the type so that new entry types could be added without breaking older versions of the driver. Though squishing elen down to fit in the type is a good idea.

One idea I do want to get to is storing files inline in dir entries. At the moment each file takes a minimum of one erase unit, which is usually 512B-4KB. For small files, say <256B, you could save a lot of overhead and erase cycles by storing the data in the dir entry. In this case you could use elen as the file size directly.

That's sort of what elen and alen were intended for. Flash memory is cheap, so my thinking is that it's better to leave room for future improvements. Thoughts?

[guillaumerems]

I confirm that alen is very useful, for example on my side I use attributes to store the modification data of an entry.

[geky]

Oh! @guillaumerems, did you modify littlefs to get attributes working? Or was this on a different filesystem?

[guillaumerems]

I modified littlefs and it works very well ;) see the new issue I opened with the modification I made

[geky]

I'm going to close this but feel free to reopen