On 02/14/2016 12:43 PM, Carlos E. R. wrote:
On 2016-02-14 17:34, Olav Reinert wrote:
On Son, 2016-02-14 at 10:54 -0500, Anton Aylward wrote:
With writeback, bcache releases system calls as soon as the blocks involved have been written to the SSD. Flushing to the underlying storage happens later, asynchronously. Importantly, bcache guarantees that the system can be safely shut down even if the cache is dirty; it will resume flushing at the next reboot.
That's Olav, not me, that you're quoting.
Would fsck work with a dirty cache?
Cache where? What is "dirty' in this context? Is there an IOCTl that lets the sysadmin force the bcache to flush to disk? An equivalent of doing a "sync(2)" possibly via CLI "sync(1)". Ah, memories of "sync;sync;sync;shutdown"
Ie, does fsck know that it has to read both the HD and the SSD to do its job properly?
I'm not sure that's a valid question. oh, wait, yes there are (or should be/may be) really three 'raw' devices here. One for the bcache, one for the rest of the hard drive (backing device) and one for the logical drive regardless of any caching. If the fsck is done on the logical raw rather than the physical raw, then it should work. your question makes sense only if there is no 'logical raw' and the raw access to bcache device and the unflushed backing media are all that exist. Which gets back to the issue of forcing bcache to flush to the backing device. I suspect that its not as complicated as this. But I'd still expect a way to force the flush of the cache. Hmm, Googling for "bcache force flush" https://wiki.archlinux.org/index.php/Bcache#Force_flush_of_cache_to_backing_... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org