[stgt] [BUG] Tgt-1.0.8 exited unexpectedly

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Tue Sep 28 08:29:55 CEST 2010

On Tue, 28 Sep 2010 15:15:16 +0900 (JST)
Hirokazu Takahashi <taka at valinux.co.jp> wrote:

> > I'm not sure the modern SATA disk can detect such failure.
> I think the modern SATA disk has this feature while the IDE disk doesn't
> have.

Do you have any pointer?

> > How Vastsky stores the information of the group?
> Actually Vastsky has a meta data node. When the structure of a logical
> volume has changed, the meta data related to the volume on the meta
> data node is updated. The meta data is cached at the node that uses
> the volume.

How can Vastsky handle the failure of the meta data node?

> > > And you should know VastSky won't easily give up a node which seems
> > > to be down. VastSky tries to reconnect the session and even tries to
> > > use another path to access the node.
> > 
> > Hmm, but it just means that a client I/O request takes long. Even if
> > VastSky doesn't give up, a client (i.e. application) doesn't want to
> > wait for long.
> Some applications don't like this behavior, but this is the policy of
> Vastsky. I think this behavior is the same as using FC-SAN storages.

it's true for whatever SCSI protocol, I guess
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

More information about the stgt mailing list