GFS released under the GPL
Posted Jun 25, 2004 16:54 UTC (Fri)
by stevenj (guest, #421)
[Link] (3 responses)
In the future, it would be nice if the editors would summarize the relevant "who, what, why" information in their article; this isn't Slashdot, after all.
Posted Jun 26, 2004 4:07 UTC (Sat)
by djabsolut (guest, #12799)
[Link] (2 responses)
Posted Jun 26, 2004 5:03 UTC (Sat)
by AnswerGuy (guest, #1256)
[Link] (1 responses)
Of course one could then export this local/SAN fs over NFS to additional
Posted Jun 28, 2004 5:37 UTC (Mon)
by daniel (guest, #3181)
[Link]
Posted Jun 25, 2004 17:07 UTC (Fri)
by smoogen (subscriber, #97)
[Link]
Posted Jun 25, 2004 20:05 UTC (Fri)
by treed (guest, #11432)
[Link] (3 responses)
Posted Jun 28, 2004 5:50 UTC (Mon)
by daniel (guest, #3181)
[Link] (2 responses)
Posted Jun 28, 2004 9:14 UTC (Mon)
by mdekkers (guest, #85)
[Link] (1 responses)
Posted Jun 28, 2004 15:17 UTC (Mon)
by vmole (guest, #111)
[Link]
No, he's suggesting that while it was proprietary, Sistina was able to devote more resources to developing it, because there was a direct cash stream associated with it.
Yes, there is a lot of good, reliable, free software. Some of it took a long time to get that way, because the developers simply could not devote the necessary timei to the project. Also, often the "final polish" part of a project, where you catch all the corner cases, is tedious and non-glamerous. It's lot more fun to start a new project, and since you're doing it for fun anyway, there's no incentive to get the last 1% right.
It's all well and good to be in favor of free software. I believe that in the end, you do have a better result, but it can take a while to get there, and ignoring that fact while rah-rah-rahing free software does no one any good.
Posted Jun 26, 2004 1:54 UTC (Sat)
by johnjones (guest, #5462)
[Link]
a clusterFS now if I could only get a MacOS and WinXP driver the world would be a better place go on apple speak to redhat about it CUPS worked well in MacOS after all ! regards John Jones
Posted Jun 26, 2004 21:16 UTC (Sat)
by stevef (guest, #7712)
[Link] (1 responses)
I suspect that the most widely used on Linux are: But with the increase in ethernet speeds, the two popular network filesystems (perhaps with minor extensions) NFSv4 or CIFS, should be able to compete with SAN like approaches in some cluster environments as well. A major problem with the cluster filesystems is that although some have open source implementations, they don't have standards documents written up for their metadata operations that sit above the block layer (iSCSI itself is pretty well documented but is lower layer). For the two most popular network filesystems they have deteailed protocol descriptions written up: obviously NFS in the IETF, and CIFS from SNIA. The VFS improved a lot in 2.6 over 2.4 for network and cluster filesystems, with a few more changes to the VFS in 2.7 we may be able to achieve essentially local file i/o semantics over non-local filesystems which we can not quite do today.
Posted Jun 28, 2004 5:55 UTC (Mon)
by daniel (guest, #3181)
[Link]
From the GFS project page:
What GFS is:
GFS (Global File System) is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, iSCSI, NBD, etc...). GFS reads and writes to the block device like a local filesystem, but also uses a lock module to allow the computers coordinate their I/O so filesystem consistency is maintained. One of the nifty features of GFS is perfect consistency — changes made to the filesystem on one machine show up immediately on all other machines in the cluster.
obviously GFS differs from NFS, but what are the differences ?What GFS is:
GFS is more of a SAN filesystem. The idea is that it can support concurrent access by multiple systems over a SCSI (multi-initiator), fibre channel or potentially even a firewire bus/fabric.What GFS is:
clients. However, it's more interesting for custered applications that
need more tightly coupled access to their storage (where network and IP layers impose too much overhead --- latency in particular).
GFS is more of a SAN filesystem. The idea is that it can support concurrent
access by multiple systems over a SCSI (multi-initiator), fibre channel or
potentially even a firewire bus/fabric.
What GFS is:
Nice succinct answer. Additionally, GFS is also used with block devices exported
over a network. For my own development, I don't have a shared disk at all,
instead I export a SCSI drive using
Hyperscsi. iSCSI will work as well. The grand GPL release also includes GNBD,
a network block device exporter suitable for use with GFS.
Of course one could then export this local/SAN fs over NFS to additional
clients.
That is one of several main applications of GFS out there in the field: basically,
server amplification. You have a core of GFS nodes, each of which exports as
many NFS clients as it can handle, and you can have a bigger NFS network for
less money (because the cost of the cluster scales linearly, whereas the cost of a
multicpu server of equivalent power scales quadradically).
You can also do html server amplification, particularly for sites generating dynamic
content. A filesystem shared _efficiently_ between all the servers in an html farm
is a big help both from the point of view of performance and maintainance.
However, it's more interesting for custered applications that
need more tightly coupled access to their storage (where network and IP layers
impose too much overhead --- latency in particular).
It's only interesting to applications that need tight coupling to their
storage. Fortunately, that is most applications :-)
Network latency isn't much these days, particularly when you use something like
HyperSCSI that sits right on the ethernet protocol, so doesn't incur the IP
overhead. No TCP -> less latency. This is perfectly practical and useful.
Besides, GFS does a very good job of caching in-kernel, much as a local
filesystem does, which tends to amortize the cost of network data transfers. And
besides again, GigE gives Fiber Channel a pretty good run for its money.
From dealing with such things in the past, the delay in making the code GPL'd is usually due to the research that is done to make sure that all the code can be GPL'd. EG it didnt come from BSD/X11 code bases or that if it came from the outside that the other authors will give permission that it can be GPL'd. They also are probably needing to do 'background' checks on the code to make sure that a developer didnt take a short-cut and put in code they shouldnt have.
GFS released under the GPL
GFS *used* to be GPL. Then Sistina (mistakenly IMHO) went proprietary with it. Since it was GPL before and all of the code came from Sistina it should have been easy to GPL it again. Unfortunately now we have OpenGFS and regular GFS to deal with. Hopefully they will merge again.
GFS released under the GPL
GFS *used* to be GPL. Then Sistina (mistakenly IMHO) went proprietary with
it.
GFS released under the GPL
Indeed, _your_ opinion. I'm not so sure. GFS's tour of duty as a proprietary
filesystem has helped it gain the fit and finish needed to work productively under
commercial workloads. We're just very lucky that events fell out so that all that
work came back to the community.
Unfortunately now we have OpenGFS and regular GFS to deal with. Hopefully
they will merge again.
Speaking as an honorary member of the Open GFS team, we have already as
much as merged. As we speak, Brian Jackson, our fearless leader, has prepared
a GFS package for Gentoo, ready to be emerged. (I think somebody else even
beat him to that, but you get the idea.) There will be more announcements on
this and other interesting topics in the next few days, please stay tuned.
So, let's let the hacking begin. And oh, by the way, clusters are loads of fun.
GFS's tour of duty as a proprietary filesystem has helped it gain the fit and finish needed to work productively under commercial workloads. GFS released under the GPL
At the risk of sounding pedantic, are you suggesting that GPL / Open Source software does not usually have the "fit and finish to work productively under commercial workloads"? The manner in wich you pose the comment suggests that GFS would otherwise not be in such good shape.....
GFS released under the GPL
at last !at LAST
(the windows driver could cage off the openAFS stuff maybe maybe)
A detailed comparison of the Linux cluster filesystems on their technical merits would make a great technical paper (or Masters thesis). We are long overdue for a comparison of them on:GFS released under the GPL
a) their network protocol, and how well the operations map to the Linux VFS
b) their Linux 2.6 implementation
1) SANFS (Storage Tank)
2) GPFS
3) GFS
4) Lustre
The VFS improved a lot in 2.6 over 2.4 for network and cluster filesystems,
with a few more changes to the VFS in 2.7 we may be able to achieve essentially
local file i/o semantics over non-local filesystems which we can not quite do
today.
GFS released under the GPL
Au contraire, GFS has already achieved that. The last of the GFS VFS patches
(beyond a trivial export or two) is in play on lkml now, the cluster flock patch,
which GFS doesn't need except to support local filesystem semantics for flock
and fcntl locks.