At Wed, 29 Nov 2006 15:24:44 -0300, Marcelo Maraboli wrote: > > I have a few questions on what a "shared filesystem" hardware > CAN be: > > - iSCSI storage ? (cheap GigaEthernet SAN) > > according to Wikipedia http://en.wikipedia.org/wiki/ISCSI , > only 1 iSCSI-client can be connected to 1 iSCSI-server (disk) > at a time...so this does not allow for a shared FS ? A shared FS is something completely different than storage that can be divvied up between multiple systems. A filesystem is just a construct of the operating system (a data structure that lends form and purpose to the data on some kind of external secondary storage), and thus for a shared filesystem the kernels of all the participants must share the same construct consistently and with integrity. I.e. if one system changes a block on the storage devices then it must be able to do so with integrity and perhaps also in such a way that the other systems will know about that change by the time they might need to reference that block. Networked block storage devices, such as Fibre Channel and iSCSI can lend themselves well to being used as components of a cluster system since they isolate points of failure related to the storage subsystem into a unit where they can be dealt with in a black-box way without the operating systems having to deal with it. (E.g. redundant network connections, mirrored controllers, mirrored storage, perhaps with the mirrors in locations remote from each other.) Of course you can also have networked storage connected to a single file server and then use a networked filesystem, just to complicate things. :-) Shared filesystems can also be implemented without shared storage though -- i.e. in much the way network filesystems are implemented. (Now why couldn't we have kept with the Multics unified view of storage?!?!?! Maybe someday we'll finally get back to it.) > - if GFS is mainly for Linux, any NAS or SAN should work ?? I'm hoping that someone might find time/money/etc. to port GFS (or something similar) to *BSD (NetBSD in particular would be best from my perspective, especially since it runs on the most platforms) -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@xxxxxxxxxxx> Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx> ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html