lkml.org 
[lkml]   [2003]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] ENBD for 2.5.64
    On Thu, 27 Mar 2003, Lincoln Dale wrote:

    > > > to traditional SAN storage and you're gatewaying into Fibre Channel).
    > >
    > >Why a SAN gateway switch, they are all LAN limited.
    >
    > ?
    > hmm, where to start:
    >
    > why a SAN gateway?
    > because (a) that's what is out there right now, (b) iSCSI is really the
    > enabler for people to connect to consolodated storage (that they already
    > have) at a cheaper price-point than FC.
    >
    > LAN limited?
    > 10GE is reality. so is etherchannel where you have 8xGE trunked
    > together. "LAN is limited" is a rather bold statement that doesn't support
    > the facts.
    >
    > in reality, most applications do NOT want to push 100mbyte/sec of i/o -- or
    > even 20mbyte/sec.
    > sure -- benchmarking programs do -- and i could show you a single host
    > pushing 425mbyte/sec using 2 x 2gbit/s FC HBAs -- but in reality, thats way
    > overkill for most people.

    We agree this is even overkill for people like Pixar and the movie people.

    > i know that your company is working on native iSCSI storage arrays;
    > obviously its in your interests to talk about native iSCSI access to disks,
    > but right now, i'll talk about how people deploy TB of storage today. this
    > is most likely a different market segment to what you're working on (at
    > least i hope you think it is) - but a discussion on those merits are not
    > something that is useful in l-k.

    Well we deploy ERL=1 or ERL=2(%80) today on 6TB platforms now.
    So the democratization of SAN is now and today.

    > > > handling multipathing in that manner is well beyond the scope of what an
    > > > iSCSI driver in the kernel should be doing.
    > > > determining the policy (read-preferred / write-preferred / round-robin /
    > > > ratio-of-i/o / sync-preferred+async-fallback / ...) on how those paths are
    > > > used is most definitely something that should NEVER be in the kernel.
    > >
    > >Only "NEVER" if you are depending on classic bloated SAN
    > >hardware/gateways. The very operations you are calling never, is done in
    > >the gateways which is nothing more or less than an embedded system on
    > >crack. So if this is an initiator which can manage sequencing streams, it
    > >is far superior than dealing with the SAN traps of today.
    >
    > err, either you don't understand multipathing or i don't.
    >
    > "multipathing" is end-to-end between an initiator and a target.
    > typically that initiator is a host and multipathing software is installed
    > on that host.
    > the target is typically a disk or disk-array. the disk array may have
    > multiple controllers and those show up as multiple targets.

    Agreed, and apply as series of head-to-toe target-initiator pairs and you
    get multipathing support native from the super target. This is all a SAN
    gateway/switch does. Not much more than LVM on crack and a six-pack.

    > the thing about multipathing is that it doesn't depend on any magic in "SAN
    > hardware/gateways" (sic) -- its simply a case of the host seeing the same
    > disk via two interfaces and choosing to use one/both of those interfaces to
    > talk to that disk.

    Well Storage is nothing by a LIE and regardless if one spoofs and ident
    mode pages or not, they must track and manage the resource reporting
    properly.

    > [..]
    > >What do you have for real iSCSI and no FC junk not supporting
    > >interoperability?
    >
    > ?
    > no idea what you're talking about here.

    Erm, shove a MacData and Brocade switch on the same FC network and watch
    it turn into a degraded dog.

    > >FC is dying and nobody who has wasted money on FC junk will be interested
    > >in iSCSI. They wasted piles of money and have to justify it.
    >
    > lets just agree to disagree. i don't hold that view.

    Guess that is why NetAPP snaked a big share of EMC's marketspace with a
    cheaper mousetrap. Agreed to "agree to disagree" erm whatever I just
    typed.

    > > > not bad for a single TCP stream and a software iSCSI stack. :-)
    > > > (kernel is 2.4.20)
    > >
    > >Nice numbers, now do it over WAN.
    >
    > sustaining the throughput is simply a matter of:
    > - having a large enough TCP window
    > - ensuring all the TCP go-fast options are enabled
    > - ensuring you can have a sufficient number of IO operations outstanding
    > to allow SCSI to actually be able to fill the TCP window.
    >
    > realistically, yes, this can sustain high throughput across a WAN. but
    > that WAN has to be built right in the first place.

    Well sell more of those high bandwidth switches to the world of
    internet-ether to make it faster, I would be happier.

    > i.e. if its moving other traffic, provide QoS to allow storage traffic to
    > have preference.
    >
    > >Sweet kicker here, if you only allow the current rules of SAN to apply.
    > >This is what the big dogs want, and no new ideas allowed.
    >
    > i definitely don't subscribe to your conspiracy theories here. sorry.

    You should listen to more Art Bell at night, well morning for you.

    > >PS poking back at you for fun and serious points.
    >
    > yes - i figured. i'm happy to have a meaningful technical discussion, but
    > don't have the cycles to discuss the universe.

    I did the universe once as an academic, it was fun.

    http://schwab.tsuniv.edu/t13.html

    This was my last time of stargazing and I miss it too!

    Cheers,

    Andre Hedrick
    LAD Storage Consulting Group

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:3.787 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site