Slashdot Mirror
Sharing an IEEE 1394 Device Between Machines?
groovemaneuver asks: "A question was posted recently regarding sharing a SCSI disk between multiple machines. Firewire was mentioned as an alternative, but there wasn't much elaboration. Is there anyone out there using an IEEE 1394 solution for shared storage between two or more boxes? I've managed to dig up ads for a bunch of enclosures that feature multiple firewire ports, but nothing to indicate that it was possible to connect any of them to multiple machines. The only thing close that I've found was the SANCube, and aside from being fairly pricey (defeating my purpose for using firewire), it is only officially supported as a Mac/Win device."
this might be waht you want ... The documentation wasn't immediately clear to me so I might be off the mark.
Thoughts on tech, Software Engineering, and stuff
...not to use Linux, now isn't it?
Join us on the dark side - the water's fine.
It's not easy to have a device shared between two computers. Especially if it's firewire. What happens is two independent machines are trying to control the same piece of hardware. Of course both of them will think that the drive is messed up.
If you really want to share a drive between machines, and they are close enough for firewire, then you might as well use the tried and true method. First install the drive in one machine, then connect both machines together and transfer data over the network. If you really need it to be faster than that try gigabit ethernet.
The GeekNights podcast is going strong. Listen!
That's all I need, two computers with two different ideas of how the filesystem should look performaing simultaneous reads/writes on the same disk fubaring everything. Are you sure this is what you want? Why not just use simple ethernet sharing, NFS/Samba/whatever? I'm thinking it would be a lot more stable.
-- iCEBaLM
Bitches
Networking is a good idead because
It's scalable. as you can add more machines later with minimal fuss
It isn't any slower over ethernet (especially 100Mb and 1000Gb)
LAN parties!!!
easily setup multiple os's to see the drive.
It's a bad idea because
It's not scalabe (easily)
you risk data corruption (even if it works)
the drive can't handle more than 1 operation at a time
it's an IDE drive, therefore the drive handles the rules of IDE, the bus is Firewire, but the adapter handles the rules of that
some os's expect different things out of a filesystem, Windows expects it to be nice and neatly formatted in fat32 or ntfs. Linux expects etx2 or etx3 (or any slew of others) to be formatted in that method. Mac's expect to see a partition table and that's it (that's why formatting a mac hd takes only as long as hitting the "Initialize" button) Therefore it is not an easily cross-platform scalable data-safe method. Use the network option, it isn't noticably slower, it is cross-platform very scalable very data-safe.
/* oops I accidentally made a comment, sorry */
It's my hope to use EVMS as my stripe-manager on each side. It seems that this is one of the things EVMS was originally built for on AIX. I will treat this like RAID4, with all of the parity information on a single spindle.
The only problem I forsee with this is that - although FireWire supports "hot plugging" - replacing a failed drive will result in putting a break in the loop, causing a different number of drives to appear as having failed on each side of the cluster. The long-term solution for this is to use ATA swappable trays in the front of FireWire chassis designed for removeable media.
It 'aint my root filesystem, so one thing at a time!
"Flyin' in just a sweet place,
Never been known to fail..."
The hardware side should work: Firewire is a relaying point-to-point protocol and it supports two "host computers" because it doesn't use the "controlling host vs dumb device" concept. For example, you can connect two computers and have them talk TCP/IP over firewire. The software side is what needs more investigation: Is a device in an exclusive logical connection when it talks to another device? In other words, does the device have to specifically support multi-device connections? And if it does have to, do firewire-to-ide converters support it? The protocol logs of the Linux firewire driver mention a "log in" to the device when a firewire harddisk is connected. Maybe someone who knows the firewire protocol in deep can elaborate on that.
Are you crazy? Use a network filesystem hosted on one machine, or network storage. Sharing the same physical drive between two concurrently-running operating systems will require special drivers and extra communication between the two (at best), and be totally unreliable at worst.
Also see Ask Slashdot: IEEE1394-based Storage Area Network?
The software to manage multiple access via firewire was recently released GPL by Oracle.
-I like my women like I like my tea: green-
..devices like CDRW, too?
:-)] one machine here has to run W2K), I'm hoping it might get easier..
Can you do this with USB/USB2, too?
I've got four machines, 3 printers, two external CDRW drives, etc., and it'd be nice to quit having to switch machines or connections to access most of my devices.
Now that I'm going all Linux (except for the wife's machine -- until Photoshop runs efficiently in WINE, or I buy her a Mac [which may have to happen
You obviously have never done ANY sort of high availability clustering. This is an extraordinarily common and important concept that many people pay LOTS of money to get. Veritas Cluster File System (and the other components of the Veritas Cluster suite) do exactly this (and more) at a serious premium.
This is the way people with real uptime requirements do it. I know, because I've got systems that do this, and I've interviewed I can't tell you how many sysadmin candidates with the same experience.
As for networking, your points are all completely wrong and irrelevant for serious high performance, high availability applications. Ethernet has far too high an overhead (at least with any commonly available file service protocols. iSCSI *might* change all that, but it remains to be seen), scalability at the # of transactions per second IS LOWER over these protocols, and LAN parties aren't any kind of interest for people running serious databases.
As for why you think it's a bad idea, all of them are what the various software packages out there are for. I won't get into the IDE v. SCSI v. FireWire argument.
Please, stop assuming the desktop is where computing ends. It isn't.
www.gimp.org
Im not here now... Im out KILLING pepperoni
But we've hooked up 2 Powerbooks and a G4 Mac, and shared 2 Firewire HD's, 1 scanner, and 1 digital camera.
All the Mac's see it, and you also see the other Mac's HD's on your connection, if you have filesharing on.
We have a SANCube here at work. It's not really full sharing of a device either. Only one computer can have read/write access at a time, and this has to be switched manually via software. The others connected can have read access. It's prone to problems, and the only way to fix file system problems is a reformat - a serious PITA if it's nearly full.
It also doesn't have OS X support. Right now it's been turneded into a JOBD for a single user machine. If we need to share it, we still use the LAN, so if we were sharing data full time, we would just leave file sharing on, or hook it to a file server.
As others have said, get some form of NAS/file server.
I am, and always will be, an idiot. Karma: Coma (mostly effected by
I don't remember the exact product line, but I used to work at a company with 2 Ultra2s connected together with firewire that shared a firewire disk enclosure. They used Sun's clustering software. This is probably not a solution for you, but their stuff may give you some idea of how to get your project to work
in IDE, the controller and computer do not tell the drive how to write data, they just tell it what to write. they say, burn this data to the MBR, then burn this here and that there. they do not "controll" the device but they "instruct" it. get it?
theirfor, and IDE device on a firewire chain functions properly and without any problems because, computer 1 says "write this here" and it happens, and computer 2 says, "write this here" and the drive says "their is data their, overwrite?" and then computer 2 says, "naw, just write it over their instead." get it?
nice and easy, IDE drives are "smart", they are self-controlling, they have a buffer to help keep things straight and arange data for reading or writeing and to improve performance. to show the difference of "smart" and "dumb" devices, a floppy is dumb, it only does EXACTLY what the floppy controller says to do, i can at most check to see if a disk is in or write protected.