On 5/12/17, Kai Krakow <hurikhan77@xxxxxxxxx> wrote: > I don't think it is important for the file system to know where the SSD > FTL located a data block. It's just important to keep everything nicely > aligned with erase block sizes, reduce rewrite patterns, and free up > complete erase blocks as good as possible. Yeah. "Tight packing" of data into erase blocks will reduce fragmentation at flash level, but not necessarily the fragmentation at fs level. And unless we are writing in continuous journaling style (as f2fs ?), we still need to have some info about the erase blocks. Of course while these are going on, there is also something like roundrobin mapping or some kind of journaling would be going on at the low level flash as wear leveling/bad block replacements which is totally invisible to us. > Maybe such a process should be called "compaction" and not > "defragmentation". In the end, the more continuous blocks of free space > there are, the better the chance for proper wear leveling. Tight packing into erase blocks seems dominant factor for ssd welfare. However, fs fragmentation may still be a thing to consider because increased fs fragmentation will probably increase the # of erase blocks involved, affecting both read/write performance and wear. Keeping an eye on both is a though job. Worse there is "two" uncoordinated eyes one watching the "fs" and the other watching the "flash" making the whole process suboptimal. I think the ultimate utopic combination would be "absolutely dumb flash controller" providing direct access to physical bytes and the ultimate "Flash FS" making use of possible performance, wear leveling tricks. Clearly, we are far from it. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
