Editing Log-structured file system (section)

== Disadvantages ==
The [[design rationale]] for log-structured file systems assumes that most reads will be optimized away by ever-enlarging memory caches. This assumption does not always hold:
* On magnetic media—where seeks are relatively expensive—the log structure may actually make reads much slower, since it [[fragmentation (computer)#External fragmentation|fragments]] files that conventional file systems normally keep contiguous with in-place writes.
* On flash memory—where seek times are usually negligible—the log structure may not confer a worthwhile performance gain because write fragmentation has much less of an impact on write throughput. Another issue is stacking one log on top of another log, which is not a very good idea as it forces multiple erases with unaligned access.<ref name="logonlog">{{citation|title=Don't stack your Log on my Log|url=https://www.usenix.org/system/files/conference/inflow14/inflow14-yang.pdf|publisher=SanDisk Corporation|year = 2014|first1 = Jingpei Yang|last1 =Swaminathan Sundararaman}}</ref> However, many flash based devices cannot rewrite part of a block, and they must first perform a (slow) erase cycle of each block before being able to re-write. By putting all the writes in one block, this can help performance as opposed to writes scattered into various blocks, and each one must be copied into a buffer, erased, and written back, which is a clear advantage for so-called "raw" flash memory where flash translation layer is bypassed.{{cn|date=June 2017}}