[stgt] Write-cache in tgtd during a target-host crash

[Chris Webb]

FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp> writes:

> On Wed, 14 Apr 2010 09:35:38 +0100
> Chris Webb <chris at arachsys.com> wrote:
> 
> > Will the initiator have retained the data that hadn't reached disk and
> > understand that it needs to resend, or will the volume end up corrupted with
> > the initiator's page cache not matching the real content on the disk?
> 
> I think that it depends on what you run on the initiator. For example,
> when many file systems (such as ext3) hits a nexus loss (the target
> crashes), makes the disk offline. Then the page cache on the initiator
> will be lost.
> 
> Note that data corruption is different from data loss.

Hi. I'm accessing the iscsi block device directly on the initiator, not via
a filesystem. (It's actually a qemu using the block device as a disk.)

I currently have the write cache turned off on the target and
node.session.timeo.replacement_timeout = 86400 on the initiator. The
behaviour at present is that, if I crash or reboot the target, IO to the
block device on the initiator is paused, and when the target comes back,
the initiator logs in again and IO seamlessly resumes.

My worry is that, if I turn on write caching on the target, there isn't an
obvious way for IO to resume without corrupting the content of the block
device because in-flight IO has been lost with the target crash but
subsequent IO will then succeed. The writes that hadn't been flushed to disk
will be silently lost without the qemu on the initiator knowing anything is
wrong.

Am I misunderstanding how this works, though?

Cheers,

Chris.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html