FYI, this was described by FP Complete in the audit report released today, page 19.
Currently, each block is stored in an individual file. However, as documented at https://github.com/input-output-hk/cardano-sl/issues/2224, this has disadvantages. There is a proposal to fix this issue at: https://github.com/input-output-hk/cardano-sl/blob/535c36cf9496958e96aabf57bb875012060b3b34/docs/proposals/block-storage.md. From the point of view of code simplicity and reliability, however, it would be better to use preexisting solutions designed to solve these problems.
One example would be SQLite, which explicitly documents its abilities to replace multiple small files on a filesystem with a single database: https://www.sqlite.org/fasterthanfs.html. There may be mitigating factors preventing the usage of such a more commonly used storage technology, but there is no evidence of such a conclusion having been reached.
Barring such evidence, our conclusion is that the current storage methodology, and plans for mitigating current risks, introduces undue risk to the project in terms of code complexity, potential data loss, and logic errors.
First occurrence: February 2018
We acknowledge that the use of many small files is not a good long term design choice for several reasons. It was an expedient choice during rapid development. We are re-analysing the requirements of the whole storage subsystem, both block storage and associated indexes, and will then choose a new design. This process, including migration, must be done properly and we anticipate that it will take considerable time.