A Lightweight and Configurable Flash Filesystem for Low-Power Devices

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This article focuses on low-level filesystems commonly used in resource-constrained, low-power devices. These devices typically have limited memory allocated for data, making efficient memory utilization crucial. The article discusses the challenges involved in developing such filesystems, along with key ideas and concepts to consider during the development process. By following the ideas and concepts presented in this article, the resulting filesystem implementation will be efficient in terms of memory utilization, portable across different hardware platforms, and lightweight, making it well-suited for low-power devices. This approach ensures that the filesystem meets both performance and flexibility requirements without unnecessary overhead. 

The paper is interesting but its sientific and technical novelties are not clear.

The paper absolutely lacks mathematical background.

The authors miss a lot of technical details. 

Comments on the Quality of English Language

The quality of English can be improved.

Author Response

Thank You for your review and valuable suggestions to improve the manusript.
The edits made in response to the review are highlighted in blue in the revised manuscript. Some of these edits may overlap with changes from other reviews.

_____
Comments 1:

The paper is interesting but its scientific and technical novelties are not clear.

Response 1:

• In the Introduction section, we added a paragraph providing more details about the design improvements to our filesystem, including runtime reconfiguration, minimal metadata, and a small memory footprint
• The final paragraph of the Discussion section was revised to highlight the contributions to CFFS mentioned in the Introduction - reliability, multi-memory support, and portability.

_____

Comments 2:

The paper absolutely lacks mathematical background.

Response 2:

Existing literature on filesystems typically focuses on the data structures and logic of the filesystem, often featuring block diagrams, flowcharts, or pseudo-code. Unless the paper is specifically about algorithm design, such as wear-leveling or garbage collection, mathematical background is generally not included.

We have added several formulas to Section 3.1 to provide a clearer explanation of how file regions are calculated based on the file sizes specified in the drive configuration.

We have also added a formula to Section 3.2 for calculating the flash wear of memory blocks reserved for error codes when one of the integrity check options is enabled. If the record sizes to be written to the files are known, this formula can be used to estimate the device's lifetime.

_____

Comments 3:

The authors miss a lot of technical details.

Response 3:

The details on how file pointers work are described in the referenced paper [1]. We have included this reference before the file type description in Section 3.1.

Section 3.1 now also includes a more detailed description of the drive structure, file structure, and flash API structure. A new figure (now Figure 1) has been added to the manuscript to provide a clearer explanation.

The text in Section 3.3 (highlighted in green) has been revised to include more details and provide a clearer explanation of how multi-memory support works. It was requested by another reviewer.

Section 4 includes examples of how the write function of CFFS can be implemented on different hardware platforms to provide a clearer understanding.

Reviewer 2 Report

Comments and Suggestions for Authors

The paper describes an improved version of the Configurable Flash Filesystem (CFFS) and establishes a comparison about this new version to others low-power embedded filesystems—LittleFS, SPIFFS, and FDS—highlighting its advantages in memory efficiency and durability (in fact I didn’t understand what you mean about durability, could you please clarify this issue in the document?)

In the presented comparison the author emphasizes the reliability of the implemented mechanisms with integrity checks and improved memory utilization. For getting the presented results, author seems to indicate that the new CFFS was installed in distinct devices (nRF52, ESP32, STM32) with external memories and real-time operating systems. Could you please clarify this issue, because after reading the entire document I think you will only use the Development Kit (PCA10056) with the nRF52 (indicated in section 6).

In general, the paper is well written, but I suggest some improvements. At the final of section 1 I suggest the author to present the contents of each of the remaining sections. In section 2 a brief description of filesystems is presented (high and low level). The transition from section 2 to section 3 should be improved, to justify the description of the new CFFS design, i.e., I felt that a sentence is missing at the end of section 2 to justify the presentation of the new file system in section 3.

Section 3 describes the implemented CFFS, presenting the new memory management, the error detection mechanism, in particular the file and drive check integrity, the possibility for multiple memory support and portability. All the descriptions are adequately supported by well-designed diagrams. The results presented in section 4 complemented with a discussion in section 5 are both well described but I suggest you put section 6 before section 4. You should present the test conditions before presenting results. In fact, only after reading section 6, I understood the conditions adopted to get those results, i.e., you adopted the PCA10056. From my point of view section 5 should be the last section of the paper, since it is basically a conclusion.

References are recent and adequate.

Author Response

Thank You for your review and valuable suggestions to improve the manuscript.
The edits made in response to the review are highlighted in yellow in the revised manuscript. Some of these edits may overlap with changes from other reviews.

_____

Comments 1:

In fact I didn’t understand what you mean about durability, could you please clarify this issue in the document?

Response 1:

By "durability," we referred to the wear of the flash memory cells. While this is related to the overall durability of the flash memory, environmental conditions and other factors outside the scope of the manuscript also play a role.

We have replaced the term "durability" with "flash wear." Section 2 now introduces flash memory wear at the beginning and provides a more detailed description of both active and passive wear-leveling.

_____

Comments 2:

For getting the presented results, author seems to indicate that the new CFFS was installed in distinct devices (nRF52, ESP32, STM32) with external memories and real-time operating systems. Could you please clarify this issue, because after reading the entire document I think you will only use the Development Kit (PCA10056) with the nRF52 (indicated in section 6).

