On Tue, May 12, 2009 at 12:36:26AM -0600, Dan Maslowski wrote: > COMSTAR and ZFS are already in the embedded storage space. For USB, > target is a function of a physical cable (which end you are on > designates host vs initiator), so not really possible, even if it were > interesting unless you did some serious spoofing and unnatural things > (at least I think so).
USB has defined host and target modes, and there are target-mode
drivers over which, with a few layers in between, the scsi protocol
runs. Not much different to SAS or FC, at this 25-words-or-less
level, and mostly simpler.
> Firewire is perhaps possible, but I don't know
> enough about firewire to know.
Same broad answer with at least one key difference, firewire supports
multiple initiators on a bus.
> All that being said, we have at least
> three port providers that are samples and should be relatively easy to
> use as a baseline... I just don't know how interesting it would be to
> the consumer space. The only reason I can think of would be cost, and, I
> just don't see the relevance of COMSTAR and ZFS for a music player or
> other consumer electronic device.
I'm not thinking so much of such small embedded devices running ZFS,
though there's already plenty of scope for not-quite-that-small
devices, NAS and similar. There's no reason the below wouldn't be
useful in those too, but that's secondary to my query.
I'm thinking more of two cases:
* utilising commodity interfaces available in the hardware already in
the field.
* providing services *to* embedded devices that only know how to
use these interfaces and transports
iSCSI via ethernet is the obvious first choice for commodity
interfaces, however:
- lots of machines have only 100M ethernet, or have other demands on
ethernet port count or bandwidth, yet also have 400M (or 800M)
firewire ports sitting idle. Oh, and they support much larger
frames than puny jumbo ethernet, too.
- iscsi initiators are not available/stable/bootable/etc for all
platforms, and in any case involve configuration, driver
installation, test & cert & support ("appliance") issues, etc.
These can likely use (and boot from) usb or firewire disks with no
effort or changes.
The embedded device second case is just a stronger instance of the
above; there are loads of media players, surveillance or video cameras
or music editing widgets that can use a firewire or usb hard disk (I
pick these examples mostly for the firewire bias in this space). Even
existing storage appliances or established software one-touch-backup
systems that want an external backup disk could be readily redirected
to use a zvol on a "real machine" as backing store. Add compression,
remote replication, snapshots, de-dup and other zfs goodness from
there. Think about test images for the developers of such gadgets.
There are plenty of existing devices and systems in working use that
are hard to change or replace easily, or that just aren't broken
despite some limitations, which could be enhanced via such means.
(It would also be nice to have targets for older scsi controllers and
transports - great for keeping retro machines going while eliminating
noise and power for cruddy small old disks. Just an aside, though).
> Regards,
> Dan
And you :)
--
Dan.
pgplYDsZFinik.pgp
Description: PGP signature
_______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
