On Thu, Mar 27, 2003 at 09:10:14AM +1100, Lincoln Dale wrote:
> At 10:09 AM 26/03/2003 -0600, Matt Mackall wrote:
> >> >Indeed, there are iSCSI implementations that do multipath and
> >> >failover.
> >>
> >> iSCSI is a transport.
> >> logically, any "multipathing" and "failover" belongs in a layer above
> >it --
> >> typically as a block-layer function -- and not as a transport-layer
> >> function.
> >>
> >> multipathing belongs elsewhere -- whether it be in MD, LVM, EVMS,
> >DevMapper
> >> PowerPath, ...
> >
> >Funny then that I should be talking about Cisco's driver. :P
>
> :-)
>
> see my previous email to Jeff. iSCSI as a transport protocol does have a
> muxing capability -- but its usefulness is somewhat limited (imho).
>
> >iSCSI inherently has more interesting reconnect logic than other block
> >devices, so it's fairly trivial to throw in recognition of identical
> >devices discovered on two or more iSCSI targets..
>
> what logic do you use to identify "identical devices"?
> same data reported from SCSI Report_LUNs? or perhaps the same data
> reported from a SCSI_Inquiry?
Sorry, can't remember.
> does one now need to add logic into the kernel to provide some multipathing
> for HDS disks?
No, most of it was done in userspace.
> >> >Both iSCSI and ENBD currently have issues with pending writes during
> >> >network outages. The current I/O layer fails to report failed writes
> >> >to fsync and friends.
> >>
> >> these are not "iSCSI" or "ENBD" issues. these are issues with VFS.
> >
> >Except that the issue simply doesn't show up for anyone else, which is
> >why it hasn't been fixed yet. Patches are in the works, but they need
> >more testing:
> >
> >http://www.selenic.com/linux/write-error-propagation/
>
> oh, but it does show up for other people. it may be that the issue doesn't
> show up at fsync() time, but rather at close() time, or perhaps neither of
> those!
Write errors basically don't happen for people who have attached
storage unless their drives die. Which is why the fact that the
pagecache completely ignores I/O errors has gone unnoticed for years..
> code looks interesting. i'll take a look.
> hmm, must find out a way to intentionally introduce errors now and see what
> happens!
We stumbled on it by pulling cables to make failover happen.
-- Matt Mackall : http://www.selenic.com : of or relating to the moon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:26 EST