[stgt] [BUG] Tgt-1.0.8 exited unexpectedly

[FUJITA Tomonori]

On Mon, 27 Sep 2010 12:41:40 +0900 (JST)
Hirokazu Takahashi <taka at valinux.co.jp> wrote:

> > > I want VastSky which is a cluster storage system to use TGT as its
> > 
> > Interesting. There are some similar experiments. IBM does the similar
> > and I also did the similar with OpenStack. RedHat Hail does the
> > similar with their own iSCSI target implementation.
> > 
> > Out of curiosity, can VastSky avoid reading the old data?
> > 
> > For example, WRITE goes to the three replica nodes, then WRITE to the
> > same sector fails on the first replica node (e.g. timeout because the
> > node is too busy) but succeeds with the rest two nodes (so the two
> > nodes have the newer data).
> > 
> > Then if the two nodes having the new data are down, is it possible
> > that an initiator gets the old data from the first node (when the
> > initiator issues READ to the same sector)?
> 
> In that case, VastSky just returns an EIO error. I won't change this

I see. Sheepdog works in the same way.


> policy since volumes VastSky serves are supposed to be used with
> file-systems on them. If a volume returns the wrong date including
> the old data will cause a filesystem corruption easily.

Yeah, but even real disk could return bogus data (that is, silent data
corruption). So this issue (returning bogus data) is about the
possibility.

In addition, as you know, the recent file systems can handle such
failure.


> VastSky updates all the mirrors synchronously. And only after all
> the I/O requests are completed, it tells the owner that the request
> is done.

Undoerstood. Sheepdog works in the same way.

How does Vastsky detect old data?

If one of the mirror nodes is down (e.g. the node is too busy),
Vastsky assigns a new node? Then if a client issues READ and all the
mirrors are down but the old mirror node is alive, how does Vastsky
prevent returning the old data?
--
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