>I thought (and maybe I'm wrong) that a good chunk of reserved space was >essential to allow the drive to efficiently manage its read-modify-write >cycles.
Correct. The industry ~standard of 7% (basically the difference between GiB and GB) is woefully inadequate for any kind of steady write load. ALL enterprise SSDs use north of 20% and and I've seen as high as 50%. > It was my understanding that bcache was explicitly designed to fill erase > block sized > chunks sequentially and discard them in whole units, > negating the requirement for the drive to actually perform RMW cycles RMW is an essential and inalienable of how an SSD works. Every manufacturer can use different page and erase block sizes. And much of the time they don't publish the specs publicly. So while Kent may have gone to deliberate length to optimize the way BCache does IO by using aligned, suitably large chunks (eg. 128KB-512KB) he has zero control over what the firmware decides to do. BTW, did you undo the retarded disk label that Linux has used for decades which is guaranteed to cause mis-aligned I/O? I expect BCache will start it's data area at 1MB offset from where the device starts. But it can't do much to remedy the problem if you didn't align the partition or LV you handed BCache correctly to begin with. -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
