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

[Chandra Seetharaman]

On Wed, 2010-04-21 at 19:51 +1000, ronnie sahlberg wrote:
> 
> 
> Tomo, would a patch that allows setting the O_DIRECT/O_SYNC flags on
> the command line when invoking tgtd be acceptable?
> 
> 
> 
> 
> tgtd -o O_SYNC     tgtd -o O_DIRECT      tgtd -o O_SYNC|O_DIRECT
> 
> 
> 
> The appropriate flags in the caching mode page could be intercepted
> and use to toggle these fd settings.
> 
> My filesystem of choice would likely benefit greatly from O_DIRECT.

I see the feature being useful.

But, I would associate this to be a characteristic of the backing store
than set it globally at tgtd (or we can have a it at global(read tgtd
level) and ability to revert it at the backing store).
> 
> 
> 
> regards
> ronnie sahlberg
> 
> 
> On Wed, Apr 21, 2010 at 7:22 PM, Chris Webb <chris at arachsys.com> wrote:
> > 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
> >
> --
> 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

--
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