lkml.org 
[lkml]   [2002]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] /proc/scsi/map

    On Fri, 21 Jun 2002, Oliver Xymoron wrote:

    > On Thu, 20 Jun 2002, Patrick Mochel wrote:
    >
    > > > But it was entierly behind me how to fit this
    > > > in to the sheme other sd@4,0:h,raw
    > > > OS-es are using. And finally how would one fit this in to the
    > > > partitioning shemes? For the system aprtitions are simply
    > > > block devices hanging off the corresponding block device.
    > >
    > > Partitions are purely logical entities on a physical disk. They have no
    > > presence in the physical device tree.
    >
    > As I raised elsewhere in this thread, the distinction between physical and
    > logical is troubling. Consider iSCSI, (aka SCSI-over-IP). It's analogous
    > to SCSI-over-Fibre Channel, except that rather than using an embedded FC
    > stack, it's using the kernel's IP stack. But it's every bit as much a SCSI
    > disk/tape/whatever as a local device. Ergo, it ought to show up in the
    > device tree so that it can be discovered in the same way. But where?

    An iSCSI device is a physical device; it just doesn't reside on the local
    system. We should represent the device in some physical form, since the
    logical class mappings do/will assume a mapping to a physical device.

    These devices are essentially children of the network via which they're
    attached. When devices are discovered, I'm assuming you can derive the
    network device through which you're communicating, so you can get enforce
    the ancestral relationship.

    You want the ancestral relationship for several reasons. You'd wouldn't
    power down such a device on PM transitions or during shutdown, but you
    would stop I/O transactions. The drivers for these devices should recogize
    it's a remote device and handlethis. And, if you were to remove the bridge
    device (the network card, etc), you want the devices behind it and their
    logical mappings to go away gracefully.

    Mulitpath devices, which you could easily have with multiple routes to the
    same IP address, are another issue that must be addressed. It hasn't yet,
    but we're getting closer...

    -pat

    -
    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:22    [W:0.027 / U:0.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site