on-board (dram) cache #89
EndlessEden
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I dont know if this has been brought up before, but its one of the major downsides to alot of these projects. Using SD media means dealing with the terrible sustained write/read speeds the format brings, alongside the many compromises the formfactor endures.
Adding permanent cache to the board, would help if not solve alot of the headaches of dealing with SD media in the first place.
Buffer-Overflow Corruption: A lack of cache for the interface to pump data through could be why a lot of users seem to report issues with exfat and the like. Judging by many similar projects that have run into this same issue. A common similarity of all SD Media Controllers is its difficulty in handling sudden bottlenecks with write operations. The SD media's sustained writes simply cant keep up with the larger file tables, and ends with data corruption to the table. Thus, since the filesystem doesn't have checksumming support and the media doesn't have a external metadata table to compare it to, the data corrupts.
Improved Sustained Write Performance: I could be wrong on this, but as we have seen from the commercial SSD space. dram cache located between the interface and the flash media has a massive improvement on burst write speeds. This alone helps with many of the applications such a project would see in the real world. More so given the nature of multiple vdev's on the same media.
Reduced wear: Due to caching writes (and possible reads too) in dram, the buffer provides a way to reduce wear on the SD from constant read/write cycles. Adding a timer to flush-to-media means things like text files, updates, and even repeated media tests can be delayed. increasing the write (and read) endurance of the SD media.
Vastly improved read performance: A dram powered cache can reduce the latency of access the filesystem, simply by having the filetable stored in cache, reducing unecessary cpu cycles waiting to access the vdevs filetables. This is further improved as by having a cache, large files that are accessed often, would be instantly accessible and not suffer the sustained read operation limitations the media normally would suffer from. Things like rebooting the entire OS could be made nearly instantaneous, just by reading it from cache rather than the media.
Future expansion: Having off-media caching can even provide a method of performing error checking during write and read operations. having a copy of the data being written can allow one of the major difficulties of the media to be overcome. With the inclusion of a battery-backup even, it could even prevent unfinished writes during a power-failure from corrupting the entire media. A big drawback to SD media.
I hope these ideas are of some use to the project and even if such things are infeasible, it at least provides some prompting to issues faced with the media that may be overcome in various ways.
SCSI is not dead, and is used across many platforms. Projects such as this not only provide legacy hardware with new life, but also provide industrial equipment a way to prolong their lifespan beyond planned obsolesces via proprietary OEM manufacturers.
Beta Was this translation helpful? Give feedback.
All reactions