= Solution
Reusing a block-oriented <file system> preserves existing operating-system interfaces, tools, consistency procedures and on-disk formats. It also permits common buffering and caching policies. Large transfers can still amortize software and controller overhead, and <flash memory> itself has page-program and erase-block constraints, so a <block device> abstraction is often useful even without mechanical motion.
The costs are that a fine-grained change may require reading and rewriting a larger logical block, and a small <computer file> can waste part of its final <file data block>. Structures optimized to reduce <seek time> need not be best for <non-volatile memory>. For <flash memory>, repeated metadata updates and erasing or relocating larger regions can increase physical writes and consume finite program/erase endurance. A translation layer can hide these constraints but adds mapping space and work.
Consequently
$$
\boxed{\text{compatibility and reuse trade against wasted space, extra writes and missed device-specific optimizations}.}
$$
The balance depends on the actual medium: byte-addressable <non-volatile memory> and page/erase-based <flash memory> have different physical constraints.
Back to article page
