[Stgt-devel] User-mode iSER
FUJITA Tomonori
fujita.tomonori
Sun Aug 6 15:48:50 CEST 2006
From: "Alexander Nezhinsky" <nezhinsky at gmail.com>
Subject: Re: [Stgt-devel] User-mode iSER
Date: Sun, 6 Aug 2006 14:00:02 +0300
> > tgt thinks that it does a write-back. The initiators can use
> > SYNCHRONIZE_CACHE, ordering write, etc for data integrity. And when
> > the target code is asked to write the data to storage permanently, we
> > can use fsync, msync, etc.
>
>
> 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
For further information, see:
Documentation/block/barrier.txt
More information about the stgt
mailing list