Red Hat announces GFS

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

Comments

Compatibility?

[Grant29]

Will it run on distros other than Redhat? According to the linked page, it looks like it only for redhat enterprise platforms.

--
11 Gmail invitations availiable

Newbie

[Wardini]

What does GFS exactly do for you? Allow you to have your hard drive in another computer?

It also helps virtualisation

[Alan Cox]

I think the other people have covered the basics pretty well - plug lots of computers into one fibrechannel or possibly firewire disk or disk array.

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 ;)) or the same with uml, Zen, etc

`GFS'

[Anonymous Coward]

I was reading only the other day about the Google File System. So there are now two acronymns which are both GFS which both refer to a distributed file system. That's not going to get confusing. Nope, not at all.

Good Distributed Filesystems?

[RAMMS EIN]

Are there any distributed filesystems that don't have serious issues?

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.

Re:Good Distributed Filesystems?

[cantabrigian]

Many people believe that the salient problem with AFS is that it violates unix semantics. AFS has a program called "fs" that facilitates dealing with metadata like permissions, etc. For example, chmod doesn't do anything in the AFS environment; you need "fs sa" instead.

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.

Re:Good Distributed Filesystems?

[Salamander]

None of these filesystems allows regular users to access remote filesystems (superuser privileges are required for mounting) like with FTP

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.

What's so hard about getting this stuff right?

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.

an idea whose time has come ... and gone

[dekeji]

GFS has a number of useful applications. But I think the times where you could design your enterprise around the idea of a globally consistent file storage system are over: enterprises are getting more flexible, more decentralized, and people would prefer not to have to deal with IT staff over issues such as file space and permissions. And they can avoid it--since many of them make the purchasing decisions.

What about security?

[ee96090]

I don't see security in the least of features. Calling this a Global file system is a bit presumptuous, considering the lack of security prevents it from being used outside of a closed LAN segment.

First Linux distro with GFS

[rkoski]

Released today, see more at Always Current Lineox Enterprise Linux Gets Global File System (GFS) Support.

Difference between GFS, NFS and AFS?

[techmuse]

What is the difference between GFS, NFS and AFS? (Other than AFS's global file structure, kerberization and encryption)? Do they all do the same thing, or does GFS add something that the others don't have?

How will this affect IBM's GPFS

[The Mad Duke]

IBM has a product called GPFS (General Parallel File System) which has sold on AIX for several years and is offered for Linux as well. On Intel based boxes it sells for about $1000 per CPU. I wonder how IBM will react to this Open Source competition ? The IBM product has very similar function - it is also used with Oracle RAC. It originated on the RS/6000 based SP clusters but has been ported out to be used on pretty much any AIX or Linux based cluster.

Re:How will this affect IBM's GPFS

[Troy Baer]

GFS is more like IBM's SAN Filesystem (a.k.a. Storage Tank) or SGI's CXFS than GPFS, which is more analogous to parallel filesystems like Lustre or PVFS2. The difference is how the clients talk to the underlying storage devices; clients of GFS, SANFS, and CXFS talk directly to the storage devices via Fibre Channel or iSCSI, whereas clients of GPFS, Lustre, and PVFS2 go through some number of intermediate I/O servers.

--Troy

I don't think so

[Donny Smith]

I don't think so.

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:GFS is cool, but

[Anonymous Coward]

what exactly does it give you that OpenAFS does not?

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

[mikefe]

I'm also wondering about how GFS compares with OpenAFS. I've looked into OpenAFS, and if you require any type of locking, you shouldn't use OpenAFS (though, I'm not sure about "lock file" semantics with OpenAFS).

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

[tchuladdiass]

If your looking for a more falt-tolerant nfs, try combining it with the network block driver (nb) and raid-1 (md). The basic technique is to mirror a volume between a local disk slice and a remote partition, using md to do the mirroring and the nb driver to access the remote slice. If you want, you could also set up several remote slices on different boxes, and set up raid-5 among them.