FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> writes: > On Wed, 14 Apr 2010 09:35:38 +0100 > Chris Webb <chris@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
