Slashdot Log In
SGI Layoffs Hit XFS For Linux Project
Posted by
Hemos
on Sat May 26, 2001 02:37 AM
from the bad-news dept.
from the bad-news dept.
Andrew Klaassen writes "Layoffs at SGI yesterday hit, among other things, the XFS for Linux project. Project lead Steve Lord writes, "We do intend to keep working on XFS linux, and I do intend to work really hard to get it into the distributions and Alan and Linus's kernels, [but] it will take us a little while to regroup our efforts and to work out our priorities on the project...." He also mentions that LinuxCare will no longer be helping out with funding for the port."
This discussion has been archived.
No new comments can be posted.
SGI Layoffs Hit XFS For Linux Project
|
Log In/Create an Account
| Top
| 57 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:well I'll try my best (Score:3)
Hel-loooooo! SGI laid off one of their fulltime developers, it didn't pull the plug on the whole thing... but what am I thinking, this is /., the piece basically says "XFS is dead, it won't be developed anymore", no matter what's actually written.
You have to wonder what the editors are smoking here. Yes, Russell Cattelan is no longer being paid by SGI to work on XFS. Yes, SGI is having financial trouble, but that's hardly news. Yes, SGI is no longer paying LinuxCare to work on this either. Yes, the guys that SGI is still paying to work on XFS will have a harder time, this is not the kind of project where someone comes and says "hmm... this is wrong, let's fix it here and there". Does this mean that XFS is dead? No. Precisely because SGI is having financial trouble is why they are doing this. Big Iron is not sexy anymore, at least not for the reasons it used to be. And SGI is a Big Iron company. Six Origin 3000 systems represent 40% of their volume sales in the last quarter. See the problem here? SGI needs a fast source of money. And small systems is such a source. Since SGI is not going to compete with Gateway and the like, they need to focus on another market. According to the current SGI vision that market is comprised of Itanium based boxes running Linux. But that alone isn't enough (VA, Penguin and whoever else do the same). They have to have an edge. That edge is XFS. Not the XFS you can check out of CVS, but the Cluster version. The version that exists on their MIPS based boxes now. See the big picture already? SGI needs XFS, so stop crying wolf.
On a side note, it's interesting that other sites picked up on this post here. (That thought is terrifying, since it means other sites give /. credit as a "news" source). I wonder how this will impact SGI's share prices. I mean, the very well researched piece says "SGI ... layoffs ... Linux" (who the fsck cares what XFS is?), and it's being repeated like that elsewhere. Boy, I don't want to be in Steve Lord's shoes now... but that leads to another thought: will Steve think it twice before posting anything else like this to the mailing list? I mean, he's been quoted here two times already. Will he think "no, I better not send this, it might end up in /." That can't be good. Just as hollywood stars think it twice before saying something lest it show up in the Enquirer...
Re:saving private ryan (Score:4)
Figure a coder makes US$40,000 a year minimum. That's a LOT of Paypal donations - I've never heard of anything like this happening. This doesn't include the other expenses folks have that are usually supplied by an employer like machines, bandwidth, conferences with hotel & travel, books, etc.
Hosting a popular site costs thousands of dollars a month in bandwidth alone. Great you'll offer up your server - howzabout when it's a few meg for the installable and a few thousand folks dl it, gonna keep offering it up? Whattabout when the script-kiddy vermin start trying to take you down?
Finally what's this about lost code? It's all Open Source - none of the projects you've listed have lost any code. What they've lost is momentum and what was in folks heads, the reasons why decisions were made and the intimate knowledge of the code being worked on day in & out.
XFS for Linux is not going away (Score:5)
I'll preface this by saying that I cannot actually speak for SGI, but I can tell you my impressions as an employee and an XFS for Linux developer.
I sat in on a teleconference yesterday, and from everything I know, XFS for Linux is not going away. Yes, there were staff reductions, but SGI is still funding XFS for Linux, it is still very much an alive project. I hope so, I was hired to work on it, and I'm moving across the country for this job in 1 week.
Since linux-xfs seems to be slashdotted, here's the post from Steve Lord:
Here's a followup post from our marketing person, Yi Li:
So, to the person who offered to take over the project, thanks, but that's really not what we need right now.
RH/VA should begin looking at supporting XFS (Score:5)
Whether you agree with it or not, RedHat and VALinux alike have spurned adopting ReiserFS despite its inclusion in the stock Linux kernel as of 2.4.1. Both vendors have courted the more "evolutionary" Ext3 kernel for 2.2 releases, but Ext3 is not the future of JFS' on Linux. As such, I offer this article in a plea for RedHat and/or VA Linux to begin consideration and formal testing of XFS as a viable JFS for their future, kernel 2.4-based product releases.
I have been integrating and maintaining production NFS/SMB UNIX servers and networks for years. As such, I ask that some of the "ReiserFS absolutists" (i.e. believe only ReiserFS should exist as every other JFS for Linux is "not as good" in their opinions) out there, who don't use Linux's kNFSd services in a heavy production environment (especially with non-Linux NFS clients) like myself, please not blindly comment on this post. Remember, every OSS project "itches a scratch," and there is a reason why Tweedie's Ext3 and SGI's XFS exist in addition to Namesys' ReiserFS (disclaimer: I know little about IBM's JFS).
Because I have UNIX NFS clients, ReiserFS was quickly identified as a "non-viable solution" for my needs (not that it is not applicable in many other areas, no sir, so don't flame me!) when I first looked at JFS' in early 2000. Although ReiserFS is very innovative in design, which includes a recent DARPA grant to extend these capabilities, its lack of a traditionally keeping meta-data in the inode itself results in a host of traditional UNIX service and VFS incompatibilites. So I ended up testing the early, full data journaling (aka Ext3 "v1 mode") Ext3 releases (e.g., 0.0.2f) for 3 months on non-critical systems with great success. I eventually adopted it on my main fileservers in summer of 2000 and it has worked flawlessly since. I even had a physical disk error, which my RAID controller did not catch for 24 seconds (long story, the firmware and driver versiuons was out of sync, my fault) and I was able to drop down to the full Ext2 fsck to fix things.
For people like me, Ext3 is a nice, "evolutionary" approach to journaling that significantly reduces the variables involved -- important to some of us that don't embrace "change" so quickly (for obvious reasons ;-). Ext3 is also a quick upgrade for existing Ext2 filesystems (get Ext3 kernel, e2fsprogs aware version, create the journal file, and mount as Ext3) plus complete reversable back to Ext2 (just delete the journal file and reset some superblock variables), which meant I could "switch back at a moments notice." I find the VA Linux kernels with Ext3 added (along with NFS v3, unified IDE and other 2.4 backports to 2.2) most excellent, and longtime Linux kernel NFS guru H.J. Lu (now formerly of VA) takes the time to make the appropriate RedHat RPM kernels for us RedHat users (shortly after HJL's departure from VA, I began hosting his kernels [smithconcepts.com]). VA Linux uses Ext3 in their enterprise NAS device products (actually based on not a RedHat kernel, but SuSE!), although RedHat's adoption of Ext3 has been limited to a public beta, and installer/BOOT kernels that are simply "Ext3 aware."
Today, Ext3 is still a kernel 2.2-only solution. And it still "inherits" all the "limitations" of Ext2 -- so it is not ideal where features are more important that minimizing variables. Now it's not that I've adopted kernel 2.4 on my most critical services, as it is still maturing IMHO (not bashing 2.4 at all, but as more systems run it, more "issues" are identified that were not before), but it would still be nice to have on some of my more "bleeding edge" workstations. I would be satified if Tweedie would only port the full data journaling (v1 mode) capability to 2.4, although I heard he purposes held off on the kernel 2.4 port and Ext3 1.0's release until 2.4 itself "stabilized" in his view (of which, I've heard many good reasons for doing so). If anyone has any insight to all this, I'm all ears (as I can only "assume" things here from what I've heard).
As such, that left me with re-evaluating ReiserFS for 2.4 systems, now in the stock 2.4.1 kernel, or possibly SGI's XFS or IBM's JFS. I looked at ReiserFS only to discover that the stock kernel does not include the kNFSd workaround patches. Furthermore, many ReiserFS users were still plauged with NFS and even quote issues, even after patching. This tends to make me believe that it will still be awhile before specific Linux subsystems "better accomodate" ReiserFS completely for certain users (like myself), although it is a viable solution for most standalone workstations or Windows-centric file servers. Even I am using ReiserFS on a kernel 2.4 Netfilter firewall and Squid Proxy cache/filter, where it excels (but does no direct network file serving duties).
This led me to SGI's XFS. Mid February saw the release of kernel 2.4.2 and, by the weekend of the 24th, SGI had already adopted 2.4.2 as the base of their XFS development CVS repository. I was impressed with this attention to keeping XFS' development as close to the stock kernel as possible. I decided to check out the kernel, compile and test it on a few older and newer systems, and ended up writing an RPM spec file and releasing some RPMs for RedHat 7.0 at the time [smithconcepts.com] (since it has been a couple months, using 2.4.0pre kernels, since SGI had done so). Thus I began my standard "three month evaluation" of XFS in early 2001, like I did with ReiserFS and Ext3 in early 2000.
It did not take me long before I was impressed with SGI's XFS implementation. Most specifically:
Shortly after my RPM releases for RedHat 7.0, SGI began a series of test releases for the RedHat 7.1 beta (first Fisher, 7.0.90, and then Wolverine, 7.0.91) in March and April, and eventually RedHat 7.1 itself. Like the 2.4.0pre kernel releases before them, RedHat releases XFS in a three fold scheme:
As of May 1st, XFS Release 1.0 was released. In following their three fold release venue, it includes a ~300MB additional ISO CD for installing with RedHat 7.1. But instead of patching XFS against just the stock Linux kernel, SGI took the time to take the RedHat 7.1 2.4.2-2 RPM kernel release and patch it against that (they actually did this with 1.0-Test3 as well) -- inheriting and benefiting all the patches and other kernel decisions that RedHat makes. This is very important to system administrators like myself which only trust RedHat releases and kernels for heavy file server duties (please, no flames on this -- I'll list reasons off-list, and I *DO* recommend Mandrake and, increasingly, Debian for many other purposes).
As such, I am surprised that RedHat and, especially, VA Linux have not taken a closer look at evaluating and, gulp, even supporting XFS's development on kernel 2.4. XFS is the natural upgrade for these two firms, being that both have spurned supporting ReiserFS for its non-traditional and troublesome design with traditional UNIX services and capabilities like XFS. In addition to design attitude, features and other considerations SGI has made in porting XFS to Linux as I made above, I would like also point out the following, additional considerations:
As much of a XFS advocate as I am, I am also quick to honestly and complete disclose each and every "disadvantage" or "issue" with XFS. Note that they are few and usually non-issues in most situations, although XFS is no more of an "universal JFS for applications" than ReiserFS is (and I would and should be considered a "XFS Absolutist" if I didn't). Specifically, I find the following disadvantages to and issues with XFS:
SGI's XFS is a powerful, stable and feature-packed JFS that is mission-critically proven on Irix and now available for Linux. It brings a wealth of features and traditional UNIX fs compatibility to Linux, while only sporting a few, less than optimal attributes in some limited areas. Being that SGI has gone to great lengths to synchronize its codebase with the common codebase of the projects it integrates with, and some of these projects (notably Quota and Samba) have adopted native support for it, many XFS users are starting to question why XFS has not become an option in our favorite distributions.
As such, I urge RedHat and VALinux, two companies who currently favor Ext3 and spurn ReiserFS for specific issues that XFS does not have, to consider beta testing and offering XFS as an option for their distributions and systems. As the 2.4 kernel matures and gains widespread acceptance, those of use who cannot adopt ReiserFS will need a solid replacement for Ext3 coming from kernel 2.2. And the additional enterprise-driven features of XFS make its consideration that more inviting.
I thank you for your open consideration of this article.
-- Bryan "TheBS" Smith
This is truly unfortunate (Score:3)
I am just waiting for XFS to make it into the kernel proper (and kdb, as well. As a developer I'm drooling over getting that in place), and for the major distros to support installing to an LVM group from the start. Now that the SGI team is in scramble mode that means I'll probably have to wait longer. Damn.
In the future, I see the average home having a data server in the basement, right next to the hot water server, the hot/cold air server, and the electricity server (breaker panel). I see this server as a faceless box, much like a breaker panel, with slots that take hot-plug disk drives. Need more storage for video on demand/music/cache (no, I'm not going to use the p-word here. Grow up.), just plug a new drive in. The system sees the drive, formats it, adds it to the arrays, and away you go. Linux is getting to where it could do that. XFS/LVM/RAID are damn important....
So, layoffs affect OSS projects just like non-OSS (Score:3)
--CTH
--
well I'll try my best (Score:3)