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."

Comments

Not sure if this is waht you want

[Merlin42]

this might be waht you want ... The documentation wasn't immediately clear to me so I might be off the mark.

Data Integrity?

[iCEBaLM]

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

Re:Data Integrity?

[david.given]

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.

Well, d'oh, you use a file system that supports simultaneous accesses, don't you?

There are good reasons for wanting such a thing. For example: say you have a mission-critical database server. You want instant failover if anything goes wrong. Your database is being continuously modified, so merely duplicating it won't do.

One solution is to do something similar to the above. Have two database machines plugged into the same drive (in the real world, RAID drive array). The database software is intelligent enough to cope with simultaneous accesses. Now you can send a query to either server and they'll access the same data, at full hard disk speeds. Pull the plug on one server and the other just keeps rolling.

Why not use ethernet sharing? Because there's a single point of failure. Your drive is attached to a file server. Your file server is attached to your database servers. If your file server goes down, your database servers are cut off.

Solutions to this? Duplicate your file server. Broadcast your data to all file servers, all attached on some high-speed network. This'll work. Unfortunately, you've just reinvented, in a heavy and expensive way, having one disk attached to several machines at once...

You see, your file servers are duplicating all the functionality of a RAID array but with a lot more overhead. Your high-speed network is duplicating all the functionality of your Firewire or SCSI bus, again with more overhead. Your databases now have to send their file accesses over that network, which will be slow. There's overhead everywhere.

By simply using a drive (or drive array) attached to several servers, you get the same functionality, much cheaper, and with a much simpler setup. Remember, complex == unreliable. You can buy certified, five nines RAID arrays off the warehouse shelf and they will Just Work. You can buy high-speed SCSI cards with multi-initiator support (this is the magic phrase to Google for) and they will Just Work.

Of course, it's not simple. You need a piece of software known as a distributed lock manager to handle the atomicity issues. But you can buy them, and they will Just Work.

This kind of setup has been around for years in the big iron SCSI world. I haven't come across anything yet for Firewire, though. Personally, I'd be a bit dubious as to whether you're going to anything fast enough or stable enough for Firewire; high-performance SCSI beats Firewire into the ground, and all the kit is available off-the-shelf. But I'd be interested to see if anything comes up.

Re:Data Integrity?

[MrRobahtsu]

You've never heard of [Open]GFS, or any clustered file system (Oracle, Veritas, etc.) have you? Trust me, that doesn't mean they don't exist.

EXACTLY what he wants

[Jeremiah Cornelius]

This is EXACTLY what he wants. I am building a VERY inexpensive solution with four 200GB ATA drives, on a shared IEEE 1394 loop between ywo Dell 2450's.

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!

Re:EXACTLY what he wants

[Kz]

To avoid breaking the FireWire chain (not a loop!), just don't make a chain.

Use FireWire hubs to create a more tree- or star- like topology, that way each disk is in it's own branch and unplugging it won't affect the others.

also see

[rakerman]

The short answer is, to do this you need both machines to agree on the file locking and such, so they don't trash one another's files. This is not something you get built-in to FireWire, nor into most operating systems.

Also see Ask Slashdot: IEEE1394-based Storage Area Network?

Re:It's not easy

[Kz]

It's easy to do in a not-so-nice way.

Just connect everthing together, but mount it on only one machine at a time. be sure to unmount it before mounting it on the other.

on a logical level, it's exactly the same as unplugging it from one machine and plugging it on the other.

you could also mount it r/o on more than one machine, but remember to unmount it from everyone before remounting r/w on anyone.

Of course, the real thing would be to use one of the few cluster filesystems out there, GFS, MFS, or the Oracle thing. Those supposedly solve the problem of keeping the directory structures in consistent and in sync.