Mailinglist Archive: opensuse (1470 mails)

< Previous Next >
Re: [opensuse] experiences with bache / logic of caching
On 2016-02-14 19:04, Anton Aylward wrote:
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:

A write cache that 'accelerates' by releases the system call while
deferring the actual transfer from the cache to storage simply cannot
guarantee the integrity of the file system in the event of, for example,
a power loss. Certainly a SSD, which will retain content, can, if the
supporting software is there to do the job, ameliorate this. It gets
back to the issue of the window/timing. But there are a few too many
'ifs" in this to inspire confidence in an old cynic like me.

That paragraph was missing.

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?

data or metadata in the SSD, waiting to be transferred to the rotating
disk. Power failure, crash, whatever, and the thing is dirty.

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.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)

< Previous Next >