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.
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?
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
Why? Gentoo has been using the XFS patches for a while now and it seems really stable. And I know this is more of a perception thing, but it seems much faster than ext3fs, for me, on the same hardware.
Well because it used to make extensive VM changes to the kernel, which was keeping it out for so long. The way I understand it, it was a direct port of the IRIX XFS mostly, and thus also had some IRIXisms that could cause problems on Linux. I read a recent post to lkml that indicated they had cleaned it of VM changes, but I really didn't expect a merge so soon.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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 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.
In Tux's name, why?
(Actually, I'm assuming that was a joke. I do like Linux's HFS support, since I run a mixed platform household.)
-- Alastair
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.
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'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...
Actually, if you had been keeping up, some guy had broken XFS up into nice tiny patches, while also converting it to use the generic I/O routines. In the end, there were four lines of changes to non-XFS code. There is an OS news article about this, with a link to the relavent lkml thread.
A deep unwavering belief is a sure sign you're missing something...
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 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?
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...
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! :)
Gentoo supports this out-of-the-box...
No, Gentoo used to support this in the kernel... until 2.4.19-r7. It's been pulled out as of this update. When I asked about this on alt.os.linux.gentoo, I was pointed to this thread on the gentoo-user mailing list. In a nutshell, concerns of data loss when a system powerfails or bad interactions with preempt (which is also included in the Gentoo kernel) are the primary reasons. Luckily, the emerge --update did not toast my old kernel dist folder so i still have it... but you may want to wait.
This pertains to the current stable (1.2?) release.
Perhaps this move in the dev kernel will prompt someone in the Gentoo dist-building realm to re-add this to the kernel.
(i'd post a url to my questions in the ng but i x-no-archived the thread.. silly me)
(and this post is non-pro non-con xfs.. though I've worked with SGI systems, own an Indigo2 and think the fs is pretty solid).
-'fester
You are arguing for a method. From my experience that absolute best, without question method of determining file type is "magic bytes". This may seem strange, but magic bytes have the amazing capability of being preserved by virtually every interface anybody uses to copy files. That makes them infinitely better than any attribute. And don't give me any crap about magic bytes colliding or not identifying text files, I challenge you to find *any* file format that a real user would "double click to open" that cannot be identified by magic bytes.
The problem with magic bytes is filesystems that return the filename vastly faster than they return the data from the file. This makes it inefficient to look it up. Though probably no big deal for double-clicking, people seem to be addicted to the "icon" in the file viewer, though I have never seen anybody rely on this (try rearranging the small icons randomly on Windows and see who notices) and that requires opening every file. However "thumbnail views" seem to be catching on and these require opening the file anyway. I believe ReiserFS is addressing this and making it fast to open files. There is also a problem if the file viewer does not have read access to the files, though it probably could not read the attributes either in that case.
If you refuse to use magic bytes you must use attributes. Unfortunately you are seriously constrained by requiring an attribute that will copy by most file copying mechanisms and will be written by existing programs. It also helps if it is obvious to the user how to fix the attribute. Unfortunately I think the only workable solution is what Windows did, which was to use the file extension. My only experience with attributes is Mac OX9 and OS/X and I have always been annoyed with them, as a .jpg file will often lauch an unexpected program (such as a Classic app).
If a file system supports attributes, I strongly recommend that they be used as a "cache". This should be the obvious way to use them for "thumbnail views", but there is no reason to not do the same scheme for "types", if the type attribute is missing you then spend the time to use magic bytes to determine the type. File copying programs can strip all the attributes and the effect will be invisible to the user except for a slight slowdown the first time the file is used.
I also want to say that the Mac HFS system that preserves files is equivalent to the older Unix "hard" links that existed in the very first versions in 1970. I think these are rather an embarrassing part of Unix history and can actually be proven to be a mistake, and led to all kinds of horrible file system mantinence problems. They tried to fix it by disallowing hard links to directories, which coincidentally eliminated about 95% of the usefulness of them. "soft" links like ln -s make are much more useful, predictable, and the user and programs can control them in obvious ways.
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
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
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... :-)
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.
the reason they pulled it is because of gentoo ppc. Very unstable on ppc.
keanmarine.com
This way it would allow cool stuff like garanteed data consistency or rollback.
Imagine
/
$ begin_trans
$ rm -rf
$ rollback_trans
Software patents. The author is frightened of a
patent held by Network Appliance that seems to
cover Tux2 and so has discontinued work on it.
Never mind he has prior art, they have more
money and lawyers. Welcome to software
development in the USA in the 21st Century....
Jeremy Allison,
Samba Team.
Here's the basic theory. Think about what happens when you make a change on a filesystem - say you add a file to a directory. The system has to:
If you don't do these things in the correct order, there will be times when the on-disk structure is not consistent. For example, you may have modified the directory to include an entry for the new file, but the entry points at an inode which hasn't been filled in yet. Or the inode may be filled in, but the free space pool hasn't been updated to correspond with the data block allocations in the inode. Throw in other modifications like deleting files or making them larger or smaller, and it gets pretty complicated. If the machine happens to crash at such a time - or the power goes out and you don't have a UPS - the disk will be in an inconsistent state. This has two major consequences:
Journalling prevents both problems (barring bugs in your OS or hardware, of course) by writing transactions to your filesystem. Instead of making changes directly to your directories, inodes, free block maps, etc, the filesystem batches up such changes by spooling them to a separate area on disk, the journal. Then, when it has written enough such changes to account for an entire, self-consistent transaction, it puts a marker in the journal indicating "transaction complete" and starts copying these changes to their usual locations on disk. Meanwhile, the next transaction can be spooled onto the end of the journal area, and it will get its own "transaction complete" marker when it is done. A journal can hold a lot of transactions - only limited by the journal size, which is usually configurable. When a transaction has been fully copied out of the journal to its final locations, it is re-labeled "journal free space" in the journal.
How does this help? Imagine that the machine goes down while a transaction is still incomplete in the journal. Next time you boot, the OS "replays" the journal: it looks for all the completed transactions and commits each part of a transaction to its correct permanent location. It ignores journal free space, and any incomplete transactions - essentially rewinding the filesystem state to the end of the last completed transaction. There is never any danger of "partially updated" filesystem state, since each transaction starts and ends with a known-consistent state.
(Ah, but what happens it the OS goes down again while replaying a journal? No big deal: next time it boots, it just replays the same journal again, which produces the same result as it would have done the first time.)
Some simplifications, obviously, but that's the basic idea. Did it help?
The different levels of journalling have to do with whether all filesystem data is journalled or only some of it. You usually only journal metadata, which is the filesystem structure: directories, inodes, free block maps, etc. That's because copying all your file contents twice (first into the journal, then into its permanent location in the filesystem) is quite slow. The main purpose of a journal is not to guarantee pristine file contents in the event of partially written files, but to ensure a consistent view of the filesystem as a whole - so you can avoid that long fsck and avoid ever ending up with a partially or fully scrambled filesystem (modulo hardware failure, of course).
HTH..
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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
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
Actually NTFS is a journalling file system; a very good one in specification and a fairly good one in implementation.
Gentlemen, you can't fight in here, this is the War Room!
This kind of priority is best suited for real-time processes that have real-time needs for disk access.
:-)
:-)
Yeah. Like my mp3 player.
It's not sufficient to do it just in the file system...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.
This isn't Serial ATA or anything. Plain old vanilla ATA. No command queuing.
May we never see th
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'.
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,