Red Hat announces GFS 240
PSUdaemon writes "Over at Kernel Trap they have an announcment that Red Hat has released GFS under the GPL and offer it through RHN. This could potentially be a very substantial offering from Red Hat."
The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford
Compatibility? (Score:4, Interesting)
--
11 Gmail invitations availiable [retailretreat.com]
Newbie (Score:2, Interesting)
It also helps virtualisation (Score:4, Interesting)
The second really interesting use is with virtualisation - imagine if you want all your S/390 virtual machines to share the same bsse file systems for efficiency (given the price IBM charge for mainframe disks
`GFS' (Score:4, Interesting)
Good Distributed Filesystems? (Score:3, Interesting)
I mean, NFS has issues with security (relying on numeric user id's sent by the client is a nightmare). Locking is problematic. Different versions have severe compatibility issues.
I forget the issues with AFS, but it's successor, Coda, seems not very mature, although it is one of the more promising filesystems out there. InterMezzo is a more complete and robust implementation of the Coda featureset, but is Linux-only.
SFS looks very promising (simple, but effective), but requires NFSv3 clients and servers to interact with the kernel.
None of these filesystems allows regular users to access remote filesystems (superuser privileges are required for mounting) like with FTP.
What's so hard about getting this stuff right? And can we please have kernels that support userspace filesystem drivers (or, better, any drivers)? (Yes, I know about LUFS and FUSE).
Ok, rant over. Thoughtful comments, corrections and pointers appreciated.
an idea whose time has come ... and gone (Score:4, Interesting)
What about security? (Score:4, Interesting)
First Linux distro with GFS (Score:3, Interesting)
Difference between GFS, NFS and AFS? (Score:3, Interesting)
Re:Good Distributed Filesystems? (Score:2, Interesting)
On the other hand, if GFS doesn't do something intelligent about security, then we're left with the same fundamental problem that NFS has. Namely, we need to presume that it operates within a local environment in which all users on the inside are trusted. (Insert end-to-end argument here.)
Obviously the idea of "secure network" is a myth, and when I first glanced at the headline on Slashdot, I was hoping that GFS would be a step in the right direction toward a secure filesystem that actually stands a chance of being implemented in servers like the ones produced by NetApp. I guess I am disappointed.
How will this affect IBM's GPFS (Score:2, Interesting)
I don't think so (Score:3, Interesting)
Red Hat's HA clustering software is also GPL but it doesn't run on other distros (and is not supported by Red Hat on other distros).
The code itself is open source, that is true, but "Red Hat Enterprise Linux subscription [is] required" (http://www.redhat.com/software/rha/gfs/)
Re:Good Distributed Filesystems? (Score:5, Interesting)
No, and they don't cook your dinner for you either, but if that's what you're expecting then you're completely missing the point of what a cluster filesystem is for. Granted, the name "Global File System" is a misnomer, but it has been a misnomer for several years now and if you have anything more than a dilettante's interest in this you should know what GFS really does.
Yeah, everything's easy when you're not the one doing it. Tell me what you do, and I'll tell you how wimpy that is. If you think that maintaining consistency across multiple machines in a cluster without compromising performance is easy, you're a fool. If you think that high availability of any form is easy, then you're an idiot. If you think putting those two together doesn't lead to an exponential increase in complexity and hence difficulty, you're a moron.
If you want a filesystem stub (not really a complete filesystem) that lets you access files stored half-way around the world over a standard protocol, look into one of the many efforts based on WebDAV. If you want a true global filesystem, look into OceanStore so you can appreciate some of the problems that are involved. If you want to be able to change the filesystem namespace without being root, look into Plan 9. Do your own googling. None of those are what GFS is about.
Re:How will this affect IBM's GPFS (Score:3, Interesting)
Re:GFS is cool, but (Score:2, Interesting)
Performance. Simplicity. Adopting AFS is kindof an all-or-nothing proposition - we looked into it, but it would mean retraining a _lot_ of physicists, some of whom make computer geeks look like social geniuses.
Is it primarily that it is more useful for highly parallel computing systems so that the actual nodes can share the actual block devices?
Yes, and it does it relatively elegantly. PVFS, the main alternative, is fundamentally a kludge IMHO and compared to GFS is horrendously brittle (one PVFS participant failing takes down the whole virtual filesystem) However, until such a time as GFS supports MPI-IO "ROMIO", PVFS will be the cluster FS used on our cluster
Re:Not quite, but OpenAFS would be a good option (Score:2, Interesting)
o fcntl locks are "always granted" meaning you won't know if anyone else is using any file on AFS.
o It doesn't support hard links between files in different directories because their ACLs are directory based, not volume based.
o Permissions are based on AFS acls, and the standard unix octal permissions will show in file listings, but mean nothing.
o The stable version (v. 1.2) has a 2GB file size (though volume size can be much larger) limit.
o Depending on the length of your file names, you are limited to approx. 64k or fewer files per directory.
o Currently it only supports 2.4 kernels stably, and there is some strife between the OpenAFS and Linux Kernel communities on the implementation. Specifically, they don't like that the syscall table is not exported to modules in Linux 2.6 (they say it is for all other Unix-like OSes...)
o OpenAFS isn't GPLed (it uses an IBM open source license that's GPL incompatible). So, unless there's a rewrite, it won't get into the mainstream kernel. There seems to be some progress made on a GPLed rewrite for the 2.6 kernel, but it is very experemental and only provides some functionality compared to the OpenAFS non-gpl module.
AFS as it is now is best for a distributed file sharing network where locking isn't important. With its one read/write server, and multiple read-only servers per volume it would be a great tool to maintain mirrors (read the OpenAFS docs on what exactly a volume is, and the concepts that suround them). It has great caching concepts, and only sends the parts of the files you request (unlike Coda that must send the entire file before the first byte is available to userspace).
GFS looks like it will be a great tool for the LinuxHA project for active/active pairs of nodes.
Given time, I'm sure GFS will be in all distributions that value cluster admins as users (suse, debian, etc).
Re:Not quite, but OpenAFS would be a good option (Score:3, Interesting)