Slashdot Mirror
XFS Beta
Motor writes: "Things have been a bit quiet on the XFS front over the last few months, but a beta is finally here." They've got a document to to read before installing, as well as some installation notes on the site. It looks like it's a patch for 2.4.0-test5 kernel, and you can also get it as RPMs, or ProPack.
The 2GB limit was (if I recall correctly) due to the Glibc..
With Redhat 7.0 - this problem is history - so you can use kernel 2.2 and create huge files (I think up to 2 terabytes)
Hetz (Heunique)
Looks like someone doesn't read the news...
UPDATE: Starting kernel 2.2.18pre9 - there is the NFS V3 - so people should start thinking about migrate from NFS V2 to V3...
Hetz (Heunique)
BUT! It's a 64bit machine... and what I'm reading about XFS sounds interesting. At least I could turn it into a half decent file server.
Anybody knows how stable 2.4.0pre is on the alpha? what about XFS? and what about how optimised GCC is become for the 21x64 processors?
Has compaq got their own journaling fs and a NIX system that works on alphaPC platforms?
---
"Hasta la victoria siempre!" El Comandante
Cool, a journaling file system... Remove that off of Microsoft's 'Linux Myths'...
Woah there! Do note that although it's great progress for Linux, XFS for Linux is *still* in Beta. I gather IBM's JFS is coming along too, so the race is on.
--
The laptop now goes through a stop-without-proper-umount and reboot without having to check the filesystems again. I had to change the flags that "lilo" tells the kernel, and had to add flags in /etc/fstab, and had to boot with special flags ("rw") once to create the journal on the root filesystem.
Bruce
Bruce Perens.
... I perused the XFS for Linux site, but could not find any information regarding LVM or SGI's toolset (revolving around xlv).
Are they only porting the XFS and none of the LVM support? My memory may be slipping, but I don't recall any mention of LVM (for or against porting to Linux) in any of their online documentation (except for some manpages, which are taken from IRIX)..
XFS without LVM? Disappointing...
Your Working Boy,
Well, the source will be open, so there's nothing to stop BSD'ers from snarfing the source to port to BSD provided they can get past the licence infection of GPL->BSD. In short, it's probably going to be up to some developers hacking with it.
--
Due to known problems with later versions of gcc, version 2.91.66 must be used when compiling XFS and the associated kernel.
Does this mean that gcc 2.9 is officially supported by Linus and co to compile 2.4, or is this just required for XFS?
---
And technically, "83" is a "Linux Native" partition, not ext2, so perhaps it's not so bad.
Just keep it in mind when you use a filesystem tool...
---
I tried it in August, and had a lot of problems.
I needed XFS support in my Linux box to read a bunch of TGA files from a 18 gigs scsi drive formatted in XFS on a SGI box. Very often my machine crashed and it took me days to get those dawn files. You should wait until the stable version is ready.
XFS works with RAID0. RAID1/5 is a bit more tricky, but we'll get to it.
Martin K. Petersen, XFS team
We're working on replacing the current block I/O subsystem in Linux (aimed at 2.5, but will exist in the XFS tree in 2.4). Currently, Linux does block I/O in entities known as buffer_heads, which carry 512 byte payloads. The new scheme is based upon Stephen Tweedie's kiobuf model, and will support big (SCSI supports up to 16 MB/req) I/Os. XFS was primarily designed for big sustained I/Os and once we're done with the kiobuf support we'll start profiling the code and push it to the limits.
Regarding ports to other architectures: My Alpha here at the office is running XFS, but I haven't committed the changes yet. I ported XFS to it for fun a month ago but never got around to committing the changes. I'll do that at some point. And possibly look at SPARC.
But then again. This is Open Source. Feel free to hack on it and send us patches!
Martin K. Petersen, XFS team
"I want to use software that doesn't suck." - ESR
"All software that isn't free sucks." - RMS
Currently there seems like a lot of limitation on what software you need and all. glibc 2.1.3, kernel 2.4.test-5, etc.
It is good to see that SGI is still working on this after such a long time of silence. I guess working in the Internet world I kinda expect projects to move at internet time. After all that is what kind of pressures I have to work under. But atlas I am not writing filesystems and drivers.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
first off
SGI have DRT (Done the Right Thing) so THANK YOU SGI
XFS is compaterble with the IRIX file system but the implementation is differant in parts
I wonder how fast this is compared to others, ext2 blew alot of FS out of the water in terms of speed
anyone got benchmarks of XFS on IRIX and on Linux ?
Well done for geting the PPC port working but what about ARM/MIPS ?
I am compileing it on redhat 7 as I type so will try it out
yes you can compile linux with 2.95.2 but there where problems I would stick to EGCS at the moment and thats what SGI recomend but redhat want 2.96 to work and they are trying to get everything working for the upcoming 3.0
have fun
john jones
(a deltic so please dont moan about spelling but the content)
XFS Beta Release Caveats
Size and Memory Limitations 2 Terabyte filesystem limitation
Currently XFS is limited to filesystem smaller that 2 terabytes. This is due to limitations in the Linux block device I/O layers.
The XFS team is working with Linux developers to improve the Linux I/O layers. The improvements will include the support neccesary to exceed 2 Tbyte filesystems.
4 Gbyte memory limitation
Well, those "caveats" won't prevent my servers running for a long time!
Just let me know when they'll be beta testing their boxen on my desktop.
Cheers,
levine
What about ext3 (which provides journalling) - hasn't that been released yet?
ext3 is available as kernel patches from ftp://ftp.uk.linux.org/pub/linux/sc t/f s/jfs/; there's still a bunch of issues to be aware of.
Pro: very nice transition from existing ext2 filesystems and back again. Does journaling so bye-bye long fsck times.
Con: Does data+metadata journaling so write performance is about 1/2 ext2. Must still be classed as experimental, I wouldn't yet go production with ext3 - reiser seems to be stable enoug to use on production systems right now.
If you're interested in stuff increasing the availability of your system (journaling filesystems, hardware monitoring, cluster configurations..) the site to visit is http://www.linux-ha.org, it's got a nice colection of links to the relevant projects.
you have moved your mouse, please reboot to make this change take effect
-- Oh Well
I like ReiserFS, it's pretty good at what it does, like being a quick and easy journaling FS for your average joe-shmoe desktop power user. I love not having to fsck my 20GB HD on a powerfail. It's really slick that SuSE had ReiserFS in the default install.
HOWEVER.....
XFS is totaly designed as a high performance FS. It is fully 64bit (on 64 bit platforms, not a concern on x86), it is growable (very slick), and has basically everything you'd expect from a high-end "commercial-grade" journaling FS. Why? Cause it is. It's the Journaling FS that SGI designed and uses in all of their completely badass servers.
As for stability, XFS is pretty good now. There are a few issues. I had problems with XFS+Athlon+Ultra/ATA66, but for highend SMP machines with SCSI, XFS can't be beat!
Also, keep an eye out for IBM's JFS in the future.
Quando Omni Flunkus Moritati
Personally, I don't really care either. I will never be able to afford that much space (HDD or RAM). And if prices fall to the point where I can afford such things, then I am sure that the kernel team will have solved those problems (considering they will probably own that long before me).
But, I know of servers (Alphas) that already exceed these limits. How am I supposed to convince these servers owners to switch OSes (not that I'm trying anyway)?
Devil Ducky
Devil Ducky
MY peers would get out of jury duty.
I keep hearing "kernel people" say that "Journaling Filesystems don't work with Linux' software RAID" but I've been using ReiserFS on a 60GB RAID0 device at home for several months with no problems at all...
For those of us on a budget (like 90% of us are...) and have to use cheap IDE hardware with software RAID, but want the reliability of a journaled filesystem, this is an important question!
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
i dont know if anyone is interessted in this but there is a great article on journaling filesystems at linux gazette.
it explains different features and concepts related to the 4 different journaling filesystems. XFS, JFS, Ext3 and ReiserFS.
-- http://electronicintifada.net --
Here is the page you wanted. You have to put up with 'scalable, reliable blah di blah di blah' (is that bumf a legal requirement for computer companies now?) on the first page, but there's quite a bit of useful info on it. I think I might give it a go when I've got a bit of spare time.
For the current release of XFS, the filesystem block size is limited to the size of a memory page. On a x86 architecture that size is 4 Kbytes.
Note that files systems created on an IRIX/MIPS platform must have been created with a 4 Kbyte block size in order to be mounted on a ia32 Linux system. File systems not created with a 4k block will fail to mount with an error indicating the mis-match.