Slashdot Mirror
ext3fs in Linus' Kernel Tree
peloy writes: "According to Linus' changelog for Linux 2.4.15pre2, the long waited ext3fs, the sucessor of ext2 with jounaling capabilities, has finally made its way into the official kernel tree. I have never tried ext3fs but it looks that now that it is "blessed" by Linus I'll be upgrading my old and trusty ext2fs partitions soon."
...and there was much rejoicing.
I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.
Yay!
-David
There. Now go play some cool javascript games!
I've been running ext3 for about a month now, and it is so much better than ext2. I'm glad to see that Linus decided to merge it in. I know that there were some issues for a while with ext3 not working with the new VM, but they finally started releasing patches for the latest 2.4 kernels.
-Alien88
I've been using ext3 ever since I upgraded to 2.4.14 a few days ago. Its nice to have the journaled FS... as I have been testing out a lot of !cough!nvidia!cough! proprietary drivers and bleeding edge software lately, and subsequently crashing. W/ ext3, I can get back to the crashing very quickly.
/var first, its simple to convert). It definitely speeds up the directory access... and on my squid it cut the average response time by a full half second... :-P.
That said, I also use ReiserFS for some other things(try
I personally think ext3 will win out, as it takes about 20 seconds to convert a 6GB partition... vs. XFS or ReiserFS taking nearly 10 minutes, and much more complexity.
SpamapS -- Undernet #Linuxhelp
Of course we'll have a lot of posts here talking about the issues of backwards compatiblity, ext3's offerings, etc, so we migh as well get those out of the way now.
From what I understand, ext3fs is just ext2 with journaling support, so in the (somewhat rare) event of a system crash you don't have to go through a time-consuming fsck during the next boot. Results in better data protection and more uptime.
If an ext3fs enabled kernel on an ext3 partition needs to go back to a previous kernel for some reason, or say, you forget to compile ext3 into a kernel, any ext2 kernel will still be able to read/write to an ext3 partition, as long as it was cleanly unmounted with the ext3 kernel.
Why not push ReiserFS, XFS, etc? It seems that most of these are not very well proven yet. ext2 is tried and true, kernel support is good, and the new revision adds journaling, so why not stick with ext3?
AFAIK, these are some of the most FAQs about ext3. I wonder how often they'll show up below...
XML is like violence. If it doesn't solve the problem, use more.
My /home partition is reiser and I have been satisfied with it. But when X decides to poo itself for the umpteenth time (Radeon DRI drivers cause a hard freeze on my ALi chipset... unless I booted and used 3D under Windows first) I hate having to fsck my / partition (which is still stuck in ext2 land because I'm afraid to change it). Maybe ext3 will be the solution for this.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Question...
What are the individual file size limits, and overall filesystem size limits for each of the various journalled filesystems?
I ran into the file size limit on ext2 just recently (2GB, I think it was), and I want to upgrade to something that handles larger files.
Thanks.
well the best part about ext3 is if something goes wrong .. you can convert the system back to ext2 in a second.. just mount it as ext2;-)
having said that .. i've been using ext3 for over a year now without any glitch. i had a 30G partition and lots of power failures .. so ext3 really eased my life and converting a current ext2 to ext3 is also pretty simple. no more backup of 30G of data ...
Anybody have any real-world benchmarks we can have a look at? I hate to sound redundant on this, but performance is a big issue for web/file servers (which is mostly what I'm running these days).
If the "running the hell out of it" scenarios look good, I'll probably give it a shot on a production box. Actually, knowing me, I'll give it a shot anyhow, but hey...
Just as a thought, I'm operating from a starting assumption that it's *pretty much* just ext2 with journaling, but it's the overhead for the journaling that raises my eyebrows just a tad...
Thanks for the feedback!
This is good news for me, but also in a way bad. Only a few short hours before this article was posted, I was trying to upgrade my mandrake kernel 2.4.8 to the 2.4.14 kernel and everything seemed to be perfect up until the reboot- I got a kernel panic- no support for ext3 in the standard kernel, and for some reason the support wasnt caried over from make oldconfig.
Its good that we're going to have support for this, but Im sorry I couldnt have waited a few more hours before doing this! The only real problems I've had with updating is a few NIC drivers (not a problem anymore) and FS support. Last time it was no ReiserFS support and now its no ext3.. (sigh)
-----------------------------------------
Perversely greped and groped by PowerPenguin
Reizer leaves me with 100 free
Is this going to chew up more HD room? I'd love to find a nice, ext2-like file system to make this laptop's root.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
GNU/ext3fs
ext3 was just about the only reason I was using -ac kernels...
Stating on Slashdot that I like cheese since 1997.
I'm using it since the first 2.4 version (0.0.1) for 2.4.5 without any problems.
How to contact me - http://www.pervalidus.net/contact.html
Sorry to say that, but production sites like Rpmfind.Net use ext3 in the last ~2 years without any troubles. About XFS, I don't care, but do a search here to know why Linus won't include it before 2.5.
How to contact me - http://www.pervalidus.net/contact.html
http://ftp.sourceforge.net/ has 850GB storage, half of which is reiserfs, half is ext2. Both filesystems have been running flawlessly for > 4 months of production (actually longer, but wasn't reiserfs before). That server pushes between 15Mbit and 50Mbit/sec, and pulls/syncs about 2-5Mbit/sec, 24x7. reiserfs also powers the CVS tree filesystem for cvs-mirror.mozilla.org (also tokyojoe.sourceforge.net), which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth. I don't get involved in kernel politics, but as a production filesystem, reiserfs is ok in my book.
I remember reading somewhere a while back that Linus and other kernel developers were disinclined to ever put XFS in the kernel because it was a huge amount of code and pretty ugly.
Here's a quick explanation of a journaled filesystem, courtesy of LinuxPlanet.com:
The term "journaled" means that the filesystem maintains a log or record of what it is doing to the main data areas of the disk, so that if a crash occurs it can re-create anything that was lost.
...
The idea is that the system can crash at any point in this process but that such a crash won't have lasting effect. ... So when the system reboots, it can simply replay the journal entries and complete the update that was interrupted, or it can back out a partially completed update to restore the file's previous state. In either case, you have valid data and not a trashed partition.
Basically, it means no more long disk checks at startup after a crash or power outage. :) And it virtually eliminates disk fragmentation too, I believe. Hope that helps.
Mozilla's a nice operating system, but it needs a better browser.
So journalling's been available to the masses for a while now. Or maybe Michael meant ease of converting for the installed base?
Now if only the damn preemptible kernel patch would make it in. Unfortunately, it looks like that's going to wait until 2.4.5. *sigh*...
--
Runnin' around, robbin' banks all whacked on the Scooby Snacks...
First, XFS is not necessarily a proven technology. XFS is a port of the XFS filesystem used on IRIX systems. XFS has a proven history of performance and stability, but that is on IRIX. The Linux version of XFS will be proven technology when that version proves it to the Linux community.
Why choose ext3? Ext3 is an extension of ext2. The XFS code adds many changes to various parts of the Linux kernel. Ext3, changes less. XFS changes must wait for the 2.5 tree.
In the long run, I think ext3 will win out above, ReiserFS, XFS, and JFS. Being able to convert and ext2 to ext3 partition is the largest advantage. I know I didn't want to do a backup-restore to convert a partition. Within seconds, you can convert ext2 to ext3.
The chance that XFS will go into the 2.4.x series kernels any time soon is small to non existent i would imagine as there is a lot of changes to other parts of the kernel to allow the features of XFS to be implemented.
It wouldn't surprise me to see it go into 2.5.x at some point though !!
Ok, I can already hear the Trolls arguing which FS is superior.
;)
Personally I'd say that it depends and it is not the point asking whether one should use ReiserFS, ext3 or XFS.
Personally I've been using ReiserFS for ages without ANY problems at all on a number of systems running SuSE, Mandrake 8 and recently on RedHat 7 and 7.1. Over the time I've been more than satisfied with the results I got regarding speed, stability and so on.
But personally I'd really like to be able to freely choose which FS to use - I really can't understand why especially redhat was ignoring ReiserFS all the time, claiming (IMHO you can't otherwise say so!) it was "unstable". This must be some kind of weird "political" or strategic question.
So my 2c: at least leave the average user the ability to choose his preferred filesystem in Distro setups and don't just simply stick to one and ignore the others as if they wouldn't exist- nobody will complain if it's set to ext3 by default for beginners.
What about tux2? I think that was it "phase tree"/"tree phase" whatever it was... That sounded cool, is anybody still working on that?
Basically you don't need journalling because the fs is always consistant.
Someone asked Linus about the preemptible kernel patches (and latency in general) at the Annual Linux Showcase on Thursday night. The thing about the preemptible kernel is that it is only for uniprocessor - SMP kernels aren't preemptible. So unless you want the SMP case to be capable of tying up a processor for "too long" at a time, then you need to re-do each bit of code which is capable of long latencies anyway. The other thing which came up is that responsiveness of the system improved quite a bit recently with VM fixes (2.4.14 was the improved version, I think). It was a matter of the VM queueing up too much I/O (and the drivers trying to throttle it, instead of just throttling it all in the VM - or something like that). The preemptible kernel won't solve that kind of problem - although it may change/mask the symptoms enough to make it a bit hard to be sure where a problem is.
Oh, and to bring things back to ext3, Steven Tweedie was also there and made a number of comments about ext3. He has been fairly busy/nervous lately as ext3 just got into the hands of Lots Of(TM) users (when it shipped with Red Hat 7.2). The most serious problem I remember him talking about was that the 7.2 installer had a box marked "upgrade my ext2 to ext3" and one marked "makefs the filesystem" (or something like that), and some people were checking both - which would create a nice new empty filesystem in place of the one which was being "upgraded". But of course that is just user error plus a confusing installer, not a kernel problem. Most of the things which looked like ext3 kernel problems seem to be something else, as far as Steven has been able to tell so far.
The ext2/ext3 limit is 4 terabytes, but Linux
device files have a 1 terabyte limit.
http://www.cs.uml.edu/~acahalan/linux/ext2.gif
Pay attention to the note on the right.
That explains why apps often break at 2 GB.
Does the new ext3fs increase the maximum filesize? If so, what is the new max size?
I dunno... What do you wanna do?
RedHat Linux 7.2 ships with ext3 compiled into the kernel by default and installs with formating you partitions as ext3.
Perhaps this is Linus' way of saying: "Ok, Alan, I'm sorry about the VM. Are we even now?"
I have nothing against the ext3 filesystem or the new virtual memory patch but Linus needs to stop adding these relatively radical changes into the so called stable kernel reserved only for drivers and bug fixes. The issue is not that big for most hackers reading this but alot of us run Linux on mission critical servers that we bet our jobs on. Even before the radical kernel patches, all the newer kernels had big-time showstopper bugs. Many admins even run the old 2.2 kernel to avoid unnecessary problems. I have been running 2.4 and had no problems yet luckily. However I really do not know if I can recommend Linux as a server OS anymore. I want stability and Freebsd and Solaris seems to meet my needs alot more. Hopefully this madness will stop soon. We all love to bash Microsoft for releasing buggy service packs for NT that have not been tested thoroughly but there seems to be no real testing with Linux kernel patches. Freebsd conquered this problem by having 2 development teams. One for the stable branch and one for the development branch. No radical changes are allowed in the stable branch and the stable branch must go under lots of testing to be approved to be released as stable. I now know why BSD hackers love there development model. Cutting edge is great for some users but please do not include it in the kernel where a lot of people count on it for servers and mission critical applications.
http://saveie6.com/
So, mark one vote of confidence for reiser.
Okay, if you have a set A with N elements, and you add an element to the set such that set A now has N+1 elements... well, that doesn't change the original 0 through N elements.
Your complaint can be applied to the case of adding driver support to an existing kernel. You see, in the life of a kernel, time passes. As time passes, new hardware, software, algorithms, etc. come out. In order for us to keep modern, we have to add new things to the existing set. You're just... silly.
Going back to my original statement, the new virtual memory subsystem wasn't an addition. He was removing an element from the set and replacing it with something different. That could be argued as bad, but in practical terms it ended up perfectly fine.
Furthermore, if you had done any homework, you'd have realized that ext3 is built using hooks that have been available in ext2 for years. Technically speaking, ext3 is as stable as ext2 because the fs can still function as ext2 if ext3 support goes away or breaks.
So stop bitching about support for new things being added to the kernel. We could only be lucky if new features were added faster. At the very least, stop dumping FUD on us. Your alias is so very appropriate in light of your post.
Why bother.
This is a FAQ, but it bears repeating: XFS requires a lot of changes to other parts of the kernel, since it was designed for IRIX which has a completely different design philosophy from Linux. Since the necessary changes are rather invasive, it is best not to drop XFS straight into a stable kernel.
ext3, on the other hand, pretty much drops right in. (Oh yes, there is the common journalling layer, but that doesn't disturb the rest of the kernel much either.)
I've never had much trouble with OSS drivers. What problems have you had with them, or is this just hearsay?
The kernel OSS drivers are maintained by kernel people, they're not just the original OSS drivers as put out by 4front.com.
ALSA is not yet ready for primetime. At least, they weren't ready a year ago when the 2.4 kernel was getting ready for release. Again, we must ask - is it a good idea to swap out the whole sound driver technology right before or during a stable release period?
I had my hopes that ALSA would replace OSS in the 2.3 cycle - but it didn't happen because they weren't ready. It probably will happen in 2.5.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
For the weekend sysadms, like me, a conversion will not be started before getting a FAQ
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
/dev/hda4 is easier to understand than /dev/ct0s1r4? Also, you're saying that the typical utilities are unreliable? Where's your support? Notice many commercial Unixes (not "Unices"... Unicos is Cray's OS) are moving to GNU utilities? Ugh... this complaint is so unsubstantiated I can't even level a structured retort!
You're off your rocker. Linux boxes have to be admin'ed ONCE in a big way, then they just keep working after that. You've mistaken it for NT, which BREAKS constantly and requires constant attention. I have a Linux server sitting in my closet that I haven't touched for months. It just works and gets heavy use. Not to mention that when used properly, *nix solutions have a constant maintenance cost, while NT solutions require growing fees. What do I mean? With *nix, you have one central box that needs adminning, and all your clients get their apps, configuration, and data from that box. So, if you have N machines, you have 1 box to admin. With NT, every seat has to have its own apps, data, and configuration. You multiply your work load by a factor of N. So, if it costs C dollars to admin one machine, NT costs C*N, while properly implimented *nix solutions are C.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
More nonsense. ext2 will lose data if the data isn't written to the disk when a failure occurrs. So will UFS. But you won't experience corruption of data you're not working with otherwise. ext2 is stable and solid. It gets corrupted if you fuck with it. Same goes for every other fs.
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
ReiserFS isn't in beta. It's sufficiently stable and is used by lots of people on production machines.
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Uh, no. Backwards compatability is good if the older stuff is still used. Also, the backwards compatability in ext3 does not break its implimentation. DOS is dead and burried. There was no reason to keep support for it lying around, but MS did anyway and it was responsible for a LOT of the instability in Windows 9x/2000. People still using DOS stuff, should not be upgrading. Microsoft just forces them to. Not only that, ext[123] was designed to be EXTENSIBLE, something Microsoft idiots don't seem to understand. Extensiblility is about being able to add future functionality without rewriting or breaking a package. Hooks exist in ext that let you add new features. This is a Good Thing.
Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
I'd like to see some statistics. This claim is unsubstantiated. I've seen Solaris boxses drop like flies. However, most Linux boxen I've ever used have been VERY stable and once everythings up and running, it flies smooth for months even years at a time. If "Linux" crashes (what you think is Linux crashing, is actually XFree86 or Mozilla), it's usually recoverable. Don't confuse your lack of knowledge with Linux being unstable.
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
This is pathetic. Linux makes things at the system level easier for most users to understand. You're saying that, say,
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.
You're right. Windows is much more stable and reliable. Oh yeah, and Solaris is much cheaper and secure. Forget free software. It sucks. I mean, it's worthless, because it's free, right? I mean, why would it be free if it was good? Anything that's good is worth paying millions for.
You're so hopelessly confused that I can't tell if you're a Windows luser/wadmin or a pro-BSD zealot that doesn't even use BSD but read about the fights between the two camps. Maybe I'm juts feeding a troll here, but I gotta battle the FUD.
Why bother.
I know Linux prides itself on beeing rich on choices, but could it be that the problem here are all the choices/alternatives? The choices soon become overwhelming, and people start to eliminate some of the choices, to relax the mind.
The distro companies might aswell make their choices of what they think's practical and what's not. You can still patch your kernel to support whatever FS you think you deserve, it's just not as convenient for you. As it is also not so convenient for the distros to include all the FS'es the community has to offer. Nor all the applications that are developed.
Strange as it might seem, it's quite normal.
The problem is that writers starve readers on ReiserFS. When writing a lot of data (for example, copying an MP3 album or a movie), no processes will be able to read from that filesystem. It's a known problem in the ReiserFS FAQ, but they really downplay it's severity. If you regularly work with large files, or copy large groups of files (more than ~50MB), stay away from ReiserFS.
How do you convert an ext2 partition to reiserfs anyways? The best method I could come up was using a spare partition somewhere else: copy data over to spare partition, mkreiserfs the original, and then copy it back. Obviously, this doesn't work if you don't have any spare disk space lying around. So, is there somewhere a utility to do the conversion "in place"? How safe is it (i.e. what happens if there is a power failure right in the middle of it?)
Say no to software patents.
On your system, fsck will still be run on bootup, to repair an uncleanly-unmounted ext3 partition. Of course, all it will do is to replay the journal.
Isn't that what development kernel (2.3.x, 2.5.x) should be for?
Say no to software patents.
There are filesystems designed for beowulfs, like PVFS, which let you take the hard drives in a bunch of computers and merge them into one big filesystem. But ext3 has nothing to do with this.
ext3 works fine for me... so far... only 2 gigs of data though...
:)
If you run tunefs -enable on xBSD you get pretty much that. My webserver looses power all of the time (15 minute UPS) and it has never lost anything. It runs OpenBSD with FFS/Softupdates.
fscks take about 4 seconds (50Mhz MicroSparc)
XFS comes with SGI's kernel debugger. Linus doesn't want a kernel debugger in the official tree, as he says here.
FreeBSD doesn't need a journaling file system: FreeBSD has softupdates, which ensure that the filesystem metadata is always in a consistent state while providing better performance than journaling.
Tarsnap: Online backups for the truly paranoid
It's like what's worse, dealing with a fscks that seems to take hours or increasing the risks of more crashes but at least you get back up faster. I can't live without quotas either. Can you imagine a student in a lab with a 10 Mbps connection to the Internet and a few hundred gigabytes of writable space? :)
It's starting to look like I can't have my cake and eat it too. :(
I'm glad Linus is blessing it. Hopefully the issues will be resolved soon. Until then, maybe redhat jumped the gun including it in their distro...
...nor did I hear an explanation of how this wound up in a 2.4.* kernel instead of 2.5.*, where right now it really belongs, even though AFAICT it's dead stable.
Got time? Spend some of it coding or testing
The only time I've ever seen it upset was when someone ran zgv at the same time as XFree86v4.1 (on a CyberBlade-based mobo video) and caused a hardware insanity then lockup while they were writing config back to /etc... ugh...
Got time? Spend some of it coding or testing
I think the kernel developers are getting careless. One of my systems (plain Epox MVP3C mobo, AMD K6-2 500, 196 RAM, 1 3.5 gig Fujitsu hdd, 1 4.3 gig Fujitsu hdd and Matrox G200-8 Meg), has never crashed so much than since I've started using kernel 2.4.x Really, just out of the blue with no logs to even show why...drives me insane. Yeah, I suppose I could read up on kernel debugging and get some sort of log... but should I have to?
.13 and .14, with only scsi cdrom and scsi generic support -- and don't compile in a scsi controller (because ide scsi emu doesn't need one) - and yes this means turning off the one that's set to compile as a module by default, the kernel dies during compile with the following message
.14 you can't have a loopback device. - Yes, I know they fixed that in .15pre1 - But, that alone deserves an immediate full stable kernel release (IMHO).
Anyway, if you compile scsi emulation in the past two kernels
#error "Config.in must define either CONFIG_53C700_IO_MAPPED or CONFIG_53C700_MEM_MAPPED to use t
his scsi core."
Now, if you go back and recompile your kernel and build that controller in, then your fine.... but that's just a waste in your runtime kernel. Unless I'm missing something here?
And let's not forget how in
I don't plan on having my servers depend on such a huge addition to the kernel, that's just been thrown into a so called stable tree in the middle of the game.
-- Wondering what comes next. I love linux, but hate that it crashes more than ever.....maybe switch back to 2.2? - That's progress.....
Cryptnotic
My other first post is car post.
With Linux i can do that within half an hour, cause i know how and what to install, the copying of the total files takes less then 10 minutes, and once its booted i need to config X a bit and the soundcard and it time to play mp3's and watch movies, when your still busy detecting hardware and rebooting when installing your video drivers with your expensive OS. Its just another reboot, and reboots take time, when installing Linux i dont have to reboot at all thanks to SuSe, But the difrence is it took me pretty long before i knew howto install my OS fast and howto use it, the other OS was easy to learn and very hard to master, cause i couldnt know if the software crashed or if it was a hardware problem, my OS was Hard to learn, easy to master and nowadays i know my hardware is oke, uase when its not my software crashes then i fix it and i have a very stable running machine, but paying again for software never, i'd rather code it my self.
;P
blabla, i wonder why i even responded to this reply, but i somethimes just have to rant a bit
Quazion.
Well, guaranteeing metadata integrity isn't the same as keeping a log so fsck know's where to look for problems.
:)
What I want to know is why some system's don't take the Amiga approach - SFS and PFS both do a very good job of remaining consitant at all times, even if you pull the plug in the middle of a write, but neither journal, and neither need anything like fsck (except when they fall over, which I guess is more down to poor testing than anything).
There's a user space fs driver for Linux somewhere - you can write filesystem backends in Perl if you like. Be interesting to see what sort of experiments people can do with that
Unfortunately, if your file system tools aren't upto date, your root partition won't be mounted ext3. A quick check to see if everything worked is to look at the output from either df or /proc/mounts like this;
In the second column, it should report the filesystem type of each mounted partition. If you don't see / , you should upgrade fileutils.
This is basically how your fstab is currently interpreted, as recorded in /etc/mtab.
If either of these look wrong, check the kernel sources for Documentation/Changes, and verify that you are using the supporting program versions mentioned in the Current Minimal Requirements section.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Ah, but I've found that it's only if you enable agpgart with it... some form of conflict between NVdriver and the kernels agp drivers. With agpgart disabled q3 runs solidly as a rock...
At the time Linus was staunchly against integrating video support into the kernel as a general device driver, even though an ongoing project called GGI (General Graphics Interface) had written a proof of concept video kernel module, supporting libraries, and an X server. Their system prevented these kinds of crashes by providing an abstraction API layer for applications to access the video hardware through the kernel, just as DRI does today, instead of having individual applications responsible for writing to the hardware directly. The argument then was that no userspace application should write directly to hardware considering the potential for race conditions, security problems, etc. And since all other hardware has an API layer through to the kernel, why not video?
This concept won out, but not the GGI project. Which is too bad because they had a good idea and a working system back in '96. I'm sure there were some politics involved, maybe a project lead at GGI pissed Linus off or something. I wasn't paying enough attention at the time.
Just a note about this in comparison with NT: the idea is to abstract out video acceleration routines into a hardware independent API for programmers. In NT 4.0 (which was current at the time), Microsoft placed not a video hardware acceleration API into kernel space, but much of GDI (their windowing system API). Many people thought this was unnecessary kernel bloat and complained vociferously about it being a prime cause of NT 4.0's instability. I'm not an NT programmer, nor do I know much about it's internals, so if anyone wishes to chime up and offer a better explanation please feel free.
One last point: now that DRI provides a direct kernel interface to video hardware, it's quite possible to take down an entire system with an errant DRI kernel module. Yup -- exactly the same kind of problem that linux advocates used to sneer at NT users over. The NVIDEA GForce proprietary DRI kernel modules are a prime example of problem drivers crashing people's systems. Ironic, huh?
Cheers,
--Maynard
Good luck getting your AFS cache to work reliably under Reiserfs. Though it looks like AFS will work OK with ext3. I've been having a hell of a time getting it to work with 2.4.9-13 (the latest RH distibution kernel) though. You're right about OpenAFS kernel modules not being ready for prime time under linux. Unmounting on shutdown often causes a kernel oops, unloading the AFS kernel module on a running system usually causes a system crash requiring a hardware reset... ugly ugly ugly. Unfortunately, find me a better network filesystem.--M
I've not been running it for too long but so far Ext3 is goodness. I more often have problems with my laptop needing a good hard reset (it was one of the toshiba lawsuit ones...not linux's fault) and let me tell you its nice when the filesystem is fixed on reboot in under a second rather then minutes.
I'm not sure if its real or imagined but eet also seems faster.
ext3=goodness. BTW I converted an ext2 partition on one of my machines so its safe (or rather RH72 did it)
Nvidia's drivers aren't DRI. They use their own approach, and have a much larger kernel driver.
Yeah, you're right. Whoops. Thanks for the fact check. --M
I have a tiny box at my home that I use as a router. It's a couple years old now. The box itself is a P100 with all the guts inside loose and hanging all over the place. The HD is > 5 years old and is loud and very unstable, simply doesn't turn on sometimes.
This little machine stays up 24x7 and only goes down when the power goes out, which is at least once a week here. After a power failure, the drive usually doesn't turn back on until the machine is power cycled and sometimes the whole machine will not turn on... and sometimes requires a light smack ; )
Even though this little box is a piece of dying crud, after it powers up properly it fscks and boots linux in about 1 minute and works every time. It has NEVER failed to boot after powering up properly after years of constant use. This Linux install is years old, running an older 2.2 kernel and has required absolutely 0 maintenance, other than smacking the machine to get it to power on ; )
At work we have... haven't counted in a while... say 20 odd machines. About half of them are servers running Linux and 1 BSD box, which do not require any routine maintenance. The other half are running W2k and require constant maintenance. Even if Windows was free, for our small company the TCO would STILL probably be about 3 times that of Linux or BSD. It is simply unacceptable how much time and energy we've had to put into fixing NT and W2k boxes.
Of course, no matter what anyone here says, there will still be people who adamantly claim that NT/2k/XP require less maintenance and have a lower TCO than Linux/BSD and many will claim that the ease of use of windows is extremely important. That is simply false, as if one isn't skilled enough to setup a Linux/BSD box, they're going to be one of the people who's boxes get infected with all the "microsoft worms" that spread around...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Good, it's not just me with an nVidia card and occasional X lockups then...
Another strategy is to set up getty on your serial port, then when it crashes, plug another computer into your serial port (my old Psion 3c palmtop works wonderfully for this since it has a 56k serial port, and a simple terminal emulator in ROM), log in and either chvt to a normal console (e.g. chvt 1) or just start running ps and kill from the palmtop. Last time this happened I managed to recover without leaving X by killing the X client I was running at the time (FSV).
Critically, because X is nothing to do with the kernel (Microsoft please note, this is a good idea), the instances of getty, bash, ps, grep and kill running on the serial port still all work fine.
I have installed ext3 on my debian unstable box, using 2.4.13-ac7, and I disabled the fscking of the file system (tune2fs -i 0 -c 0). I wonder.. does it replay journals automatically when I reboot after a crash? Or do I have to do this by hand? Up to now, no problems, but I do get the feeling that reiserfs is slightly faster. I use reiser on my laptop, since the battery lfe of my sony vaio is only 50 minutes, so I can shut it down in a brutal way if nessecary..
Are there any disk array controllers or other storage devices that do FS-independant journaling at the block level?
It'd be an interesting way of doing backups -- instead of restoring from tape, you could get the disk controller to back out changes to a specific timestamp.
I'm sure there are some gotchas -- without knowledge of the filesystem, a specific hardware level transaction may not have complete filesystem level coherency, for one. And it may take a lot of disk to keep a log of any decent duration.
But it still seems like an interesting way to accomplish some kind of fault tolerance for any OS.
When I first switched to Reiser I had this habit of just turning off the power to my box every few minutes just because I could. No good could come from this. Hopefully as more people switch to journaling FS they will have more self control than I had. Anybody else do the same thing? It is so addictive! Must resist turning off box after I post this...
A JFS doesn't protect your data, it simply allows you to reboot faster after a crash.
I'm a bit confused here, could someone give me an answer...
I thought that Alan was the maintainer of the ext3 patches. Who is Andrew Morton?
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
I don't judge a filesystem based on what kind of tools are there to 'convert' it from something else. That's not what it's designed for, and has nothing to do with what you get out of it.
No kidding ext2 takes seconds to convert to ext3... it's the same filesystem.
ReiserFS was merged in 2.4.1... Nice troll.
How to contact me - http://www.pervalidus.net/contact.html
I believe Linus has learned to be a little more realistic with releases. While publicly he states that he doesn't care a hoot about what any polls, groups, or the press want or think, and is only interested in building the best dang kernel, my guess is that he desires to see Linux really catch on in the corporate world (and I'm talking linux vs other unix - not displacing MS.)
The corporate world really wants to see business features in the production kernel such as a rock solid good performing VM, a journaling file system, etc. The older kernels' VM and lack of journalling were really singled out as being critical hurdles for corporate acceptance.
It didn't matter that RedHat had ext3 or ReiserFS, it was needed in the base kernel without messing around with patches. It's more of a mindset / perception thing than reality.
The fact is, the corporate world wasn't going to wait another 2 years for 2.6. Those features really needed to be mainstream now. The only thing I'd really like to see added are extended ACLs, but that can wait. I don't know if a solution to device numbering can if Linus won't assign new numbers... (Alan will however, in his tree...)
Thanks Linus! And a big thanks to all the hundreds of other kernel hackers that made this all possible!
Now Slashdot is posting pre versions of the kernel.
2.4.15pre2 is out!!!
I was getting worried what would happen with alan not looking after 2.4.x once 2.5.x started... I've been running -ac kernels mainly to get the ext3 support (I've had no luck with reiserfs... I don't trust it any more - no machine I've ever used it on has survived more than a month).
On one machine I had a scary moment when I had to drop to a linus kernel since the latest -ac seemed to have a crashing bug in it. ext2/3 worked as advertised (I didn't even have to change fstab) & everything just worked as ext2.
Why should we explain it when this and this do it so much better? Are you trolling, or can you educate yourself?
FreeBSD - the power to serve.
Why not go for a journaling solution that a) innovates in filesystem design, with large increases in speed already and advanced database-like features in the pipeline and b) has been in the kernel for months.
Ext3 is just a patch to Ext2 - it's not the future.
- Hypnos
Actually, I've found that putting ext3 (in /etc/fstab) with no ext3 support will automagically mount as ext2. I've also heard that having something like ext3,ext2 will work, but I've never tried it.
/dev/blah and look for the has_journal flag in the Filesystem features field.
Oh, and to check if you have ext3 you can also use tune2fs -l
For your root filesystem, you may also see something like VFS: Mounted root (ext3 filesystem).
Andrew.
I might be wrong, but wasn't IQ defined as the worldwide median? If so, you should remap the IQ fields in all rows after that.
Afterwards the whole operation should be carried out again.
And again. And again.
In the end, only one human begin would be left, with an iq = 100. And that's because the condition is iq < 100. If you would use iq <= 100, no one would survive. Hey, perhaps that's what killed the dinosaurs?
This sig under construction. Please check back later.
You've completely missed my point regarding the set example. If YOU are only using features 0 through N, and not caring one bit about N+x where x > 0, then the addition of those features doesn't affect you. Adding ext3 support is not only minor, it also does not affect you if you choose not to use it. If you don't think ext3 is stable, just don't compile it when you build your next kernel. Simple! You go back to the original set. There's nothing wrong with adding new drivers to stable kernels. It's been done constantly and it's necessary for Linux or ANY operating system to survive.
Why bother.
Talking of stability, remember that ReiserFS spent a whole year in SuSE and half an year in Mandrake before being inserted into the official kernel.
I'm using ReiserFS from the first 2.4.1 and quite happy with it. I'm still glad to see other alternatives added, though, and from what I've read Phase Tree is the most interesting thing yet to come but obviously still in an early stage.
But it changes the set. The fact that it doesn't change 0 to N is irrevelant. In set theory, once you add that N+1 element, the set's identity has changed. Once it's identity changes, as far as you should be concerned, it's a new set unless you want to prune the set for each operation.
What you're talking about has zero revelance to programming. Have you ever programmed a huge system? You might have existing hooks in the system but the fact is, when you add new code, shit happens. That's the fact of life. Taking advantage of new hooks adds new states to your program. For a utter garauntee that the system is stable, you'll have to traverse each state and each path in the system. That is not realistic.
A better advice would be, don't switch to the new kernel until there have been real life evidence that the system works. Btw, you're right, we need to add new stuff to the kernel. We need to keep the kernel as up to date as possible. But when you release a stable kernel, the only thing you do to it is add bug fixes. You DO NOT rewrite huge sections of it. Because when you do, the program states have changed and you're testing from ground zero. (Adding bug fixes usually shouldn't change program states. It just fixes problems with the states or state path traversal.)
Me.
Have some respect and s
Your idea about a different versioning scheme makes a lot of sense; however, I think there might be a better solution than what you suggested, since you would have to set a "cut-off" point for each major kernel version to ensure that one was maintaince only, and another was features. My suggestion would be to do what SGI does, and have a "maintaince" and a "feature" stream. This is what SGI does with IRIX, and it works unbelievably well for them. Linus could then release two version of each official kernel, one that had only _fixes_, and another that added actual features. Seperating fixes and features could be a potential problem, but not nearly as large as choosing a kernel now that contains only fixes. :-) Any comments? (Sorry about my sig . . . /. is the first site where it doesn't work well!)
Years of real-world experience.
Of course, it wasn't contributed by the Linux illumninati, so it'll be dismissed and excluded as if it were contributed by Microsoft.
Petty bullshit and ego-based politics have arrived in Open Source.
Otherwise updatedb will ignore your "auto" filesystems (i.e., your whole system) and the slocate database will be empty.
XFS a "special-purpose" file system? I think not . . . it handles all size files just fine, though it handles larger ones better than it does smaller ones; Reiser is just the opposite of this. If this is what you think, then you should consider Reiser a "special-purpose" file system. IMHO, XFS is the _best_ FS out there for Linux today; it's solid as a rock, it's compatible with all standard UNIX features (Reiser/NFS? Don't even think about it without patches), and it just plain works! No problems, no worries with XFS. Just my opinion . . .
Well, ext3 is very easy to test out, and it will soon get a large Userbase. More users means it's getting more attention, which in turn means more development. The different journaling filesystems are not too different from each other considering performance (and that's what most people are concerned with), a while ago reiser was the best performer AFAIR, but with more development going into ext3 that might soon change. I think it makes sense to put your bets on the Filesystem where you expect the most development to happen.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Red Hat 7.2's release notes on ext3:
Please keep in mind that even a journaling file system can be damaged by power loss. When a system loses power, that system's behavior is
undefined. For example, memory contents can decay (become randomly corrupt) as the contents are copied to a hard drive running on the
last bit of power. This is a fundamentally different situation from the more defined sequence of events caused by pressing the system's "reset" button while the system is running. In addition, IDE hard drives do not provide all of the write order guarantees that SCSI drives do.
In the case of ext3, I actually agree with what is otherwise the greatest example of weasel-wording since the Evangelists excusing everything Apple does.
ext2 does not synchronously write metadata -- a power fail can hose everything. Thus I consider ext3 a bugfix on ext2, albeit a somewhat radical one. Same goes for the AA VM, a radical bugfix on a broken VM that should have been a show-stopper for 2.4 in the first place.
Otherwise, you're pretty much the kind of support Linux frankly doesn't need. Keep giving people attitude, soon enough you won't have to anymore, because they'll turn elsewhere.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I just set options maestro dsps_order=2 in my modules.conf and I can open and write to /dev/dsp 4 times, simultaneously, in stereo.
Black holes are where the Matrix raised SIGFPE
-Legion
EVERYONE knows the NTFS is the best filesystem ever created. All these other filesystems toys compared to NTFS. Microsoft makes it after all, and everyone knows that Microsoft makes the best stuff. If they didn't they wouldn't be such a big rich company and able to buy off the govnerment now would they? I'm going to stop using Linux before I get in trouble. I know what's good for me, I don't want to have to explain to the computer police why I was running a subversive terrorist operating system. I'm not one of those evil hackers that try to take money away from Darth Gates, dark lord of the Sith.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Do you know some recent benchmarks between the FreeBSD filesystem with softupdates and Linux with ReiserFS or XFS or Ext3FS?
Or are you just making up the "better performance than journaling" ?
Such rather strong assertion needs proofs, not just theoretical justifications..
It's not true.
If you have only SCSI disks, it may be true, if your disks are from a very reputable manufacturer. (They are few, and charge more.)
If you have IDE disks, it is almost certainly false. IDE disks report data successfully written to disk when it is still only in on-board RAM buffers. Even when told not to, they often do it anyway. (Lying results in better benchmark scores.)
If you have IDE disks, journaling will help protect you against various lockups and crashes, but if the disk is active when the power goes out, all bets are off. If you think you didn't lose data, maybe you got lucky, or maybe you just haven't noticed your losses yet.
The reason IDE disks are cheaper than SCSI is that the people who buy IDE disks have much, much lower quality standards. To compete, the manufacturers are forced to deliver lower quality. If you care about reliability, buy SCSI (or fiber-channel, or ...).
If you use IDE, watch that power switch, and keep current backups. If you maintain critical data, invest in a UPS. Journaling is not a substitute for a UPS, it's just a time saver.
I'm not that informed about EXT3, but if the ACL support is there ... then ill switch fs...!
Anyone who knows when ACL will make it inte the kernel?
There is no way to say i'm sorry to a dead computer Luser:-forgive me, i was wrong. Ladmin:-Please boot up, Luser didn
Ext3 has three journal modes (available with the data=mode option on mount or in /etc/fstab):
Writeback: Don't care about ordering, just write in whatever order is most convenient. Possibly fastest for some loads... (This is basically the same level of journaling guarantees that you get from ReiserFS)
Ordered(default): Write out data before filesystem accounting information. (will protect all data modifications except for writing to the middle of the file - this is rare in most situations)
journal: Write all data to journal first (Guarantees all completed writes will be recoverable, including writes to the middle of files. This mode can be fastest with random writing because they all go directly to the journal - more effective write clustering...)
That said, ext3 does it's best to protect the data. Also, no JFS will protect you from hardware failure, use at least RAID 1 for that....
There: Something at a specific location.
Their: Owned by someone.
Please make sure your english compiles.
Then OS X is a drasticly overdue bug fix for MacOS 8 and WindowsXP is a bugfix for win3.11, or how about dos?
Oh, boy... Where to begin...
First of all, the soonest the preempt patch would be merged, if at all would be in 2.5, and it is still in development. It only supports x86/32 and ARM so far...
"The thing about the preemptible kernel is that it is only for uniprocessor - SMP kernels aren't preemptible. "
This has been fixed over a month ago. UP and SMP kernels are now both preempt safe. So is a highmem (more than 2GB of ram) kernel.
"So unless you want the SMP case to be capable of tying up a processor for "too long" at a time, then you need to re-do each bit of code which is capable of long latencies anyway."
There are some small parts of the kernel that have been marked "not preempt safe". Fortunately, there aren't too many of them, and they're planned to be fixed in 2.5.
"The other thing which came up is that responsiveness of the system improved quite a bit recently with VM fixes (2.4.14 was the improved version, I think)."
Actually, the new VM was put in in 2.4.10pre11.
"It was a matter of the VM queueing up too much I/O (and the drivers trying to throttle it, instead of just throttling it all in the VM - or something like that)"
Actually that was one of the outward signs... The kernel favored the page cache over most anything else, and it grew particalarly large. That was since fixed, which allowed other problems to be noticed... The main problem was the swapping code. It would choose the wrong things to swap out, take too long to do so, and basically do bad things. Also there were some races in there that would cause kswapd to use 100% of the CPU (or just one cpu if you have SMP).
"The preemptible kernel won't solve that kind of problem"
Wow! The first thing that was 100% correct! Congratulations.
There: Something at a specific location.
Their: Owned by someone.
Please make sure your english compiles.
Yeah, been there, done that. I`ve had same experience with reiserfs and various kernels, but right now Im considering the interactive performance probs to be vm problems really. I havent really tried to test this, though. What does everybody else think?
Journaling is a guarantee that the filesystem is *always* consistent on disk (as long as the filesystem code itself is bugfree and similar disclaimers etc etc).
softupdates is a fairly reliable approximation that uses carefully ordered writes to keep the disk mostly consistent.
*laught* As usual, I have no mod points.
-- MarkusQ
Let's have a close look at the costs involved when running a Linux system.
Ok, lets have a look...
First off a Linux Install is done in a quarter of the time.
Second All the servers that you may need (with the possible exception of a Exchange Server Replacment) are available for free.
Third backing up does not require that you buy a £300 backup Manager.
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance,
A Lot? Where did you get this from? We have several Windows NT/2K servers and they are constantly requiring Maintenance.
Our exchange server had software RAID setup (an oversight from the company we got it from) and suddenly decided that it would spend 88% of both 900MHz CPUs using the disks...
This then cause exchange to die taking the message store with it... 2 days later, with the disks un-RAIDed, re-RAIDed, exchange repaired (only just by the tools supplied) it was running again, but no one knows what caused the computer that had run OK for the 3 months to suddenly die, or what it was that fixed it.
This is the way of microsoft software.
In the same time we got a new hard disk, downloaded Linux (3 CDs), installed, secured, setup accounts, and had a replacment Mail server with LDAP addressbook going with a day to spare...
work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
Well all I can say to this is that you either don't know Linux, or are a Windows admin who has tried and failed to learn how to Admin Linux and is bitter about this.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly.
Windows is no better. Most filesystems are no better. NTFS (Or NT's Fragmented System) just doesn't complain. It's worse if the MFT gets even slightly hurt...
Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
Well If you don't think what Linux has is stably enough for you, port the filesystem over and stop complaining...
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
Others have covered this.
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS,
I, for one, would like to know hat these drawbacks are. My ext2 systems have never failed apart from a hard disk head crash that destroyed a disk and a power surge that also killed a disk.
Funnily enough other opperating systems on thoses disks did not survive either...
for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Staying with a technology that was old (FAT) and had so many faults (No good disk management, defragmentation, checking, it didn't even notice that it had not been finished writing data when the power was pulled).
Back to Linux' cost.
Hang on I thought this was all about Linux' cost...
Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
Again no information to back this up. Yes I've crashed Linux. I was running a Kernel I'd hacked up myself. Yes I've crashed X. Keyboard did not respond, mouse died...
I tellneted in from another box and killed X and it all came back.
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost.
Ah so you're a Windows Admin, that does not understand the way of Unix
The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification.
Oh dear, Lost of software is badly coded, not just Linux (OR GNU as it should be called) software. If you dislike it that much you could always rewrite it...
What specification does the other software use?
Their own, to make their software 100% compliant because the specification is one the invented to match the product...
Linux software does not mangle data.
Why?
Because if it did it would be fixed within a few hours and you could download it.
On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
Go on Name the software that does this.
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.
The conclusion that we draw is that,
1, You don't know what you're talking about
2, You have nothing to back up these wild claims
3, You Are a troll
I hear this time and time again.. it's only X that crashed! Everything else works fine...
And while this is true most of the time and I can telnet or ssh into my computer and kill X, that's not always the case and sometimes no port will respond at all... thus leading me to believe that the entire system went down.
Use the Z-modem protocol between Information Superhighway routers to compress the plaintext. ~LordOfYourPants