[email protected] said:
> If a device can be accessed by multiple machines concurrently, it
> should not be in driverfs.
On that argument, we'll eliminate almost all Fibre Channel devices!
I think the qualification for appearing in driverfs is actually possessing a
driver. Therefore, we accept FC and iSCSI. Things which appear as
FileSystems are debatable, but not anything which has a real device driver.
> We need a device tree to do PM. If driverfs's PM capabilities are hurt
> because it doesn't stay true to that, then the featureitis has gone
> too far.
Perhaps it's more a question of whether power management belongs as an every
unit item in driverfs. As you say, we get problems where the device is shared
between multiple computers.
James
On Mon, 24 Jun 2002, James Bottomley wrote:
> [email protected] said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs.
>
> On that argument, we'll eliminate almost all Fibre Channel devices!
>
> I think the qualification for appearing in driverfs is actually possessing a
> driver. Therefore, we accept FC and iSCSI. Things which appear as
> FileSystems are debatable, but not anything which has a real device driver.
Between iSCSI and filesystems there's still MD, loopback, ramdisk, NBD,
LVM, and general partitioning. They all expose block devices and try their
damnedest to look like physical devices. If we're serious about using
driverfs as a system for unifying device detection ("show me all my disks,
please"), then these should all be in too.
And they raise some interesting problems. As pointed out earlier, iSCSI is
potentially multipath, as is LVM, NBD, and software RAID. Hardware RAID is
already multipath in some cases so our tree really ought to be a DAG.
And let's think about loopback a moment. It's potentially layered on top
of a filesystem, layered on top of a logical volume layered on top of SCSI
and ATA. Just from the power management perspective, to quiesce our
system, we'll have to know that we need to flush loop->fs->lvm->scsi/ata
before we can shut down whichever drive.
So to be done right, we need to pull filesystems into the tree too (rather
than just implicitly correlating against /proc/mounts).
> > We need a device tree to do PM. If driverfs's PM capabilities are hurt
> > because it doesn't stay true to that, then the featureitis has gone
> > too far.
>
> Perhaps it's more a question of whether power management belongs as an every
> unit item in driverfs. As you say, we get problems where the device is shared
> between multiple computers.
And we already have a problem there for local SCSI - see OpenGFS which
lets you share a filesystem on a single SCSI bus. Admittedly, that's
rather sick, but not as appalling for FC, iSCSI, or NBD (or GFS's
internal equivalent).
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
> I think the qualification for appearing in driverfs is actually possessing a
> driver. Therefore, we accept FC and iSCSI. Things which appear as
> FileSystems are debatable, but not anything which has a real device driver.
The qualification for appearing in the device tree is the physical
presence of the device, regardless of the presence of a driver to control
it. (This typically depends on the presence of the bus driver so it can
discover the device.) Presence in the device tree implies presence in
driverfs.
-pat