Response 2:

We have used CFFS on various hardware platforms, but during development, most of its logic was simulated on a personal computer. When provided with correct flash memory parameters (block size, block count, and word size—the smallest writable unit), CFFS behaves the same as it would on hardware. The results presented in the paper are based on simulation, similar to those of LittleFS and SPIFFS.

The PCA10056 devkit with ARM Cortex M4 was used solely for the FDS experiments. As stated in the manuscript, FDS is highly integrated within the software development kit for Nordic chips, making it difficult to simulate. We attempted to simulate it, but the process was time-consuming with no results.

We have revised the 'Materials and Methods' section to better explain why FDS could not be simulated and why the PCA10056 devkit was chosen for the experiments. We also state more clearly that CFFS experiments were simulated and provide technical details on how implementation for different hardware platforms works and that the filesystem behaves the same.

_____

Comments 3:

At the final of section 1 I suggest the author to present the contents of each of the remaining sections.

Response 3:

The final paragraph of Section 1 now describes the remaining sections.

_____

Comments 4:

I felt that a sentence is missing at the end of section 2 to justify the presentation of the new file system in section 3.

Response 4:

We revised the end of the last paragraph in Section 2 to improve the transition to Section 3.

_____

Comments 5:

The results presented in section 4 complemented with a discussion in section 5 are both well described but I suggest you put section 6 before section 4. You should present the test conditions before presenting results.

Response 5:

The 'Materials and Methods' section has been moved before the 'Results' section, making it Section 4, with 'Results' as Section 5 and 'Discussion' as Section 6.

Reviewer 3 Report

Comments and Suggestions for Authors

This manuscript presents a detailed discussion of filesystem challenges for employment in low-power memory-constrained devices and, based on the reviewed concepts, proposes a modified CFFS filesystem, comprising also reliability control mechanisms. The proposed filesystem is compared to other alternative solutions in a few experimental scenarios. The overall quality of the manuscript is good, useful introductory material is included in the first sections and, eventually, novel solutions are reported with respect to prior arts in terms of filesystem strategies for low-power devices. The authors are invited to address the following points before the manuscript may be published.

1. In section 3.3, the discussion on the possibility of supporting multiple physical memories might be extended and its clarity improved.
2. In the case where on-chip memory is employed in the considered applications, would the proposed filesystem approach allow for minimization of the area occupation on-chip, appealing to application contexts with very strict cost and area constraints for the integrated circuit units? Please elaborate on this point.
3. The experimental methods used to derive the results of section 4 should be more clearly stated. Specifically, how were the memory utilization factors of fig. 5-6 measured.
4. Did the authors employ a physical memory to execute their tests or did they simulate through software representation on a computer?
5. There are a few typos to be corrected across the manuscript.
6. In section 5, a comparison table comparing the achieved results with those of prior works from the scientific literature reporting similar filesystem techniques should be included, if possible.

Comments on the Quality of English Language

N/A

Author Response

Thank You for your review and valuable suggestions to improve the paper.
The edits made in response to the review are highlighted in green in the revised manuscript. Some of these edits may overlap with changes from other reviews.

_____

Comments 1:

In section 3.3, the discussion on the possibility of supporting multiple physical memories might be extended and its clarity improved.

Response 1:

Section 3.3 has been completely revised to provide a clearer explanation and additional details. Additionally, a new figure (Figure 1) has been added to Section 3.1 to illustrate the relationship between the CFFS drive and the flash API bundle.

_____

Comments 2:

In the case where on-chip memory is employed in the considered applications, would the proposed filesystem approach allow for minimization of the area occupation on-chip, appealing to application contexts with very strict cost and area constraints for the integrated circuit units? Please elaborate on this point.

Response 2:

Section 2.2 now highlights that the advantage of low-level filesystems with a reduced feature set is their smaller memory footprint, making them ideal for small chips. This point is also reiterated in the 'Discussion' section.

_____

Comments 3:

The experimental methods used to derive the results of section 4 should be more clearly stated. Specifically, how were the memory utilization factors of fig. 5-6 measured.

Response 3:
Section 5.1 now provides a clearer explanation of how memory utilization was calculated during the experiments.

_____

Comments 4:

Did the authors employ a physical memory to execute their tests or did they simulate through software representation on a computer?

Response 4:
The 'Materials and Methods' section has been revised to clarify that the experiments for LittleFS, SPIFFS, and CFFS were simulated, while FDS was tested on hardware because it is highly integrated with it and cannot be easily simulated. However, when provided with the correct flash block size, block count and word size, CFFS simulation behaves identically to its hardware implementation, which has been thoroughly tested. The section also includes examples of how CFFS functions can be ported to different hardware platforms.

_____

Comments 5:

There are a few typos to be corrected across the manuscript.

Response 5:

We have corrected the typos we found throughout the manuscript.

_____

Comments 6:

In section 5, a comparison table comparing the achieved results with those of prior works from the scientific literature reporting similar filesystem techniques should be included, if possible.

Response 6:

We have added a table and its description to Section 5.4, comparing various characteristics of the tested filesystems and discussing their differences.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The authors addressed all my concerns. The paper can be accepted.

It'll be good to add a real application example for embedded system with a scheme.