Slashdot Mirror
XFS merged in Linux 2.5
joib writes "According to this notice, the XFS journaling file system has been merged into Linus bitkeeper tree, to show up in 2.5.36." Ya just know someone out there wants to have every journaling file system on one drive just 'cuz.
The round file gets all my bills. The manila one gets all my pay stubs. It works out ok.
Always going forward, 'cause we can't find reverse.
This is pretty unexpected, at least for me. I know they had cleaned out the VM changes and things of that sort recently, but this is really something that I did not expect to see so soon.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Does anyone have a link to any comparisons of all these journaling filesystems, showing their strengths and weaknesses? Why shouldn't I just stick with ext3 for everything?
Code, Hardware, stuff like that.
From linux-2.6 on I don't have to repatch the kernel source with that sgi.com XFS patch everytime a new kernel comes out. BTW, I still have trouble getting XFS to work on linux-2.4.19 because sgi won't update their stable XFS patch from 2.4.18.
As I understand it, XFS also offers things like extended attributes. However, I have been told that the Linux VFS does not offer any way to read or write the attribute information?
Is this correct? Will the VFS also be extended so that you can make use of extended attributes in XFS?
read it today in the 2.4.20pre changlog
t in g/patch-2.4.20.log
http://www.kernel.org/pub/linux/kernel/v2.4/tes
the time moves by
There's an XFS FAQ and a load more information about it on SGI's site - which points out that several large distributions have had XFS support for a while by default.
Still, it's noteworthy that Linus has finally accepted it into his tree...
Meep meep
I'm still waiting on the original pre-HFS Mac file system to be incorporated.
Gentoo supports this out-of-the-box (is that an appropriate phrase for gentoo really, heh?.) as well as the other major distros thanks to the aforementioned sgi.com XFS 2.4 kernel patch. It is still great news to see this going into 2.5 -- 2.6 should be an excellent and well-evolved kernel.
i am using their cvs kernel version, which is always an up to date (with org. pre patches and so on). ;-)
m l
if you are not using some additional patches, this is the easy way of life
http://oss.sgi.com/projects/xfs/cvs_download.ht
This is great; more filesystem support is always good in my opinion. Now if we could just get some stable NTFS read/write support I would be set.
www.timcoleman.com is a total waste of your time. Never go there.
When I install Linux, and it comes to anything to do with filesystems, I just go with whatever default it gives me.
I suspect I'm not exactly alone.
So ... what compelling reason is there for me to use any other filesystem? Being more stable or better with data loss is nice, but considering I've only ever had this problem once, doesn't mean that i'll leap up and down going "oo oo! got to have blahFS!" any time soon.
To give you an example, FAT16 to FAT32 was the fact you could have larger partitions. FAT32 to NTFS was because of permissions and security.
But whatever we have now (can't remember, i barely look) to XFS? What *compelling* absolutely-must-have reason do I have to go change from whatever my installer suggests putting on for me?
Or should I just stick with what the installer suggests from now until eternity?
Avantslash - View Slashdot cleanly on your mobile phone.
For any of you Mandrake fans out there who like to bash Red Hat, and mention that Mandrake has had XFS file system included, while Red Hat does not, you would be wrong. While Red Hat does not officially support it, if at the installer's 'boot:' prompt you type in 'linux xfs', it works great. I've used it on a few systems with no problems.
------
Random, useless fact: I type in startx entirely with my left hand.
For those of you who don't subscribe to the Linux kernel development mailing list, it was absolutely not a case of XFS just being accepted, there was a HUGE flamewar about it, which only ended a few days ago.
Mailing list archive
Just search in the page for XFS and you'll find the thread.
When is Linux 2.6 likely to be released? I know that there is no fixed date, but what are the criteria?
My second question... Does it really matter when the 'official' release comes out, when distribution makers "roll-their-own" anyway?
Sorry if these sound like dumb questions to some of you, but I'd be interested to find out.
...is that the breakdown goes something like this:
:-)
ext3:
* can be told to journal everything, including data (not just metadata) -- most theoretical reliability.
* is backwards compatible with ext2
xfs:
* tweaked for streaming large files to/from disk -- probably best at sequential reads/writes.
reiserfs:
* best performance with many, many files in a single directory.
* Can save space on very small files with -tail option
jfs:
* really don't know.
May we never see th
Despite being a little more resource intensive than ext3, XFS has to be one of the better file systems available. I've used it (obviously) on SGI's and it's been outstanding, and opted to use it before ext3, JFS and Reiserfs (although I believe Reiserfs is just as nifty).
Having it accepted into the kernel makes upgrades a world easier, and hopefully I'll be able to move away from SGI's modified Red Hat installation. Although, I doubt Red Hat will support it out of the box.
The other issue that needs fixing with XFS is the lack of an emergency boot disk. XFS enabled kernels are huge, and that creates a slight problem when booting from floppy.
"The round file gets all my bills. The manila one gets all my pay stubs. It works out ok. " ...and the IRS gets everything else. Time to use that 'hidden' attribute.
this pdf compares how journaling file sytems compare to non-journaling systems like ffs or freebsd's soft updates.
Common sense is not so common.
2.6 has got me more excited than recent minor releases. Some of the things that look cool:
* ALSA support. ALSA is a pain to keep patching your kernel with every redownload. ALSA is a Good Thing, if a pain in the butt to configure. My guess is that there will be decent front ends on top of the thing when distros start shipping 2.6.
* Batch priority/boosted effect of nice levels. I've always felt that "nicing" something didn't have enough effect -- nicing something by one level is almost unnoticeable. 2.6 boosts this change. It also introduces batch priority, where a process gets *no* CPU time if there is *any* non-batch process in the runnable queue. Very sexy.
* Low, low latency. Just as 2.4 emphasized good multiproc support, 2.6 is emphasizing low latency. Preemptive kernel, lots of disabled-interrupt time being reduced (especially the godawful framebuffer console), etc, etc. This is top-notch for both I/O performance and multimedia. Linux kernel 2.6 is supposed to beat any current release of Windows in audio latency when released.
The only thing that I really wish Linux had was a prioritized disk scheduler. Linux can prioritize network traffic. It can prioritize processes. It just can't do the same with disk I/O. This is a shame, since I want my MP3 player not to skip when reading MP3s/paging, followed by X getting next highest priority when paging (so that the UI doesn't freeze up for long when paging something back in), and Linux just doesn't yet have the functionality. Currently, you can have a nice 20 process that's busy untarring a large tarball...and all your paged out processes will be blocked, waiting for this stupid tarball to finish.
May we never see th
Ya. And people want to have every ethernet card in one box just 'cuz, so there are a bunch of different drivers for ethernet interfaces.
I've been running Gentoo Linux for some times with XFS. Here's my experience with this filesystem :
- It's extremely reliable. Filesystems never got corrupted, even after a lot of ugly reboots.
- Recoveries after a crash are really fast. Almost immedate, better than ext3 and reiserfs.
- Every needed tool is available to resize filesystems, check filesystems, analyze filesystems and backup/restore filesystems.
- _BUT_ there's something strange. Basically during disk I/O, the whole system is unresponsive. While I'm compiling something, KDE becomes slow, playing videos is not smooth at all, etc. Just as if it didn't scale at all for concurrent disk access. So I finally switched back to ReiserFS just because of this. Maybe the 2.5.x series of kernel behaves differently.
{{.sig}}
Linux is used in an incredible variety of environments, from embedded systems without disks to seriously large servers and parallel supercomputers. As you might imagine, the default filesystem isn't always ideal. But, if you're just running an ordinary single-user workstation, and aren't experiencing any noticeable performance problems related to your disk access, then there's no reason to worry about your filesystem.
So "stick with what the installer suggests from now until..." you run into a reason to do otherwise, makes sense.
Ya just know someone out there wants to have every journaling file system on one drive just 'cuz.
That's the sound of thousands of English teachers weeping in despair.
How could you not love the fact that you never had to run scandisk ever again once you are running with NTFS? YOu can install win2000 with Fat 32 and it will work fine. But if your system ever crashes, which does happen, you will have to wait while scandisk is run.
I hate scandisk
something similar to Macs HFS+, support for extended file attributes, and the ability to move files and have the file system point to the new location when a program looks for it, I know this would add a lot of overhead to the file system, but it would make it so much easier to customize the file system. Linux needs to break away from many things that slow progress, and one of these is the "magic numbers" method of file typing, a exe tab, a user tab, and a read-only tab, just is not powerful enofe
hallelujah... i was waiting for this decission for 1 year and more now..... thank you...
1: one of the primary reasons people like XFS is because of ACL support.
2: Do -you- want your filesystem cluttered up with lookups that you don't even know exist? If you want them, create them: it's what "ln -s" does. Otherwise, it's bloat and overhead.
Now that your entire post has been invalidated, might I recommend you go and read what XFS does? Personally, I prefer ReiserFS for raw journaling. But XFS *ROCKS* for other stuff like ACLs.
$.02...
They mean faster reboots period because they never need to be checked on boot - so you don't get that annoying "Ahem, you've rebooted too many times, I'm going to check your hard drive while your client, who's looking over you shoulder, wonders why you re-assured him you'd only have his production server down for half a minute to install the new kernel, and I'm spending 5 minutes scanning his drives."
Of course you can turn off those checks on ext2 too, but that would be stupid.
"with their freedom lost all virtue lose" - Milton
I think you have a good point there. The problem is that Tux has no offerings to contain McNabb.
It's unfortunate really, and, quite frankly, I don't see this problem being resolved by the kernel hackers anytime soon.
At least Linux is open source, so any of those coding linebackers who care to step up the proverbial plate (to mix sports) have an equal shot at helping the coach out.
As my father lik@(munch munch)...
I've been reading about the differences between
using journals and using soft updates and have
decided that soft updates is the cleaner approach.
Can anyone explain to me why the Linux community
is so enthralled with the concept of journaling
file systems while the BSD community has quietly
but unanimously embraced soft updates?
*sigh* back to work...
This isn't correct... if it were correct, I would not have spent so much time working on a :)
custom Red Hat installer for XFS.
There is some XFS-aware code in the Red Hat Linux installer, but there is no kernel support or userspace tools available, so what you propose simply can't work.
However, SuSE, Mandrake, Gentoo, Slackware, and Debian (to some extent) do have XFS support.
There are systems where we simply don't and won't have enough disk space and where speed is not of the essence. We have them now, and we will continue to have them in the future.
Being a linux developer for embedded production boxes and given the current increasing interest over linux in embedded along with embedded boxes typically running _WITHOUT_ hard disks (mostly just flash chips of some sort, due to their better life-time), I cannot help wondering why the kernel mailing list shows little or no interest towards ext2 (or ext3) compression.
JFFS and JFFS2 don't come into question in most cases as they tear through the fs layers and cannot be used with IDE flash chips for example.
Alcatel even released it two weeks ago for 2.4.17... loads of people, like me, must have ported it to 2.4.19 by now. But to get ext2 compression to 2.5.XX, forget it... but why?
This little like the lack interest towards under clocking, eventhough once you've overclocked your main computer to the max, you will start looking for more silent option, if not for the desktop computer, but for the closet firewall. Even if you don't have the interest now, you will, once you shack in with a gal.
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
This is why I think there should be more useful rescue CDs.
CD burners are quite widespread, a quick rescue image could be quite small.
And yes I know not everyone has a burner, I don't either.
i'd much rather see framebuffer support for my maximum impact video card. Linux would make this indigo2 a lot more useful.
I used to run both ext3 and ReiserFS on my home machine.. my experience is that ext3 sucks..
Every month or so, I had to sit through the following:
"Warning: drive has been mounted more than 30 times, check forced" on the ext3 partition
I thought the idea for journaling was to AVOID fsck's on boot?
No OS withstands power cord disconnection well.
;)
I'm sometimes a clutz and my laptop uses ext3.
And well there are experimental kernels
One of the things both mentioned on the gentoo-user email lists and in the XFS FAQ is that if the power drops on a system using XFS, only the *metadata* is journaled, not the data.
Short version: If you're using XFS, make sure you are careful to have clean power available, unless you don't mind file corruption. If no clean power is handy, stick with the usual journaling filesystems.
This can get bad fast. With a full 30 seconds between disk updates, having the power cut means binary NULLs in any file updated since sync. (http://oss.sgi.com/projects/xfs/faq.html#nulls)
Now my charms are all o'erthrown, and what strength I have's mine own... - Shakespeare, "The Temepest"
I find that very cool, for some reason. I guess one practical application is if you have a box that is the only one of that type (either big-endian or little-endian) that dies and you need to recover the data.
--
Runnin' around, robbin' banks all whacked on the Scooby Snacks...
Ext3:
- compatible with Ext2
- can journal everything (data included)
XFS:
- very large volumes and files
- very good performance when writing/reading at high speeds, and/or to/from large files, and/or with concurrent access
- POSIX ACLs and extended attributes
ReiserFS:
- very fast with lots of small files
XFS supports ACL's (or access control lists) which are much better than standard UNIX permissions.
My experience tells me that with user/group/other protection attributes on a file you can solve practically 95% of the situations you encounter in an ACL protection schema.
The remaining 5% of the cases are likely to include a) a truly twisted protections schema implementation or b) file access protection as part of a larger badly designed application that relies on file system protection where it should have relied on a professional authentication/authorization/audit system.
ACLs are also harder to administer.
I just wish to get BeFS back. It was the best FS I've ever seen. Journaled, live queries, and FAST! Palm, it's useless to you, open it up! :)
- very high disk I/O performance, especially when reading/writing from/to large files
- extended attributes
- POSIX ACLs
- mature and stable
This comes secondhand, and is not a personal opinion of my own, but I think it's worth mentioning here.
I had an operating systems professor that did some filesystem design work (and DBMS design work, which at a low level and especially back in the day, was pretty similar). He was pretty negative on the mass demand for journalling filesystems.
See, what people really want is filesystems that don't get corrupt. It's also kind of nice if the recovery procedure at mount is pretty fast. So they want a filesystem that is always consistent -- it's never in a state where if the power is lost, the computer will try to mount the thing and say "hmm, this isn't a proper filesystem."
So if you want to add a file, you can't just add an entry to the table of files, then create the file metadata, than complete the filesystem operation, because you could lose power and end up with only the entry, but no filemetadata...so you have a pointer to garbage on the disk.
You need some sort of atomic updating. You want to say "at this point the change I'm making to the FS is not active, at this point it is, and nowhere in between is the FS invalid".
Journalling is one method of making atomic updating -- always write in the forwards direction on the hard drive, building a journal of all actions as you go, and just using the lastest journal entry when you're reading. Journalling tends to have pretty sexy write performance, because it always writes forward and doesn't have to seek it all. It also usually has fairly lousy read performance, since you have to be sure that you're using the most up to date journal entries.
To avoid some of the slower read performance, most "journalling" filesystems on Linux only journal metadata -- the lists of files in directories, permissions, times modified and so on, because the data is what you're really worried about accessing quickly, and if the data in a file gets corrupted when you lose power, you only lose that file -- not the whole filesystem.
It's possible to use other techniques -- I believe that BSD's FFS uses a non-journalling approach to ensuring a consistent filesystem at all points in time. Despite claims both ways, I don't believe that FFS is radically faster or slower than any of Linux's journalling filesystems.
And what's my personal preference? Well, I use ext3, because I already had an ext2 filesystem, and it's awfully easy to upgrade. ext3 used to have pretty bad performance, but now it's generally on par with ReiserFS (which was ahead for a bit), except for Reiser's strongest points (like a single directory with, say, five or six thousand files in it). That being said, I suspect that most people just use ext3 in it's "metadata journalling mode", which means that it doesn't have many advantages over reiserfs.
Ext3 builds heavily on ext2, which is a pretty mature filesystem. I've had one roommate that screwed up his reiserfs filesystem a while back. I believe the bug that caused that was fixed, but it made me a bit leery of reiser at the time.
The other misgiving I have about reiser is that I'm uncomfortable with the direction that the developers are going -- very heavyweight filesystem drivers, with plugins and all sorts of stuff. I'm not sure that I want my filesystem drivers to be so complex.
On the other hand, if you have lots of very small files (not empty, just a hundred bytes or so), Reiser does a great job of keeping them from eating up more disk space than they should (normally, you have to throw 4K or so at a file, unless you've changed the block size of your FS).
XFS, as far as I can tell, wasn't really designed so much to be a general-purpose filesystem as a streaming video filesystem.
And, as I've said earlier, I don't know a thing about JFS.
Other interesting tidbits:
* ext2 is still a pretty well-designed, fast filesystem.
* All of the mentioned Linux filesystems beat the snot out of MS's FAT-16 and FAT-32 in performance and *particularly* fragmentation. The popular act of defragmenting your hard drive on Windows stems solely from the fact that FAT was not well designed for anything but the very smallest of filesystems, like a disk.
* I've heard stories that NTFS (MS's new filesystem) is still worse off from a fragmentation point of view that Linux's FSes. That's second hand, so it could be wrong.
* I know for a fact that real-world performance on NTFS (at least in the NT 4 era) is significantly slower than on ext2. I have a strong suspicion that a fair bit of that stems from the ACL security system MS uses in their filesystems. In terms of performance, ACLs are not a good choice.
May we never see th
If you're like me, and you're doing lots of video processing stuff, then the ability to very quickly process files that are usually > 1GB is very neat. That's one reason to use XFS.
we just finally solved the vm crisis merged the code into one coherent mess and look whats happen...someone decides to add the code now to mess with the journal file system. ...
I know I am really going to get nailed for this (I know, I'm just a windows kiddie) but I've been curious about this for a while. What exactly is 'journalling'? I've bene hearing plenty of buzz about ext3 being a journalling system, but I still don't have any clue what the hell journalling is. Any links, responses, etc. would be appreciated...
You call that a flamewar? Puh-leaze!
There wa sno flamewar. Disagreement about various things, yes, but certainly no flamewar.
Nor was the thread itself huge by lkml standards.
My Suburban burns less gasoline than your Prius.
The problem you describe happens with all filesystems that do not have ordered writes: ReiserFS and JFS are also affected.
Ext3 has this "ordered mode", where metadata is commited to disk only after data was commited, therefore there's no chance to get NULLs no matter what.
A while ago, XFS had this pathological behaviour when metadata was commited after data, so the NULLs were quite a problem after power blackouts. But this was fixed since a few versions now, and there's no real difference between XFS and other journaled filesystems nowadays.
Anyway, if you care that much for your data, then you're better off using Ext3 with full journalling turned on.
Otherwise, i just use XFS everywhere, because of performance boost (ok, so i do use ReiserFS for proxy caches).
Could somebody post a comparison between Resier, XFS and Ext3?
Linux sucks.
Anyway, the big success story for Linux is servers -- and journalling file systems make a lot of sense for servers, because they're more bulletproof. I once worked in a place with a lot of Solaris servers using a non-journaling FS. Now we had fancy UPSs so the servers could go down gracefully. But they were no help when an overloaded power main caught fire (middle of summer), sending out a gigantic surge that took out the UPSs before the power went away. It was days before all the file system repair and restore was complete.
About a year later, I was working at a place with a lot of IRIX servers. Had a power failure there too. No surge this time -- but no UPSs either. So how long before the servers were back up? About ten minutes after the power came back. XFS, like other journalling file systems, doesn't get all inconsistent when it's interrupted.
I recently installed Linux-XFS on one of my computers here, as I was having problems with the kjournald process under ext3 taking extremely unreasonable amounts of time -- and I had had wonderful experiences with XFS on our SGIs -- it's always been solid and fast. Various reviewers of ext3 had complained about the existence of kjournald -- disputing the need for a user-code daemon.
Several places it is mentioned, though, that the kernel image of XFS is very large, so much that you can't really fit it onto a floppy (although people over-format their floppies to get 1.8 MB or so onto them, and then the kernel might just barely fit.)
I can't understand why any filesystem should be so big -- it seems that the code to run the filesystem is almost as big as the rest of Linux put together. How can this be? Is it really all code? What could that code possibly be doing?
I studied XFS fairly extensively after I had to repair a disk that had 1 of its 23 heads fail. From the remaining 22/23rd of the disk I managed to recover almost every file and directory, by writing my own XFS filesystem interpretation code. The on-disk organization of the filesystem is fairly simple and straightforward, I can't imagine where the hundreds of K of code is going.
I won't be shocked if the answer does lie in that kjournald daemon -- that XFS is bigger than ext3 because ext3 puts most of the bloat into a user-mode daemon instead of the kernel.
thad
I love Mondays. On a Monday, anything is possible.
oh no, it's the plan9 from bell-labs operating system all over again :)
reiser is just implementing what others have done long time ago:
http://plan9.bell-labs.com/sys/doc/9.html
Why the hell are Linus et al. using Bitkeeper which has one of the most ridiculous and annoying licenses known to man? I mean, if you read it, it's actually worse than Mickeysoft's!
Christ, it's enough to make me want to go to FreeBSD so that I can feel pure.
Yes, just like NTFS, ReiserFS, JFS, and ext3 (by default). That's kind of the whole point of journaled file systems: in the even of a crash, power failure, etc. you are guaranteed to get a consistent file system, though some data may be lost. Basically, you may lose a few files but you never lose the whole file system. ext3 is the only file system I know of that gives you an _option_ to journal data as well, but that makes it really slow.
___
If you think big enough, you'll never have to do it.
I survived powercuts and brownouts just fine when everything was on ReiserFS...
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
XFS has a file size limit of 32TB (or so, I think), with a _filesystem_ limit in the EBs. But, I've heard that the Linux VFS layer has a max file size limit of 1TB. Is it possible to create files > 1TB on a Linux+XFS box ? Unfortunately, I don't have the resources to try it out just yet... :-)
So is this the X-treme File System? Sure hope it lasts longer than the XFL did. The XFL was a great league, if only it lasted longer. I was really hoping to see who would win the million dollar game this year.
What ever happened to the Tux2 file system project? The concept behind Tux2 is far superior. I am disappointed it has kind of peter'd out. XFS was my runner-up for file system projects to root for. So I give them the "high-five" ... but what ever happened to Tux2?
I think the trick to this is to have a /boot partition, and a /root partition, and make them both ext2. Then you can boot from a floppy, and then boot the larger image on the boot partition. That was the reason given for having those partitions in the Linux Stadard Base documents, anyway.
But I'm an engineer, not an IT person, so I could be mistaken as I've never attempted to do it myself.
This way it would allow cool stuff like garanteed data consistency or rollback.
Imagine
/
$ begin_trans
$ rm -rf
$ rollback_trans
It is a little known fact that ext2fs corrupts data on power failure because it does not do synchronous writes nor journaling. For all these years, linux systems have been in danger of losing data, while BSD systems have been rock solid with the world-class FFS filesystem.
The skipping is caused by scheduling latency, as Paul suggests.
I can stand behind my claim that it isn't. I've had multiple processes running loops with the same priority running, plus flipping around in X (which I keep at nice -10) to test specifically this, and even with my CPU at 100% load, things stay okay.
*Only* heavy, long term disk activity causes this. I even tried jacking the mp3 player up to nice -20...that's not it.
I had a friend run the same test on his SuSE box with Reiser and 2.4.18 -- same problem, at least as vulnerable. It isn't the filesystem, it's the disk scheduling.
This also isn't short term "blips" -- even if you have other processes eating CPU time, the mp3 player should be getting CPU time frequently. I have #define HZ 1000, and if there is one other process running, I should be seeing 500 context switches a second. Take into account a few extremely low daemons, and you still are getting a good 100 context switches a second. That's way more than enough. I'm talking about a total mp3 dropout for *many seconds*.
In short, the soundcard will be starved of ready to play PCM data long before the decoder will be starved of MP3 encoded data (from disk).
I agree. However, in my case, CPU is nowhere near a scarce resource, but the disk is completely saturated.
I'll make you a challenge. Denice your mp3 player. Run five bash scripts doing infinite loops (while [ true ]; do done;), not niced. At least on my system, this produces no dropouts at all (though six just start to do so). Then run *one* cat process, niced to 20. It will cause dropouts (at least with the mp3 player I was testing with, mpg321, which doesn't precache the whole thing in RAM).
Furthermore, the dropouts I get with the bash scripts, CPU latency issues, are significantly different. They are very short, and sound like static -- a buffer or two wasn't filled. The dropouts I see with the nice 20 cat are far longer, lasting a second, then two, then three.
The problem is that Linux doesn't have any sense of disk scheduling priorities attached to processes. I mean, that's not egregious -- AFAIK, neither does Windows, and I haven't heard of any general purpose OS doing this (though I haven't looked around). But it would be nice, and though some workarounds exist (such as the elvtune that someone else pointed out), I have to specify that latency be emphasized for the whole disk -- what I really want to do is say that "this one process needs high disk priority".
May we never see th
I did not work with it by myself, but my friend told me that he used to work with FS as with SQL DB in a manner you described. I wonder if there are any plans to port OS/400's FS to Linux.
Less is more !
Still not as technically elegant as I would have liked, but *damn*! Changing the read elevator max latency from 8192 to 32 makes a tremendous difference. No more breakups with the workloads I mentioned!
May we never see th
I implemented this once as a special patch in Irix/XFS. It's not sufficient to do it just in the file system. The priority must be passed down to the devices. With Fibre Channel devices supporting a good-sized output queue, it is important to utilize the priority queuing supported by the disk channel vlsi chip. Unless there is device and driver support for priority queues, reordering the disk block queue at higher levels in the OS is usually not effective.
This kind of priority is best-suited for real-time processes that have real-time needs for disk access. The problem of keeping a big tarball unpacking operation from sucking up lots of space may be better solved by adding space constraints rather than having prioritized i/o.
Finally, a filesystems where one dont just have the old user/group/other for granting permissions. XFS supports posix ACL(and EA's), meaning now one can grant arbitary users and groups the appropriate permissions. GREAT!
They're not. A short ACL is no more complicated than RWX permissions and would achieve the same purpose. However, when you need real find-grained access control, they're there.
Since RWX permissions don't offer any kind of granular security, admins must hack other access control methods on top of them in software to get the security they need. Which is a lot more complicated.
Besides, your routers and proxy servers are already using them, as are most industrial strength Unixes. ACLs are needed to ensure granular permissions, and are necessary for anyone who runs a file server.
Imagine a bunch of HR documents on a server. These documents are used for things like, for example, firing people.
Its a common scenario, and one rwx simply can't do unless you hack other access control schemes on top. Which is much more complicated than a three line ACL.
I've used all three of Resier, XFS, and Ext3fs on a couple of different machines.
I've had *all three* result in a corrupted file systems for me, not due to hardware failures, but improper shutdown (typically on laptops that don't resume from a restore, or otherwise die suddenly).
I would say the severity of the corruption in each case, for me, from greatest to least, would be XFS, Reiser, and Ext3.
From what I've read, XFS's design is by *far* the most advanced, and the potential reliability and performance are far greater than the other two; the white papers on it are truly impressive. Hopefully, the corruption I experienced was due to using an earlier version, and that those glitches have been resolved.
The ext3 corruption was in some ways the most frightening, because no problem was ever actually reported, until a fsck I did one day reported a whole bunch of problems.
I think that once people try out the mature XFS, that it's benefits will become more and more obvious, and hopefully someday it will be the default filesystem in major distributions.
Love many, trust a few, do harm to none.
SGI's modified Red Hat installation...
The other issue that needs fixing with XFS is the lack of an emergency boot disk
Pop in the SGI modifed Red Hat, boot off the CD, and type `linux rescue'.
XFS was only the 2nd journaling file system available and useable on linux, after ReiserFS, and before ext3 and jfs. Quite odd that cmdrtaco would get the impression now that there's too many jfs's in the kernel, where have you been I ask? It's been there for a couple of years, and without a problem with over 300 days uptime.
XFS is more advanced than ReiserFS, JFS, and ext3 in terms of fs feature support on linux, the only thing missing I believe is shrinking the fs online.
You're mixing filesystem features up. To clear things up a bit,
- Individual inode records need not be of a fixed size.
- The inode table (total number of inodes) need not be a fixed size, and it can even be moved around, and spread across, various physical locations on the disk.
- The inode table can either have a special-cased storage method (ext2/3), or simply be stored using the filesystem's own block allocation methods -- in effect treating the inode table as a "normal
file" (jfs, ntfs, several others) This second method has the property of being very flexible: just as it is trivial to extend the length of a normal file [i.e. append], it is trivial to add new inodes to an inode table that the filesystem treats internally as a "normal file."
There are wild and varied ways to store inodes. But ReiserFS definitely has them.Regards,