Slashdot Mirror
SGI open-sourcing XFS
Yun Ye writes "Finally, a journaling FS for Linux! Get the full story
. Excellent-we'll have to ask the SGI people about it tomorrow. And who came up with the name change. Whatever the case, this will help Linux continue to crack the high-end market.
One nitpick... with standard Linux devices you can access 2G /blocks/, which comes out to 1TB.
From the white paper:
7.1.2 Future Directions
The ever evolving future of XFS shall include items such as:
Access Control Lists
Disk Quotas
It looks like the white paper might not be completely up-to-date. Have Quotas and ACLs been implemented yet?
--
Business. Numbers. Money. People. Computer World.
Here's a quick definition of ' journaling'.
> Well, my nominations for the other two would be:
6. Lack of drivers for the latest hardware.
7. Poor gaming environment.
(6) may not be a weakness, because we don't need Winmodems, Winprinters, Winsoundcards, etc. And, unless someone ported Linux for PSX2 or all hardware companies finally got a clue, (7) will remain to be a problem.
Meybe it was GOD who put in the exeption but it is there anyway. Who got copyright for linux, linus right? - so He must have been the one who did it, but I guess GOD could have done it to, if he cared ;)
Well, Now you know one sysadmin who has made serious use of NT's ACLs. They actually do come in handy if you know how to effectively use them.
The u/g/o permissions are sufficient in most instances, but being able to set up 1 person as the "owner", a group with "rwx" perms, everyone with "rx" permissions, and excluding one group from even looking in that directory....in a corporate LAN, that type of thing comes in handy.
-- If you can't laugh at yourself, someone else will do it for you.
Well, they are:
At least there will be a "hacker" reason to wait for the summer :) If they won't hurry however, we will be getting the next ext2fs with journaling and B-tree code (faster directory/file data access) by then from Ted T'tso and Stephen Tweedie, and XFS will be useful only for IRIX compatibility :)
Licensing is still an issue, GPL would be nice IMHO for them, because of the protection they would be getting to not commercialize it without them getting the improvements back, and also perfect for kernel code. If it's not GPL, it can't be used by directly linking into the kernel (minor issue, but still inconvenient.) Let's hope for the best.
It's also not the "full" XFS, according to the report, it's got only the features the kernel hackers are planning to build into ext2.. really weird.
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
Solaris has had /proc for a long time. Since Solaris 2.1.
Actually, Solaris has all the things you mentioned.
Linux is still technically inferior to commercial unices. Just like windows NT. Truth hurts.
>5. No high availability clustering (Beowolf is cool but completely unrelated to this)
HA clustering, load balancing, hot swapping of nodes, etc. using Linux boxen is something I've been looking into recently. I'm currently having wet dreams about hierarchical, infinitely-scalable Linux clusters, using SAN technology...
Dodger
aka Mad Systems Engineer-type person.
If you read the white paper on XFS, you'll find that it includes a volume manager which looks comparable to AIX's forex.
Instead, you buy a box from someone like Baydel or Sun Storage Solutions. This box has a bunch of disk drives in it and a couple of controller boards that have SCSI controllers to talk to the disks, RAID hardware, and a SCSI controller to talk to the host. This disk box deals with all of the RAID stuff (striping, parity, rebuilding failed disks on hot spares, etc.). The host sees the entire array as one or more disks.
For the host, you just buy a couple of regular SCSI controllers and plug each one of these into one of the controllers on the disk array box. Then you just have to set it up to fail over to the second controller if the first one fails in some way (be it the host controller, the cable, or the controller in the disk array box).
cjs
The world's most portable OS: http://www.netbsd.org.
This is great news! Does anyone have a guess now as to how long it would be until such a journaling FS would be reasonably working in Linux?
*NOT* releasing software intended for Linux as GPLd shows oh-how-commited those big companies are to Linux. I believe mere "Open Source" is commitment. I could talk a lot more about that but I'll be busy this afternoon waiting for Santa Claus.
this will be interesting. if it is to be linked into the kernel as source - not as a binary - surely it will have to be GPLed... i guess that would prevent it being ported elsewhere (bsd and friends). if this is the case, then SGI will actually manage to ** effectively limit ** the release to linux. nobody else would dare to touch it for fear of license pollution.
i could be wrong of course... i wonder how rms will react.
Sorry but there is GPL in *BSD kernel, actually the same FPU emulation than Linux can be used in OpenBSD's kernel (I'm not 100% sure but I think that it's an available option for FreeBSD too).
The only restriction is that the system must be able to run without GPLed code. In the previous example a BSD licenced emulator is an option (and it sucks compared to the GPLed one), and most people don't use a FPU emulator at all since they have a FPU.
Please don't spread FUD. Even a GPLed XFS will be usable in the BSDs.
Linus does not have the power to add such an exception.
How about support for ACLs? That the other major weakness in the current Linux file system... the UNIX file permission system is extremely limited compared to NTFS or the Netware file system in this way.
The SGI Myths paper mentioned looks like it hasn't been touched in 2.5 years, which makes it embarassingly outdated in places. For example, quoting Byte (Jan '97) labelling the O2 as a "Wintel killer." Well, in 1999, the writing on the wall is that Wintel, in the form of SGI's own VisualPC boxes, is going to kill the O2.
Also, the 6.4 GB/sec figure quoted is Origin memory bandwidth, and has nothing to do with XFS or disk I/O rates. You can get really good throughput out of an Onyx/Origin, like in the hundreds of megabytes per second (I've witnessed that), if you've got lots and lots of striped disks, but gigabytes per second disk bandwidth isn't realistic.
I'm suprised. I turned off the active desktop. I was tempted to boot it out and try installing KDE instead, but my experience of compiling OSS on IRIX hasn't been that great, and it probably takes root access anyway.
I'll probably switch to a Linux PC soon anyway. The Pentium II's are much faster for single precision adds and multiplies, although divide and sqrt suck rocks, and don't even think about doing a trig function.
This is internet gift economy at its best. I really hope that no-one will forget SGI for this generous move!
n ge/ti_xfs.html
;-)
Short overview of XFS at http://www.sgi.com/products/remanufactured/challe
All we need to get Linux into the data centers is a decent clustering/failover package...
Compaq, are you listening? How about GPL'ing your old failover/clustering package (ASE)? It would be a proper gift to match SGI...
(not that I don't appreciate or notice the release of the Compaq 64-bit math libraries... i really do... but SGI just raised the bar
/ Henning
Well, my nominations for the other two would be:
/proc filesystem, that Sun have only just introduced in Solaris 7.
1. No large files support (files over 2Gb). This is required for any work with medium-large databases or digital video editing.
2. Poor support for RAID - hot spares, hot swap, etc.
3. Poor NFS performance (speed and locking)
4. Poor desktop environment
5. No high availability clustering (Beowolf is cool but completely unrelated to this)
All these except (4) are possibly (5) more or less requirements for use in medium to large enterprise situations.
But while these are significant, lets not forget the cool things linux has like the
It's not fully finished (have not tried it yet, but will be soon), but we now have NFS Version 3 support for linux.
http://www.CSUA.Berkeley.EDU/~gam3/knfsd/
>If you add automatic failure-detection to MOSIX, you have HA+speed. You'd only need to make sure state was mirrored across the cluster.
Yeah, all you need to add high availability is make sure state is mirrored across the cluster and add failure detection. All you need to write a kernel is run a few lines of code through a compiler. All you need to build a car is weld a few bits of metal together.
Slashdot - News for Herds. Stuff that Splatters.
While it would rock on NT, Microsoft wants an inordinate amount of money for their IFS development kit (I can't remembert if it is one or five grand). I'd be quite impressed if someone actually took the time to port XFS to NT, given the cost associated with the development tools.
Then again, IIRC, I have seen some sort of GPL'd IFS development kit. Anyone have any details on this?
Rather depends on the License. I don't believe the BSD folks allow GPL software into their kernel.
when I read that NTFS could journal and ext2 could not, it made me feel really crummy...
This is excellent news!!!
I just hope XFS can match NTFS blow for blow...
anyone know of a good comparison?
So ACLs, properly implemented, are a really nice feature. They're certainly not properly implemented in NT, but if you look at Unix with a filesystem like AFS, they can make life a lot easier. If I'm working on a project for a class, I can set up a new group, stick all the people on that project into the group, and we can have shared files all of us can access. It's really something that's a must for an environment with thousands of users (such as my school network).
All the BSDs ship with plenty of GPLed code, as well as all Linux distibutions ship with plenty of BSD code, get real.
The various BSD generally only require that the GPLed code not to be necessary to have a running system, eg the kernel scheduler couldn't be GPLed.
Here is a good article that explains it simply in the cotext of NTFS's failings.
g i?vc=docid_9-129837.html
http://www.idg.net/idg_frames/english/content.c
Although the GPL implies that #include of GPL'd headers makes the using source code GPL, that is a completely unenforceable idea. Standard headers like stdio.h, strings.h, etc. are under [L]GPL, but they map to ANSI and POSIX standard headers.
If the GPL had any teeth in this area, that would mean POSIX code which was originally developed on another platform would have to be GPL'd if it was cross-compiled under Linux et. al. Clearly cross-compiling software is *not* the same thing as actually using fragments of GPL'd code (cut-copy-paste), so such a claim would be tossed out of court eventually.
Having kept an eye on the M$ AntiTrust trial it's kind of clear that the legal system and rationality have little to do with each other -- otherwise M$ would have lost that case a long time ago. Should such GPL claims ever go to court, the results are likely to depend on who has the biggest lawyer/legal budget, not on rationality.
I stand corrected. However, Solaris 6 had 64 bit file support, and that runs on non-Ultra hardware. There are limitations involved in architecture, but Sun managed to work round them...
--
Uh, didn't Sun make source code available for Java, Jini, and Sparc?
Many of you complain that Sun does not resell Linux. Sun does not resell Intel chips. Sun does sell Intel UNIX. The comparisons are not valid. SGI does not sell Linux on MIPS, in fact, that program has floundered. HP does not have an IA-32 version of HP-UX. Compaq has not ported Digital UNIX to Intel. I know Alpha cloners sell Linux, just like Sparc cloners sell UltraPenguin (at the encouragement of Sun). Does Compaq sell Linux on Alpha? If they do, that is great.
Now everyone attacks Sun, the lone holdout, just because they are successful. I guess it's OK to sell out as long as you lose money.
HP is especially vile, after complaining and threatening regarding Java licensing. Sun's Java license addressed every issue HP bitched to the trade rags about, and what does HP do? Renew their efforts to fragment Java, and avoid Jini in favor of MS-UPP, which they know will never work with HP-UX/PA-RISC. All because they would rather see Sun fail, than HP succeed. And who wins then? Microsoft, and only Microsoft.
Beware of throwing stones. If you look back six months ago everyone was ragging on SGI for selling out to Wintel.
4dwm would be nice, but I'm still waiting for fsn to go open source!
Give a man a match, you keep him warm for an evening.
Light him on fire, he's warm for the rest of his life
If they open source it, not matter what license, Sun can still use it. I just hope it is allowed to be integrated into *BSD.
>Let's just say smart management doesn't give away one of company's few technological advantages for some vague future benefit.
It seems to me that giving something to Linux is not necessarily giving away a technical advantage.
Seriously, SGI is not fundamentally in the operating system kernel business, it's what they build on top of that. If the IRIX kernel was replaced by a Linux kernel (I have no idea how practical that is or how the feature sets compare), then SGI could dispense with a large part of their R&D expenses (maintaining the IRIX kernel) without giving away anything that they really sell to customers. Even if they don't make such a move, XFS for Linux makes dual boot situations nicer, and compatibility with Linux is a feature.
I had hoped that BeOS would do this with the BFS.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
The article says that the lack of a journaling filesystem is one of linux's three major weaknesses. What are the other two?
Yeah. As I understand, the way many journaling systems work it, the filesystem itself is a database. Just as a database uses a journal to record transactions in preparation for committing or rollbacks, so does the journaling filesystem. The journal holds the transactions (block writes) until they are written, then the journal entries for them are cleared. If there is corruption in the filesystem, the journal can be used to bring the filesystem back to sanity.
:)
I've never lost an ext2 filesystem; it does, however, take some time to fsck... a journaling capability would be nice to have.
Codifex Maximus ~ In search of... a shorter sig.
Great! Another clueless comment from a failing wannabe pundit!
I don't know about support for ACLs, but I've never heard that discussed as a weakness. To the contrary, all I've heard is much complaining about how hard it is to manage ACLs and how the user and group model tends to be more practical. (In fact, I've never met an NT sysadmin who's made serious use of NT's ACLs.)
Is this a byproduct of poor implementations, or am I missing something?
After many years of walking in circles, SGI
has finally found the new focus needed to grow
beyond graphics. And they are showing great strategic savvy: it's much better to periodically release bits of very free source, instead of going `Open Source' in a big gulp. You get much more exposure that way.
It's not risk-free, of course. For many people `just' 64-bit and journaling will be more than they need.
I hope the license will only allow THEM to use this source to add XFS to Windows NT.
Irix v6.2+ has quotas for XFS and Irix ver 6.5 has both ACL's & quotas.
If they GPL it they'll have to GPL all derivative work, including all the work they did improving it for Irix. That's exactly for this reason that Netscape didn't used GPL, they had other products using the same code and didn't want to opensource them.
It's slightly worriesome that SGI haven't decided on a licence, even though the piece says it'll certainly be Open Source.
If we need a journalled FS (I guess we do), then we need a GPLd journalled FS.
How's this going to be implemented? If it's a kernel patch, then correct me if I'm wrong, but doesn't it *have* to be GPL?
I guess if it's only a module, it can be any licence, right?
--
Linus doesn't have to approve *anything* -- unless it's going to be part of the kernel, and even then the GPL allows anyone to start distributing a forked version of the kernel, without consulting Linus, as long as that too is released under the GPL.
See the top level post I am about to make, discussing this and the GPL.
--
But I have never been in a situation where they have been needed. They are just extra bagage which probably got added just because someone thought they should have it so they could have an extra checkmark in some box in a comparison table.
Please don't add junk that noone uses to Linux
So I notice the article sez some parts will be
held back. I wonder what that means with SGI
just having come out with that clustered file
system (hot stuff!) cxfs. I guess they wouldn't
let go of the grio (guaranteed rate io) or real
time stuff either, huh?
Wonder if they'll add XLV...
I hear they have some cool demos at Linuxexpo.
ANyone know someone at the show?
For real high-end stuff:
1. Poor large memory support. I'm not sure how the most recent kernels fare, but last I checked Linux only supports a maximum of 2GB of ram. This is probably one of the FIRST things which need to be fixed. I have heard that SGI is working on a patch to give 3.8GB on Intel machines... that sounds promising!
2. No raw I/O support. This is used for large RDBMS's for example. AFAIK Linus hates the idea, so it will probably never get this. Mind you this is minor because there are ways around it.
3. "fsync()" on large files is extremely inefficient. Again, this affects RDBMS to the extreme. It is so bad that in some cases Windows NT is 30 or 40 times faster than Linux on equivalent hardware doing database inserts and updates. To witness this for yourself, write a quick program that opens a file and loops appending a line and doing an fsynch on it. Notice the slowdown as the file grows. That shouldn't happen.
4. Poor performance under load. When the load on a Linux box goes up, context switch time increases a LOT. This is bad.
And these are just off the top of my head...
Mind you, I am not diminishing Linux, it is still my primary development platform of choice, however as it stands it doesn't make a good platform for really big single-computer tasks. I'm sure this will change in the future, but right now as much as I hate to say it, NT and commercial Unix have the lead. Also I'd love to hear corrections to my points above, they would be good news to tired eyes.
Thanks
Some time ago Silicon Graphics asked for comments from users regarding what we wanted, and I replied that opensourcing xfs was probably the most relevant thing they could do. Since apparently SGI is moving away from their Irix95, and they have a huge investment in xfs development, this appears to be a natural step towards having xfs on their Linux platform. This is really a good thing, and the only OpenSource initiative SGI has done so far which will actually matter to most users. Now 4dwm would be nice too - that is really a nice window manager.
--
Thorbjørn Ravn Andersen "...and...Tubular Bells!"
It looks like free software has reached a critical mass. There is enough usable and successful source out there to make it more profitable to add to it than develop your own proprietary code.
This could explode.
This is one of the advantages of the GPL, with BSDish licenses they could just port it and include it and keep it as proprietary as before. If it should be possible to boot from XFS it would have to be in the kernel wich forces it to be GPL.
This is unfortunately also one of the disadvantages. SGI don't want Sun or MS to be able to use it and probably don't care at all for *BSD. So they will probably release it under GPL only wich means *BSD can't use it.
Actually there is a limitation in the VFS (virtual file system) layer that means right now no FS can have more than 2GB files.
It could well be that SGI have patches to address that, but that would be separate to the XFS code as such.
This restriction only applies to 32 bit platforms such as x86, non-Ultra Sparc and PowerPC of course. On Alpha, Ultrapenguin and Merced there is/will be no such limitation.
okay...
OpenVault - opensource . check
XFS - opensource . check
DMF - opensource . Well, not yet
Open Source Ronin
Or can any linux distribution modify their code to run on it?
I know the article said Linus would have to approve but journalists are great for misinformation.
I've been thinking about it for a while but now as soon as I make sure there is a driver for linux(Haven't looked yet)that I will buy one of those swanky digital flatpanel monitors.
Journalling filesystems slower than non-journalling ones? Not XFS!
XFS is actually faster than its non-journalling predecessor, EFS. I had both on the same hardware (low-end Indy). EFS itself wasn't bad. I thought is was faster than SUN's ufs on otherwise comparable hardware with the apps I used back then.
I'd never go back to an old-style FS if I had a choice. Glad to see a key piece of technology open sourced.
I'd sure like to hear what features you're talking about, because I can't imagine how anyone could think this. SGI's desktop tools are the best I've seen on Unix, bar none.
I think by ``non-SGI X server'' you actually mean ``X servers that do not support the GLX server extension.'' Is is really a surprise that SGI, who invented OpenGL, would write a lot of code that takes advantage of it?
It seems quite unfair to me to blame SGI for the failings of X servers shipped by other vendors.
You can argue that SGI should have met the least-common-denominator of all other vendors with these tools, but if they did, they would be throwing away all the technology related to their area of expertise.
They have a list of Linux jobs with them at
LinuxExpo I hear... Might want to contact someone
down there to pick it up for ya!
AC
Congrats to SGI for making the right move at the right time - hopefully their license will meet the OSD, if not GPL'd outright...
:)
With the source available shortly, let's do the GNU/Linux community a big favor and express our appreciation to SGI by adding proper disk quotas to xfs!
With the addition of an excellent filesystem, SMP and NFS will be the last barriers to making GNU/Linux 'enterprise-ready'
~AC
It's out there.
http://linux.msede.com/lvm/
It is not considered production code yet, but I haven't had a problem with it yet.
Very similar to the HP-UX implementation of the Veritas volume manager, though IMO the Linux implementation is shaping up to have better tools.
> SGI still is deciding how to structure the open
> source license, the company said, though it is
> sure to meet the requirements of the Open
> Source Definition, a spokesman said.
They need more than OSD compliance. If they want it to go into the Linux kernel, they need to use a GPL-compliant license. The main question is whether they want (or will accept) that the other proprietary Unixen can use it. If not, then the obvious choice is to GPL it. It will cause problems for the BSDs, but why should SGI care? They don't have the hype (momentum) of Linux.
If they do want their file system to become a standard, they could LGPL it, or even use an X-like license. That would also make it easier to backport changes to Irix. Using the LGPL would fmake it more problematic for competitors to keep their changes proprietary.
It depends on what RAID level you use. Doing
RAID 5 in software is CPU intensive and unsuitable
for most situations, but for simple RAID 0 and 1,
a software solution is much more cost effective
than hardware. Since disks are so cheap these
days, I would rather buy a bunch of drives and
do RAID 0+1 than pay the big bucks for hardware
RAID 5.
-Yun Ye
Not to put a wet blanket on the party, but if it already doesn't include mentioned things like quota support, etc.. and they aren't releasing all of the features, and they don't even have a licence decided on yet...
Looks like it will just be a part of the code that might be incorporated into ext2, and will help some, if there are enough tallented people to actually do it (I sure know I won't be doing it). And, given it will take time for them to decide on the licence, it will take time to deal with the licence, and time to incorporate the code.. It might be a long time before we even see the effects of this _part_ of xfs incorporated into a Open Source OS (and who says Linux will be the first to use it?).
Apparently, this file system does not have quota or ACL support? As per the SGI white-paper on the XFS filesystem, those features are on the TODO list.
Is this something we will be able to put in given the source, and call the whole thing ext3fs, and release it in Linux 2.4?
Good filesystems are some of the most difficult code in an operating system, so having an excellent base like XFS will certainly help. Thank you SGI!
Sig (appended to the end of comments you post, 120 chars)
es this is a great step. But...
>As someone noted above, XFS can become >corrupted. I've got one here. And the XFS >managment is pretty dumb old stuff in >comparison to what IBM offers out of the box.
>
>So in reality, I'll be moving to Monteray for an >enterprise os because it gets me all the power >of AIX (plus SCO plus linux) on an Intel (or >PPC) platform.
Question: Who gives a damn?
I'm not sure off the top of my head if XFS supports ACLs. I would tend to think so. However, e2fs has supported ACLs for a long time. However, the linux kernel does not, nor are there stable ACL aware versions of acl utilities, or an acl-aware version of e2fs utils. I did come accross a group that was working on it. However, they were only at the alpha stages, and seemed to halt development after kernel 2.2.0pre9. Anyways, the issue of ACL is one of the kernel and user space programs, not the filesystem.
PS - Slashdot could use a full dictionary of terms from around the site... That'd rule..."
... Then you may want to check out What is it -
a really good web dictionary.
http://www.whatis.com/default.htm
They can have how meny differen lisences they like without interfering with each other but they might want to include the changes in the linux version in their own propertary version so I don't think they'll chose GPL lightly, but I hope they do
yes, the unix style acl's are not very useful at all
vms had great acl support, and that got "ported" to nt, which is why the nt support is so good. it wasn't a microsoft idea.
Another thing that would help get Linux into the data center, would be a real disk manager like Vertias Volume Manger. Lets hope that they port it to Linux, or maybe even open source it!
Lack of a volume manger is the last thing from keeping me from recommending Linux to the managment at the company I work for.
Not to mention Hans Reiser's fs called (guess what) Reiserfs.
It wouldn't have journaling at first, but it is planned.
>...one thing that hasn't been pointed out yet: journaling file systems don't (immediately) overwrite a file when it is changed.
>
>To elaborate, imagine a long tape that represents your hard drive...
It hasn't been pointed out because it's not true. What you're talking about is a _log structured_ file system. That's a whole different thing. A _journaling_ file system looks after the metadata using a (duh) journal that records changes to directories, attributes, allocation maps etc. so they can be either rolled forward or rolled back upon reboot. However, a JFS (not necessarily IBM's JFS, though they were pioneers in this area) has pretty much the same ways of handling the actual file data as any other FS, including deferred writes etc.
Any FS including a JFS or LSFS may support features for increased synchrony providing greater data integrity, such as fsync() or O_SYNC, but that's really a separate matter.
Slashdot - News for Herds. Stuff that Splatters.
If I'm not mistaken, I believe journaling plays a role in file recovery. fsck'ing 10 gigs can take awhile.
Anyone else more versed on how this works?
If you want grio, you'll have to get IRIX.
They are only releasing the journaling part,
and it's limited to 64-bit.
This is the perfect move. They give Linux something great, get extremely good PR, establish XFS as an industry-standard, and still manage to
keep a proprietary advantage
to make you want to buy their machines for technical reasons. Really smart.
Even such a `limited' version will
be better than NTFS.
I think it will be a standard GPL. The real issue is removing the features they don't want to give away (i.e., GRIO). They also have to make sure they aren't releasing code which under license from a third party.
I don't care if SGI sells it or open sources it and charges you $6,000 per year for support (current price) but:
XFS + OPENVAULT + DMF
Would make Linux THE choice for HSM/Nearline storage
(DMF = the Cray Data Migration Facility)
http://www.sgi.com/software/dmf/
You don't beat someone by giving them technoligy they can add what ever crap they want and make it a closed non standard, thats the way to beat yourself.
What you get is OpenStandards and ClosedSource. I prefer OpenStandards and FreeSoftware.
I say, BSD lisence suck because it doesn't cooperate but rather forks in 1000 different directions with just a few free versions and tons of un-free. But if you wan't your code in every application except GPL ones BSD is the right way...
Or if you want to get ripped of by practically everyone but get your collage's name written on every ad it could be good to...
If microsoft had bad TCP ip it would be perfect, they would weak in networks and not the slightest threat to anyone...
De lyckliga slavarna är frihetens bittraste fiender, legalisera!!!
Gees guys, look for the self intrest angle here. If I want to do X, what do I need before I can make it happen.
For IRIX 6.5:
52 extreme % man acl
NAME
acl - Access Control Lists
SYNOPSIS
#include sys/acl.h
DESCRIPTION
Access Control Lists (ACLs) are supported on XFS file systems only.
ACLs provide a mechanism for finer grained access control than the
traditional UNIX discretionary access control mechanism. An ACL is a
list of users and/or groups and their access rights, which is associated
with a file or directory. ACLs are optional. In addition to the ACL
used to mediate access, a directory may have a second ACL which defines
the default initial ACL for files created in that directory. Files have
only the single access control ACL.
At the interface to the library routines, ACLs are represented in a
struct acl which is defined in sys/acl.h.
[snip]
Try Everything And, if a definition doesn't exist, you can write one yourself.
It's a slash-cousin.
I've never had an ntfs server boot faster than a Linux server (both with the works) - journaling seems to be more of a status thing (another brag point for Linux - one of an endless list) than something that will be widely used or practical (depending on the nature of SGI's license and actual market interest). Secondly, I can't imagine ntfs on a crummy 32bit OS even being comparible to XFS on an advanced 64bit OS.
Mike
They plan to use Linux to compete in the low-middle range of servers, as well as under Intel systems. Having XFS available for Linux will only help them, competing with NT in that market. Finally, we see a company actually contributing something besides a few cash investments in RedHat. With more moves like this, companies investing in Linux and the open source movement, what can Microsoft NT really do against both the open source movement AND companies with wary eyes at Microsoft's monopolistic practices? The fall of the evil Empire is not far away...
XFS has "Attributes" which can be attached to inodes. Apparently they're user defined. Maybe Linux use of XFS can reserve certain values for ACL or Capabilities use. Yes, we have to deal with verification...but that's already an issue with networked drives, clusters, and trusting any disk mount.
A friend of mine spoke with Linus back at the 96 USENIX conference. He asked him if there were any plans for a new filesystem such as XFS to replace ext2 because of its limiting factors. Linus said that he was open to anyone porting XFS because he didn't have the time to address it since other portions of the kernel required more attention at that time.
Just my two cents worth
then again... NTFS isn't that good...
Yes this is a great step. But...
As someone noted above, XFS can become corrupted. I've got one here. And the XFS managment is pretty dumb old stuff in comparison to what IBM offers out of the box.
So in reality, I'll be moving to Monteray for an enterprise os because it gets me all the power of AIX (plus SCO plus linux) on an Intel (or PPC) platform.
If it can only be used as a module and can't be compiled into the kernel, you can't use the root partition with it. (Unless you go through all the mess of an initrd setup.) Arguably this is not a big issue since on most servers the root filesystem is distinct from /usr, /var, /home and the rest of the big stuff, so it's small and doesn't take much time to fsck. OTOH most of the configuration is on it (/etc) so losing anything there could be a problem.
Actually Irix does have software RAID, Raid 0 (stripping) comes with the OS. If you want to do mirroring or any other level you will need to purchase an additional module (sucks, but it is an option). I personally prefer hardware based, so that I can get better performance than software, and get much better reliablity i.e. system crashes with outstanding writes waiting for disk, software based you lost all of them, hardware you have them cached within the external raid box.
Depending upon what you define as "clustering", you should check out Array, it allows you to connect Origins & Challenge servers into a cluster. On top of that you can use FailSafe for HA between clusters (or within clusters). The biggest beef I have with FailSafe is that if you are using hardware raid and not using SGI's tweeked up Clarion it won't fail to another path within the same box (lose a controller), if you are using software raid then it works fine (go figure). Failsafe ver 2 supports N to 1 and N to N where I believe it has a max of 8 servers set in a cluster.
I personally like SGI's desktop, the only time I ran into problems with another X-server is when you have to run SGI DGL. I don't use any of their GUI admin tools, I tend to "power admin" and do everything through vi and text files (try bringing up 18000 users in their user manager hehehe).
Thomas Suiter
If they only release it as GPL, it can't go into the BSD kernel. But nothing stops them from releasing it under multiple licences. But I highly doubt they'll go with anything BSD-like. That would be like telling Sun 'here's our XFS file system, please adopt and expand it for your own proprietary use'.
None the less it isn't SGI's fault if other companies don't use the GLX extension. Would you remove all the XFree extensions that SGI doesnt have?
Having "just" journaling alone would not actually
m l
be *that* important; logical volume management
is more important -- fortunately XFS gives
both.
Journaling gives you "just" faster startup times
after crashes because the filesystem should by
definition never be in an inconsistent state
(no fsck or equivalent required). However,
for big disk farms the flexibility given
by a logical volume manager is really important.
(the flexibility is not bad for small setups,
either...)
Here's a nice white paper on XFS:
http://www.sgi.com/Technology/xfs-whitepaper.ht
Just a thought - it hasn't crashed yet on my amiga, and I'm using an early beta from ages ago, and I delibrately tested it by power cycling in the middle of lots of writes on several occasions.
/. effect minimisation,
It's great to never have to use l:disk-validator (amiga fsck) again ( o.k, ok. it's in ROM, not l: on all Amigas above 1.3, but hey...)
The website has an exceptionally clear discription of how the filesystem has been implemented. It's 64-bit, using the NSD (New Style Device)API.
It's also free.
here's the site :
www.xs4all.nl/~hjohn/SFS/
In the interest of
the feature list is duplicated here:
(Note that some of the things described are amiga-specific. The dos.library limitation, in particular, is irrelevant to linux, and probably to future amigas, too. The 2GB max single file size limitation arises from the amiga's incomplete transition to 64-bit APIs - CBM went bust as the NSD spec was released, and, once again, may not be relevant to a linux implementation)
This page gives you an overview of what SFS is capable of. It will also give you an idea what features we are planning to add in the near future in planned features, and what features we are considering later on.
Features
Below you'll find a list of features which are already implemented in SFS.
Fast reading of directories.
Fast seeking, even in extremely large files.
Blocksizes of 512 bytes up to 32768 bytes (32 kB) are supported.
Supports large partitions. The limit is about 2000 GB, but it can be more depending on the blocksize.
Support for partitions larger than 4 GB or partitions located (partially) beyond the 4 GB barrier on your drive. There is support for New Style Devices (NSD) which support 64 bit access, the 64-bit trackdisk commands and SCSI direct.
The length of file and directory names is internally limited only by blocksize. Limitations in the dos.library however will reduce the effective length of file and directory names to about 100 characters.
The size of a file in bytes is limited to slightly less than 4 GB. Because of limitations in dos.library we will however probably not allow files larger than 2 GB, to avoid potential problems.
Modifying data on your disk is very safe. Even if your system is resetted, has crashed or experienced a powerloss than your disk will not be corrupted and will not require long validation procedures before you will be able to use it again. In the worst case you will only lose the last few modifications made to the disk. See Safe writing for detailed information on how this works.
To be able to ensure that your disk never gets corrupted we use an internal caching system which keeps track of modifications before writing them to disk. This cache has the additional benefit that creating and copying files can be a lot faster, especially if the drive used isn't very fast (ZIP & floppy drives for example).
There is a built-in low-level read-ahead cache system which tries to speed up small disk accesses. This cache has as a primary purpose to speed up directory reading but also works very well to speed up files read by applications which use small buffers.
Disk space is used very efficiently. See the Space efficiency page for a comparison between a few filesystems.
Supports notification and Examine All.
Supports Soft links (hard links are not supported for now).
Using the SFSformat command you can format your SFS partition with case sensitive or case insensitive file and directory names. Default is case insensitive (like FFS).
There is a special directory which contains the last few files which were deleted. See deldir.
Planned features
The list of planned features below are features which are either already in development or are very likely to be added to the filesystem in the near future.
Multiuser support.
Built-in background file and free space defragmenter. Already the filesystem is set up in such a way to allow for easy implementation of this feature without having to do extensive scanning of the disk before the defragmenter can begin. This means defragmenting can be done in the background and can be interrupted at any time (even by a reset, crash or power failure) without loss of data.
Mirroring of important filesystem administration blocks to make the filesystem more robust.
Features we are considering
The features below are either features which are very application specific or not used very often. If there is enough demand for some of these features we will consider implementing them in the filesystem.
Mirroring of complete partitions. Such a feature would not only ensure that all your data is very safe since everything is stored twice on two different drives, but it will also speed up multiple concurrent read accesses since both drives can be used to deliver data. This feature however normally is only used on mission critical systems (like file servers) and would be of little use on systems not equipped with high speed SCSI controllers.
Support for striping. To put it simply, striping can be used to distribute data to multiple drives which increases the total available bandwidth as each disk will be used simultaneously to access part of the data. If you for example have 2 drives than with striping all odd blocks of 64 kB would be stored on drive 1, and all even blocks of 64 kB would be stored on drive 2. A similair scheme is used with more than 2 drives. With striping there is also an option to use one of the drives as a parity drive. If one of the drives crashes or becomes unuseable than the data on that drive can be reconstructed using the remaining drives which ensures that your data is very safe. However, although it may seem that striping could speed up disk accesses by a factor of 2 or more, this is usually only the case when working with very large video streams or multi user systems. Under normal conditions you will be hard pressed to find any speed gains at all.
Support for hard links (soft links are already implemented).
The ability to extend a partition without having to copy all your data and format the partition.
New DOS packets. There are lots of ways to exploit the ability of a filesystem better than is possible at the moment. New packets are the key to this. For example, support for paths larger than 255 characters, live directories (directories which are updated in realtime), enforcing recordlocking and many more. This however must be a team effort and we'll need support from writers of important applications and people willing to build new interfaces to access these new abilities.
There have been a few good answers to this question in this thread, but there's one thing that hasn't been pointed out yet: journaling file systems don't (immediately) overwrite a file when it is changed.
To elaborate, imagine a long tape that represents your hard drive. The tape is written from left to right. When a file is changed, the new version is appended to the end of the existing data, while the old version remains "untouched" farther to the left. When the kernel has finished updating all pending file writes, it can write a "checkpoint" at the end of the existing data. Essentially the checkpoint says "everything up to the point is kosher." If the disk gets really full, then the filesystem can double-back and overwrite the really old data at the beginning of the tape.
Now, let's see how this works to help recover from crashes; say the computer crashes as it's writing out a file to disk. In a conventional filesystem, a lot of things could go wrong: it could have been overwriting the old data, but finished only half of the job. Then, at best, you've got a corrupted file with a hybrid of new data and old data. The file allocation table may not have been updated, so the file may be completely lost. It's a bad situation.
Conversely, if the crash happened with a JFS, the computer would run an "fsck" and look for the last checkpoint. It's guaranteed that all data preceding the checkpoint has integrity. Then the filesystem would just work from that checkpoint and ignore any non-checkpointed data. This can still lead to some data loss, but never to filesystem corruption.
Of course, this is a simplified account, and there are implementation details. But that's the gist of it.
Nope, they could have a GPL'ed version and a prorietary version if they wish so. However, they would need permission to include _others_ improments to the free version in the proprietary version.
Actually, they need such a permission in any case. But in practice it will be easier to get if they use a license that also allows others to make their own proprietary versions. It will then tend to become the "default" license for all modifications.
SGI is back on it's feet!
Let's we all (day traders) go and buy a decent amount of their shares ...
... Sun, I can only say I just feel sorry for being so short minded! But you still have time to backup and have MacNealy eats his words back and join the FORCE. Otherwise I am feeling you will become the next DarkVader after MS falls down; and guess what ... The FORCE is with US!
Linux ... what dreams may become! _ _____
_______________________________________________
Why software RAID? Simple. Speed.
Jamie Zawinkskiw said:
"I think by ``non-SGI X server'' you actually mean ``X servers that do not support the GLX server extension.'' Is is really a surprise that SGI, who
invented OpenGL, would write a lot of code that takes advantage of it?
It seems quite unfair to me to blame SGI for the failings of X servers shipped by other vendors."
SGI takes it to ridiculous extremes, however. What does Jot do, for example, that requires GLX?
I believe you need to have ACLs in order to be
B1 or B2 certified.
If you're trying to sell your system to the govt. then this might be important to you.
SGI could choose to use the GPL plus alternate licensing, and still get back improvements from others. This can be done either by getting assignments from contributors (if they are willing) or recoding the changes in a different way. Regardless of what licensing is chosen, getting assignments (as FSF and the egcs project do) is probably the safest thing to do, as I expect that within the next year, Microsoft or someone they put up to it will attempt to sue some high-profile open source project for theft of code (just find some contributor who didn't have the right to contribute, because of an employment contract or something), thus spreading a piracy taint over the whole movement.
It should be emphasized that at the least, SGI would be shooting themselves in the foot if they choose a GPL-incompatible license such as an NPL-like license. The reason is that this would force all Linux distributors to use their filesystem only as a module, which would be inconvenient. If SGI's work requires changes in the kernel itself, then it wouldn't even be valid to use it as a Linux kernel module if it's not under a GPL-compatible license.
SGI could use a BSD-like license (without the advertising clause), which would permit both BSD and Linux to use the code. They might not want to give that much away, though. You'll never beat Microsoft if you write code for them (yes, Microsoft networking has tons of Berkeley code in there, you can tell from the bug-compatibility).
I hope that they either go in the GPL or the BSD direction, and don't try to do one of those one-sided NPL-like licenses that is becoming popular with companies (e.g. we can take your changes proprietary, but you have to distribute source).
*BSD can't use GPL in the Kernel, and this file system if it relly get released as GPL all linux system could use it easily and boot from it and I'll bug every BSD user about it until the end of the world/or end of BSD... :-)))))
But I don't think this will happend, Netscape relly fucked up then they created their own lisnce, now every company do the same misstake. If it ain't GPL I won't be relly happy about it. Modules suck!
> ...the OS itself has no software RAID facility.
> SGI/IRIX achieves HA RAID using HARDWARE, There
> external RAIDS are made by Clariion and simply
> look like a SCSI device to the OS, you can do
> the same with Linux today.
If you'd rather do software RAID then you have never worked in an enterprise environment where speed and reliability are a concern. Why somebody would use software RAID when hardware devices are available at low costs COMPLETELY blows my mind.
ALG
They used to be the state of the art bad-ass workstations.
And yet, they still do. I'm sorry, but SGI's closes gfx workstation competitor remains Intergraph. (Sun? Gimme a break. Maybe when Sun actually offers something in the same league as the original Onyx I'll reconsider. Sun sells boring-flavored business workstations.)
If you think SGIs sell poorly, perhaps you should check on how Intergraph's sales are doing.
I don't know why SGI machines don't sell better. I still think they offer the best possible price performance for graphics (and server and computational performance) than anything else out there.
I as a previous SGI fan felt isolated by the jump to NT, and I wasn't alone. Their NT workstations just didn't sell as much as they wanted, so now their jumping onto the Linux bandwagon.
They haven't even been out a year. Give 'em a chance.
And how do you know anyway? Facts and figs, please.
And, why should anyone have felt *isolated* by SGI's adoption (note the word adoption instead of *jumped*) of NT? I don't get it. Maybe it's just because I didn't care.
I wonder whether we'll ever see the day when billionaire philanthropists buy the rights to successful commercial software and then turn around and release it under the GPL in the interests of humanity.
Sheesh, evil *and* a jerk. -- Jade
as i recall, someone out there already has a volume manager for linux that works almost exactly like hp's volume manager...
anyone have more details on its location, etc?
Peter
I'd love to be able to run XFS on our apartment FreeBSD fileserver/firewall, as well as my Linux desktops. I am really looking forward to playing with this! Thank you SGI!
--
Jake
NetBSD 1.4 has a log-structured filesystem called LFS, though it may still have a bug here or there. And it really wants a cleaner that also consolidates (defragments) files as it cleans.
cjs
The world's most portable OS: http://www.netbsd.org.
SMP and NFS come to mind. (Good implemenataions of.)
Journaling filesystems keep a "redo-log" of all activity (changes) to the filesystem. If the system dumps (crashs) the redo-log is re-run at the "fsck" time so the filesytem will be complete again and the fsck take relatively no time. I have a very large Sun machine at work that has a terabyte of a Oracle table space that would take almost an hour to boot (due to the basic fsck of the oracle tablespace filesystems) unless it crashed then it was almost 2hours or more. I move the oracle tablespace filesystems to a journaling filesystem and now it takes about 12-15 minutes to boot maybe 20 minutes if I crash the box. Before the journalling filesytems, whenever it crashed (or I should say almost always when it crashed) I had to manually fix filesystems in maintenace mode. Once I moved the filesystems to a journaling fs, I have not had to do that again. If the journalling filesystem is stable and works like it is suppose to, I would move *all* my machines (including laptops, desktops, and servers) to it.
Scott
C{E,F,O,T}O
sboss dot net
email: scott@sboss.net
Scott
janitor
sdn website family
email: scott at sboss dot net
There is an LVM implementation for Linux.
It's coming along nicely.
Have a look at http://linux.msede.com/lvm/
^D
-- open source? sounds like the real book --
I'm guessing you know the answer to this already, but the reason Jot requires GLX is that it was written using a GUI toolkit that happens to be built on OpenGL instead of on Xlib. I haven't used that toolkit, so I don't know what its merits are, but it's sure not hard to imagine a GUI toolkit whose API recommends it over Xt or Motif.
Jot is also a very old program; most of SGI's tools use Motif these days.
But, you know, there are technical reasons why one might want to use GL in something like a text editor, too: because when you only use raw X, performance sucks . For example, you're not going to be able to do things like, say, scroll text smoothly without using an API that gives you more direct access to the frame buffer than the baseline X protocol gives you.
Even for non-3d applications, the performance improvements you can get by using GL instead of X are amazing. I mean, my god, raw X can't even do double buffering properly. (And before you mention the ``double-buffering extension,'' try it with XFree86: the performance is identical to copying pixmaps yourself by hand, meaning that's doubtless how it's implemented in the server.)
As Don Hopkins so eloquently put it, `` The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid.'' All the associated layers of pseudo-generalism make it impossible to actually take any real advantage of the underlying hardware.
Oh yeah baby
If SGI so desired, they could actually release a binary-only module which implements XFS (complete with GRIO (*drool*) if they really wanted to), and do so without GPL or anything that resembled an Open Source license. (Ick.) With that in mind, it stands to reason that a filesystem module could be distributed under any license, since it could be built separately from the kernel and modprobe'd in.
A different question is whether or not code that is part of the kernel source tree proper (eg. /usr/src/linux, also known as "everything in the linux-X.Y.ZZZ tarball") must be GPL'd, and I believe that said code does inherit the GPL from the rest of the kernel's GPL-ness. (Any license lawyers out there care to expound on this point for us?) If this is the case, then if SGI wants this to be part of the Linux kernel source tree, they'll have to jump on the GPL bandwagon.
I think "kernel patches", if they're distributed separately from the official kernel and must be applied manually by the users of the patch, are also exempt from being GPL'd, although this is a significantly greyer area. Kernel patches distributed in this fashion act very similarly to programs that #include GPL'd header files. eg. If I #include a GPL'd foo.h in my program, but I don't distribute my code with said foo.h, I don't believe my code becomes GPL'd -- even if foo.h is under GPL rather than LGPL -- although I'm not 100% certain. Anyone care to clarify on that particular grey area?
--Joe--
Program Intellivision!
Posted by skaffster:
What I could never figure out is, if the JFS has to keep a changelog, where does it store it? If it's on the disk, how do you handle corruption to the changelog file(s) if it crashes? Anyway, the whitepaper URL is
Excerpt from http://www.OpenBSD.ORG/policy.html
The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.
While this may be a noble strategy in terms of software sharing, it is a condition that is typically unacceptable for commercial use of software. As a consequence, software bound by the GPL terms can not be included in the kernel or "runtime" of OpenBSD, though software subject to GPL terms may be included as development tools or as part of the system that are "optional" as long as such use does not result in OpenBSD as a whole becoming subject to the GPL terms.
As an example, some ports include GNU Floating Point Emulation - this is optional and the system can be built without it or with an alternative emulation package. Another example is the use of GCC and other GNU tools in the OpenBSD tool chain - it is quite possible to distribute a system for many applications without a tool chain, or the distributor can choose to include a tool chain as an optional bundle which conforms to the GPL terms.
So a GPL part only have to be optional, XFS qualify.
There have been some excellent White Papers on
:(
m l
XFS over the years I recall at both USENIX and
the LISA mtgs. Might want to browse them.
There was one in 95 about XFS and guaranteed IO;
I KNOW there was one in Jan.96 in San Diego as I
have a copy still. Titled "Scalability in the XFS File System" sorry no link
Try this, looks recent:
http://www.sgi.com/Technology/xfs-whitepaper.ht
Check em out!
wahl@sgi.com
Yet SGI/IRIX it is considered an Enterprise OS:
2. Poor support for RAID - hot spares, hot swap, etc.
I manage several Origin 2000's with Fibre Channel and SCSI RAIDS. While the IRIX OS does support powering down a SCSI chain for swapping out a drive, the OS itself has no software RAID facility
SGI/IRIX achieves HA RAID using HARDWARE, There external RAIDS are made by Clariion and simply look like a SCSI device to the OS, you can do the same with Linux today.
3. Poor NFS performance (speed and locking)
While SGI (almost) properly implements NFS3, good luck if you are serving/sharing files with anything other than a Genuine SGI. They've screwed with the Sun implementation enough that it really pays to just stick with SGI for all your workstation/server needs.
5. No high availability clustering (Beowolf is cool but completely unrelated to this)
While there is an expensive, fun to set up FailSafe IRIX available, it is only limited to TWO nodes and not really true clustering (kindof like the original NT implementation).
4. Poor desktop environment
I use 4Dwm daily; its features pale in comparison to the linux offerings. While 4Dwm is "ok" it has a major flaw in that many of the features available on the desktop are not available to a non-SGI X-Server (such as Linux/eXceed). As the servers such as the Origin 2000/Origin 200 ship headless (no display) and we interact with the servers using Linux/NT-eXceed this is a major shortcoming. I wonder if the SGINT-eXceed combo is any better.
now go crawl back under the rock you came from. :))
When Linux goes critical mass, we can probably free up some real estate around a small lake in Washington State.
Codifex Maximus ~ In search of... a shorter sig.
and several million hours saved worldwide for
fs non-gurus like myself. When can we burn the
rescue disks?
Lets hope it all comes together in an acceptable way. If/when it does, what a gift for humanity!! (or at least the
short fat flippered version thereof)
-- open source? sounds like the real book --
The change log is on the disk. It is stored sequentially.
Basicly it is like this: You write to the changelog "I'm going to modify sector xxx to be yyy" Then you modify sector xxx, then you delete that part of the changelog. IF anything in the changelog is corrupt, it doesn't matter cuase you didn't write the change to the other sector. If something is in the changelog after a crash, then you go in quickly and re-write all those secotrs bringing them up to date. This saves time because you only check the sectors in the changelog, the rest must be safe because they are not in the changelog. And you can tell if the changelog is corrupt (it would only be one sector) and not modify the affected area. Therefore you always either have the new data, or a rollback to the old one.
If the license for XFS is any sensible (i.e. a true Open Source license), this is the single most intelligent thing SGI could have done to score with the Open Source movement. Linux is in dire need of an Journalling File System and XFS is one of the very best of this flock.
Their white paper on XFS explains how XFS is different from conventional file systems and what they did to it to make it fast with very large files as well as with many, many small files (SGI is not Open Sourcing their GRIO capabilities, which together with RT scheduling would make Linux a serious multimedia contender).
If you are a USENIX member, you will be able to download the Sweeney paper Scalabilit y in the XFS File System from the USENIX server. It was published in the Spring 1996 proceedings of the USENIX, so you may also read it in your Universities library.
With backing from a company with such prestige as SGI, the future is looking brighter and brighter. It's nice to know that SGI actually put its money where its mouth is and came through.
Linus doesn't have to approve anything. You can fork the kernel any time you want and include the patches you think are important. It just kind of easier if we all let Linus decide, and anyway, he seems to know what he's talking about. Usually :-)
Seriously, there's no reason why SGI might not release their own version of Linux with XFS in the kernel if for some reason Linus doesn't want it in the 'main' kernel.
In other words, the filesystem does not become corrupt, but files can. If your application needs to be sure it never loses data, it has to take care of that itself. With reliable metadata and appropriate flushing, it is possible for an application to do this, but a journalling filesystem does not automatically make existing applications safe from data loss in crashes.
I knew this was comming, but I though they were going to delay it for one or two months.
Now the only thing for a perfect world is that they offer me a job now! ;-)_ ________
____________________________________________
Forgive my ignorance here for I haven't learned much about file systems, but what is the difference between journaling and non-journaling file systems?
8Complex
PS - Slashdot could use a full dictionary of terms from around the site... That'd rule...
You can always tell where these people come from.
XFS in Linux is fantastic. The only ones who are likely to be unhappy about this are SGIs competitors, Sun, HP, and IBM. It is a shame that the method that they choose to express their discomfort is an anonymous note slamming a great move. The note was almost ad hominem in nature, worthy of the bit bucket and little more.
Most people see through this.
With XFS out, there is now a standard journaled file system for computers running Unix. This is a good thing. SGI does make some of the most awesome technology in the world, and XFS is a big part of that. I wonder what else is coming.
Well, hardware RAID is important, if only because there's tons of x86 server boxes out there that have hardware RAID cards in them, including many 486/586 Compaq boxes that are being decomissioned. These would make perfect Linux boxes.
Note that people go for hardware RAID on x86 even though WinNT has workable software RAID. So both are importantant.
--
Business. Numbers. Money. People. Computer World.
I've always thought of SGI as one of the coolest companies in the industry, but this announcement has put them over the top in my book. Wow. Thankyou, thankyou, thankyou SGI. I don't care if you're really doing it for your own self-interest; you're also helping a large community in a very big way, and I hope you reap equally large rewards for it.
I'm not a Linux kernel expert, but I suppose Linux and his gang would have to glue XFS to the VFS... but I don't think they would complain about that :)
SGI is dying, and this unfortunatly not many can deny. They used to be the state of the art bad-ass workstations. Hell, I learned most of my Unix from an SGI Indy and an AIX RS/6000. Now I own a Challenge & Indigo^2. Remember back in '90 how we used to be in complete awe of the demos that came with IRIX? They were always known to be unique, one of a kind. They had class, they had style.
But then in mid-97 it just all began to fall apart unfortunatly. Their Unix workstations weren't selling, they were losing competitive edge against Sun and NT workstations.. so they tried to jump on the NT bandwagon.
I as a previous SGI fan felt isolated by the jump to NT, and I wasn't alone. Their NT workstations just didn't sell as much as they wanted, so now their jumping onto the Linux bandwagon. It's great for the free-software industry (I myself can't wait to have some really nice OpenGL support on my FreeBSD workstation), but I think it's not done because they love free software, I think it's more of a marketing ploy. "We couldn't compete with the people who love NT, lets compete for the people who love free stuff, once we can convince the penguins that didnt realize we sold out that we're God, they can spread the word to the world"....
This of course is not to say that they haven't dipped their toes in the free-software industry for some time as the other unix vendors have, the difference now is they make press-releases.
And then they tried to switch their name from Silicon Graphics to "sgi".. owell. I give them credit for trying. I don't give them credit for giving up.
-- Proud owner of two beautiful real SGI workstations. Proud to say that they will only be running IRIX.
I'm impressed that they namechecked Stephen Tweedie's work towards a journaling ext2. sct, of course, claims that his work will produce the most stable and efficient filesystem the world has ever seen, but this work is certainly welcome while we're waiting. If it's GPLled (as I think it has to be) it may even help sct along...
--
Xenu loves you!
I hope this will not replace the non-journalling file systems for Linux, however. After having used them for a few years, I think the benefits of journalling file systems are actually very minor in practice and I don't expect to want to use it either on servers or clients. In addition, the XFS implementation is likely to be fairly complex (making other enhancements more difficult) and may not even perform as well as much simpler non-journalling file systems.
On balance, I think this will make Linux more attractive to corporate buyers and people for whom journalling is a requirement. But I also hope the mainstream of Linux file system development will explore other areas.