Thanks for elaboration - you are right in your analyze. What you propose will increase wear levering, especially if object are big in comparison to area size.
We can consider usage of additional RAM temporary, just when initializing: inode size on disk: 20 B + file_name/directory_name data_block size on disk: 24 B + data nffs_area header on disk: 3 B File deletion: the worst case: the smallest file create and immediate delete: [data_block of 1 B data] + [inode of 1 B file_name] + [deletion inode] = 25 + 21 + 20 = 66 B For each deleted inode only ID and sequence number must be known during file image parsing -> 8 B each the worst case required 8 B for store required deletion info. The worst case is that whole partition is filled by deleted files, no directory at all, regular area size: deleted_inode_info_max = ((Partition_size - area_size - areas_count * 3) / 66 ) * 8. So ratio is around 1/8 [RAM/ROM] For NFFS which contain 2 areas of size 4096 required 62 item of deleted inode info -> 496 B required. I think this is much tu much. And will be even worse if considers directory-create-delete scenario. But I have also idea of change management of IDs: [ Full content available at: https://github.com/apache/mynewt-nffs/issues/10 ] This message was relayed via gitbox.apache.org for [email protected]
