Re: [PATCH] ENBD for 2.5.64

[Matt Mackall <mpm@selenic.com>]

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