[Stgt-devel] User-mode iSER

[Alexander Nezhinsky]

 Fujita,



> For further information, see:
> Documentation/block/barrier.txt


 First of all, thanx for the reference.


> As far as I understand, SYNCHRONIZE_CACHE command is not intended as a
> tool
> > to be used by the initiators to avoid possible cache-related data
> > corruption. It rather should be used "to ensure that the data was
> written
> > and any detected errors reported" (citation from SBC-2 spec).
> > In case of power-off, h/w failures etc. the target should guarantee that
> all
> > cached data are written to the medium (or backed up, saved
> etc.)  regardless
> > of the initiator's actions.
> > At some points (presumably related to application semantics) initiator
> may
> > be interested to receive either success status or all possible errors
> > resulting from the actual I/O, but this command should not be used to
> > guarantee data integrity.
> >
> >
> > > > > > > Modern operating systems and applications
> >
> > > > (like file systems) does not
> > > > > > > need help from battery-backed memory to enjoy
> > > > > write-behind cache on
> > > > > > > SAN target devices for better performance without data
> corruption
> > > > > > > risks. So page cache is always useful.
> > > > > >
> >
> >
> > How does linux cope with this? I never saw anything that "funky" in the
> scsi
> > command logs sent by a linux initiator.
>
> Interesting. I just created one file on ext3 with iSCSI and saw
> several SYNCHRONIZE_CACHE commands. :)
>
> For your convenience, I've put the tcpdump log.
>
> http://zaal.org/cache.cap


After playing a bit with our system i understood why we don't see
SYNCHRONIZE_CACHE
commnds. All our disks are reported "write-through". So there is no need to
sync cache.

But anyway, I meant primarily the modes of operation that are not
file-system related.
For example, with etx3 sync'ing the journal is clearly  the kind of
"application-related" operation that needs an explicit flush/barrier.
My question was mainly related to the cases when no such need occurs
naturally.
What if the user works with the raw unpartitioned device -- does he still
get a guarantee of correct operation under failures? And if it is done
through sg driver (not through the block device subsystem)?
Do you imply that if the devices are reported as write-back (plus capable of
performing flushes etc) then the problem is solved even if the cache is
de-facto volatile?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://bat.berlios.de/pipermail/stgt-devel/attachments/20060806/bcc2f64b/attachment.html