| |||||||||||||
A bcache updateA bcache updatePosted May 15, 2012 22:34 UTC (Tue) by intgr (subscriber, #39733)In reply to: A bcache update by koverstreet Parent article: A bcache update
> But for that to be useful we'd have to have writeback specifically pick bigger sequential chunks of dirty data and skip smaller ones, and I'm not sure how useful that actually is
That's certainly an important optimization for mixed random/sequential write workloads whose working set is larger than the SSD. To make best use of both kinds of disks, random writes should persist on the SSD as long as possible, whereas longer sequential writes should be pushed out quickly to make more room for random writes.
(Log in to post comments)
A bcache update Posted May 16, 2012 1:52 UTC (Wed) by koverstreet (subscriber, #4296) [Link]
Well, you want the sequential writes to bypass the cache, which is what bcache does.
If you can show me a workload that'd benefit though - I'm not opposed to the idea, it's just a question of priorities.
A bcache update Posted May 16, 2012 7:35 UTC (Wed) by intgr (subscriber, #39733) [Link]
> Well, you want the sequential writes to bypass the cache, which is what bcache does
Oh, I didn't realize that. That should take care of most of it. There's probably still some benefit to sorting writeback by size, but I'm not sure whether it's worth the complexity.
|
|||||||||||||