Ext3 Filesystem Explained

sheckard writes: "The next installment of the wonderful Advanced filesystem implementor's guide, part 7, details the ext3 filesystem in all of its glory. This is another great voyage into the world of journaling filesystems, and ext3 has been rock-solid in my experience."

Comments

wow

[Fillup]

Journaling file systems / ext3 -- is this the best? Or should we be looking in another direction entirely?

Re:wow

[be-fan]

Actually, the best filesystem on Linux right now for most uses is probably XFS. Its a little slow on deletes, and not as fast as Reiser for extremely small files, but from the stuff I've done with both (compiling, tar/untar, moving around directories, general workstation stuff) XFS is just as fast as Reiser for normal sized files, and much faster for large files. JFS is the dark horse here, though. I've seen some benchmarks showing it to have as good large file performance as XFS, but much better metadata (creating, deleting, growing, etc) performance. But there's not much info on it yet, and its not rock solid entirely.

Distro battles? Nah. Journaling fs battles!

[Deal-a-Neil]

ext3 catches my fancy because there's no ext2 --> ext3 conversion -- you just have to unmount, make a journal file, and remount. reiserfs migration is a challenge for the huge partitions.

ext3

[FeeDBaCK]

One thing I would have to agree on in the usage of ext3 is the fact that the machine can be booted with a kernel that does not understand ext3 (only ext2) and the filesystem can still be read. This is a major strong-point in my book.

Re:My semi-Weekly Drunken Comment...

[91degrees]

It isn't inherently better. It does have benefits of being more customisable, and a non-windows policy means you have a little choice, rather than piling more money into the pockets of a company as disreputable as MS.

Re:Distro battles? Nah. Journaling fs battles!

[ThatComputerGuy]

And because there's only a journal as an addition, you can remount as ext2 after a clean unmount and everything will still work fine.

Re:Of course its been solid

[Deal-a-Neil]

Power supply dies. Power goes out and UPS dies after 30 minutes. Playing shuffle-the-cables at the co-lo facility and you mistakingly unplug the NAS unit. There are still a few non-Microsoft OS related catastrophes that exist, believe it or not. By the way, that last scenario was completely hypothetical. [whistling/twiddling thumbs]

Re:Distro battles? Nah. Journaling fs battles!

[FeeDBaCK]

Actually... You don't even have to unmount to create the journal... just to actually *use* the journaling.

Re:Distro battles? Nah. Journaling fs battles!

[Andreas(R)]

"ext3 catches my fancy because there's no ext2 --> ext3 conversion "

In addition, you can actually read ext3 from a kernel then only supports ext2. Only catch is that the partition has to be cleanly unmounted for this to work. This is a "Really Good Thing (TM)", because then you can to boot from an old bootdisk and still access your files, or if you are running multiple distributions.

how to convert to ext3?

[nusuth]

On my new machine I installed linux as my primary os, expecting soon get tired of it (again) and reconfigure a dual boot system windows as my primary OS. While installing linux, I didn't think much(since I would soon be destroying the partition anyway) and installed the system on reiserfs. To my surprise that didn't happen and unreliability of reiserfs started to bother me more and more. And with this article I'm convinced that ext3 is what I want. Now, how do I convert from ReiserFS to ext3? I have plent of empty space on a soon to be destroyed ntfs partition and a cd writer, so backing up existing data is no problem, but simply copying back files will not do the trick, right?

Going for a informative point here

[t0qer]

I know RH7.2 has Ext3 support. Right from the setup you too, very sweet.

Re:Distro battles? Nah. Journaling fs battles!

[mindas]

Anyone knows is there a working ext3 patch for 2.2.20? Because ext3 home for 2.2's (ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/) doesn't seems to be updated since June.

In the Linus Kernel yet?

[redcliffe]

Is EXT3 in Linus' tree yet? Other thing I'm wondering is if it's worth moving to the Alan Cox tree to get it?

Re:In the Linus Kernel yet?

[Anonymous Coward]

2.4.15 should have it.

Re:In the Linus Kernel yet?

[Anonymous Coward]

Linus' 2.4.14 already has it.

Re:In the Linus Kernel yet?

[jrockway]

no, it doesn't. you still have to patch. EXT3 is introduced in 2.2.15pre2

Re:In the Linus Kernel yet?

[psamuels]

EXT3 is introduced in 2.2.15pre2

Actually 2.4.15pre2 - big difference. So yes, it's in Linus's tree, just not in a "released" kernel yet. (Wait a few more days.)

Re:My semi-Weekly Drunken Comment...

[TheMidget]

Hey, if Best Buy sells you hardware that's broken, just take it back to the store, and get it exchanged or refunded. Easy, isn't it? And if they won't stand up for their products, well, then you know where you won't be shopping the next time around.

Performance

[raahul_da_man]

Ext3 is quite nice, I've moved to it myself
because the root partition until recently
had to be ext2. I still can't help feeling
that ext3 is slower though compared to Reiser.

Anyone else got comments on performance?

Re:Performance

[Anonymous Coward]

I've had an ext3 root partition for over a year - it needed a reboot to change root to ext3 in those days, though. All other partitions were done with a remount.

Now, any ext2 fs can be turned into ext3 by a single tune2fs command, with no remount and no reboot.

I'm sure you could come up with several benchmarks which show reiserfs to be faster than ext2/ext3/xfs/whatever, but for most desktops and servers, filesystem performance is not a factor to be overly concerned about - unless you choose something silly like umsdos or NFS over PPP. News servers and high load fileservers are a different matter of course.

Re:Performance

[Dictator For Life]

I'm sitting at a humble (K6-2 450MHz, 128MB RAM, 8GB HD) box that ran for 230 days on RH7, and I never noticed speed issues with it...until installing RH 7.2 with ext3.

The box is definitelyslower doing disk access now. It's a little disappointing, but I'm not really concerned: I'd rather have the protection of the journaling and I'm willing to pay with a little speed tradeoff. Eventually I'll get a bigger/newer/faster HD for this thing, and that will probably help as well.

My perceptions may be skewed; my main box for the last year has been a PIII-750MHz with a 30GB drive, and that bad boy sings, so it may be that I just don't remember precisely what performance is "supposed" to be like on this one.

Re:Performance

[rodgerd]

IIRC RH7.2 installs ext3 with both data and metadata logging enabled by default, so your performance change is most likely that you're doing two writes for every one you did before.

Re:Performance

[msaavedra]

Actually, RH 7.2 uses the "data=ordered" mode, not the "data=journal" mode. The data is not stored in the journal, but it is written before to changes in the metadata are written (according to the article, that is). This should guarantee data consistency, and is faster than full data and metadata journaling, but still gives a minor performance hit.

FWIW, I have tried both reiserfs and ext3fs on the same system, and haven't noticed a significant speed difference. Both seemed to work well for me.

Re:Performance

[raahul_da_man]

Ever try compiling the kernel? Reiserfs is noticeably faster than ext3 for that task.

Good Teckie Post

[Newt-dog]

Well another great post that went over my head! :-)

Although I did enjoy the paragraph on filesystem journaling -- After pulling my one of my [gasp] Win2000 servers offline the other night to do a defrag, I could appreciate the fact that a developer could tweak Ext3 to do some neat things. (ahh, for linux, at least) Like when I save and resave files on a test server, the journaling approach could be made more efficient by only saving the changed data! (not the whole freakin fragmented file)

Now the question could be -- Is there someone who will step up to the plate and produce several custom filesystems. The article points out that there is no "best" file system, but given the options, I'm sure the teckie endusers could tweak settings to meet their needs, be it server or desktop.

Newt-dog

Re:Good Teckie Post

[Newt-dog]

In fact I prefaced my comments by saying that the article went over my head should have given you a clue that I was an idiot in this specialized area. But I did see a potential in certain areas that I could relate to. I just merely pointed them out, and *I* posted my nic to it.

Newt-dog

Re:Good Teckie Post

[Newt-dog]

SlashDot Login? Yea, after a few years of off-and-on reading, I finally got one. :-) Myself, I just finished plowing through two 1,000 page books on Exchange 2000 and Active Directory and still don't know a thing about it! Leave it to MS to make something so complicated that you need to read the book(s) just to get it installed and working! Pity. Newt-dog

ext3 vs xfs

[Anonymous Coward]

I've tried both, but when I played with XFS it took forever to rm -rf a 2 GB directory. Was it me, or is XFS extremely slow with removing lots of files? If so, is this because if takes forever to update the journal?

Re:ext3 vs xfs

[be-fan]

XFS historically has very bad delete performance. I don't think its the fault of the journal, since other things involving the journal (growing or creating files) aren't slow (though, ReiserFS does seem to have the best journaling code). I don't know what the official take on this is, but here's my theory. Most filesystems use a bitmap to keep track of free blocks. XFS, on the other hand, uses a pair of B+ trees to mange extents of free areas. This allows it to find better (more contiguous) blocks more quickly when an allocation has to be done. A bitmap, on the other hand, has to do a scan through the bits and can't afford to spend a lot of time looking in different places for the "best" place to allocate. However, when deleting a file, the bitmap approach already has all the addresses of the blocks, so its just a matter of clearing some bits. XFS, on the other hand, has to go ahead an reinsert the blocks back into the B+ tree, which takes many more disk access and much more time. Normally, this is an okay tradeoff, since you usually grow files more often than you delete (ie. you grow it many times while writing it out to 2GB, but delete the thing in one go). On systems like Squid server, on the other hand, you create and delete files like mad, so Reiser is often faster in that case.

Re:ext3 vs xfs

[WNight]

Sounds like they might benefit from the optimization of not putting newly freed blocks back into the main B+ trees until it's got some dead time...

If they build another B tree (only trivially balanced) as they delete files they could return control to the system quickly, and then they could pull the free blocks out of the temp tree and spend the time to properly balance the main trees as it builds them.

In the event that it needs those blocks *now* it could stop and take the time to merge them into the tree immediately.

The benefit is that it would only have bad performance on very full drives, where it is writing immediately following a delete, into the freed space. As opposed to how it sounds now where it has bad performance on all deletes.

Deletes are a common enough action that I think you'd want to optimize for them.

The journalling filesystem myth

[Anonymous Coward]

I hope that joe public will eventually realize journalling filesystems don't guarantee data integrity in the event of an unclean system shutdown.

Re:The journalling filesystem myth

[Subjective]

Nothing can insure data integrity in case of mid-write shutdown. That's logically obvious

Journaling insures filesystem integrity, which is very important. Mounting an unclean ext3 fs will take seconds - no need to check the filesystem for mid-write evidence, etc. - the journal says excatly what mid-write problems there are, and wether to delete them or keep them as files.

If your system crashes in the middle of your work, and your hard drive wasn't physically damaged (it can happen. Use RAID if you're so paranoid), everything but your open files will be normal. Your open files might be 'un-journaled' (new official term? no) back to before you wrote them.

Re:The journalling filesystem myth

[mj6798]

Journaling insures filesystem integrity, which is very important. Mounting an unclean ext3 fs will take seconds - no need to check the filesystem for mid-write evidence, etc.

Let's say the journaling file system has 5% overhead (it probably has more). That means you lose more than 1h per day on a busy server--it's spread out, but it's still lost. You'd have to do a lot of rebooting in order to make up for that in terms of "saved" fsck time.

Re:The journalling filesystem myth

[cowbutt]

Let's say the journaling file system has 5% overhead (it probably has more). That means you lose more than 1h per day on a busy server--it's spread out, but it's still lost. You'd have to do a lot of rebooting in order to make up for that in terms of "saved" fsck time.

Actually, Andrew Morton reckons ext3 is actually quicker than ext2 in spite of the journalling. Go figure. :)

--

Re:The journalling filesystem myth

[jdub!]

That's an overhead you can safely quash by other means (faster disk subsystem, efficient RAID, etc).

A fsck is unpredictable wasted time you can't get around unless you've used a journalling filesystem - it may take hours, it may not work at all.

I'll play it safe, thanks.

Re:The journalling filesystem myth

[jdub!]

Speed and overhead are different things: You can have an incredibly fast webserver, but it may take 99% CPU to pull it off. That's bad. :)

Same goes for filesystems. A great filesystem is going to have stunningly low overhead, and be blisteringly fast [ plus be 8-hours-sleep reliable, but you can only choose two ;) ].

I mean... You want your machine to do things outside of managing their filesystems, don't you? ;)

Re:The journalling filesystem myth

[swf]

That's absolute bull. What's the difference between 10ms at 10% cpu load and 10ms at 20% cpu load
?

Re:The journalling filesystem myth

[edhall]

A few points:

1. You can't equate down-time to a slightly slower response time. Having a reboot time of tens of seconds vs. tens of minutes for (e.g.) a large source repository or a critical web server is well worth a minor performance hit. Reboot time is dead time for all who need access to the server.
2. If your file server is running so close to capacity that a 5% decrease in maximum filesystem throughput represents a 5% slowdown in actual throughput, your server is dangerously overloaded already.
3. In general, journaling affects write performance, not read performance. If your server performs mostly reads, the overall overhead of journaling may amount to much less than your 5% figure. Most (though not all) applications for file servers are read-intensive with incidental writes apart from the initial "load" of the server.
4. Fast fsck's aren't the main reason for journaled filesystems. Rather, its the improvement in filesystem integrity that is the main attraction -- an improvement that incidently allows for fast fsck's.

-Ed

Re:The journalling filesystem myth

[be-fan]

Actually, the new journaling filesystems (ReiserFS, XFS, and JFS) are all *faster* than ext2. Also, journaling itself can cost very little these days because modern JFSs use large buffers and coalesce writes. For example, BFS achieves metadata performance nearly as high as ext2 on a heavily loaded system. So if all you're doing all day is creating/deleting/growing/shrinking files, the filesystem is only slightly slower. When you factor in all the performance improvements, it end up being faster.

Re:The journalling filesystem myth

[mj6798]

Those are all the usual arguments. However, if you want reliability and avoid downtime, you must have redundant servers or replication; journaling will not protect against most of the problems that cause downtime. Once you have redundant servers, you can easily tolerate a little more time for fsck.

What it comes down to is that journaling is a convenience feature. Relying on it for "filesystem integrity" or "reduced downtime" or "reliability" is foolish. You pay for fast reboots in slower performance and more complex file system code.

Re:The journalling filesystem myth

[mj6798]

That may well be, but it doesn't really affect the argument. Journaling imposes an additional set of constraints on when and where data needs to be written to disk, and an optimal file system designed under those constraints is going to have more overhead than an optimal file system designed without those constraints. Generally, with journaling, either you write the same data multiple times sooner or later (which, I believe, ext2 does), or you put data in places where it may take longer to get to when reading it.

The only time where journaling doesn't have any significant overhead is if you put the journal on another device that can operate in parallel.

Re:The journalling filesystem myth

[edhall]

Sure, redundancy is nice. That's entirely orthogonal to the issue here, however. If I have a farm of redundant servers, and one of them cooks its power supply, with a journaled file system I can be reasonably sure that the system will come back up without some unfortunate sysadmin pulling an all-nighter to reload after the spare PS is installed. Redundancy might make it less likely that a failure will inconvenience my customers/users, but it also makes it more worthwhile for me to reduce my per-server admin costs -- and journaling does that.

-Ed

Partition resizing?

[Bun]

I've converted over to ext3fs, and am curious about one thing: resizing the ext3fs partitions. I know Partition Magic can resize ext2fs partitions with no difficulty, and Linux won't miss a beat. If the file systems are cleanly unmounted, as during a shutdown, and the ext3fs partitions are resized using Partition Magic, will there be problems? Is there anything in the journal that would make the kernel panic and puke on the newly changed partitions? I have no plans to do this; I'm just curious what would happen if I did.

Re:Partition resizing?

[Anonymous Coward]

I can think of at least one method that will work. Read on.

According to the article you can freely convert back and forth between ext2 and ext3. So it follows that you could convert an ext3 back to an ext2, then resize the ext2 file system. Afterwards convert back to ext3. Not so tough.

Maybe it is possible to do it directly too, but the method I suggest will work in any case.

Re:Partition resizing?

[Sapien__]

This thread might be useful.

To summarize: yes, it's possible to resize ext3 partitions, so long as your resizer doesn't mind. Don't use Partition Magic to do it. It doesn't like it. Badly.

Re:Partition resizing?

[fredlwm]

Why don't you use GNU Parted ? It supports ext3. Sorry, I can't help with Partition Magic.

Re:Partition resizing?

[LWolenczak]

do be aware that your journal may be to small if you lets say, double or triple the size of your partition.

Power loss

[nick255]

Just had my first power-loss since switching to ext3 last night. Normally would take 10-15 minutes for my computer to restart after checking /home, etc. But today came up in just a couple of minutes with no corruption (or none I have noticed, or has been reported). So ext3 gets my thumbs-up!

Re:Power loss

[Znork]

Yep, I was reinstalling our main fileserver here at home the other week, upgrading to redhat 7.2. Unfortunately the space was a bit cramped and I didnt bother to put the cover back on the computer so the powerbutton ended up resting against my chair. Of course, this resulted in several instant poweroutages as I got up to get coffee, etc. I think I managed to instakill it 6 times total. Not a single problem noted, just fast log replays and up and running again :). Thumbs up for ext3 from me too.

Excellent engineering

[ppetru]

The very existence of ext3, and it's complete forward and backward compatibility with ext2, shows that ext2 was extremely well designed by it's authors. Kudos to Remy Card, Ted Tso, and the rest of the ext2 team!

Also, based on the same extensibility of ext2, Daniel Phillips is working on a directory indexing patch which speeds up ext2 by a huge factor when working with lots of files in a directory. You can get the preliminary patches here and see a graph of a simple file creation benchmark here. Amazing!

Re:Excellent engineering

[jaju]

But why would someone now want to use ext2 given that (aparently, from the postings above), ext3 does a much better job (and so do other JFSes). Why spend time on ext2 development? Or is that going to affect ext3 too? So, that ext3 is faster than now?

BTW, ext3 is doing a wonderful job on my desktop. One more thumb up ... ;-)

Re:how to convert to ext3? -- as far as I know

[Dante'sPrayer]

If your root partition is formatted as ReiserFS, you're pretty much limited. Try to make a partition big enough on your free space, and make an ext[2-3] there. Then copy everything that is on the root partition to the new ext* one (use "cp -pR" to preserve permissions). Try to reboot the system, passing 'root=/dev/hd??' to the kernel, being ?? the new ext partition. If everything boots fine, you're on your way. If not, you won't lose anything on your old ReiserFS root; just reboot as usual.

Re:My semi-Weekly Drunken Comment...

[91degrees]

Never had any hardware that was easier to install in Windows than Linux. Windows keeps autodetecting it, insisting on the Windows disc, installing the wrong driver, and then rebooting. Then I have to go through this again with the right driver. Installing a TNT2 took 5 reboots. Under Linux I just had to run XF86config. 3D required that I reboted and added a line to the config file, but that was easy enough. BeOS just worked out of the box.

Re:Of course its been solid

[91degrees]

A good UPS should let the computer know when it is running low, and at the very least remount alll the disks read only. Mistakenly unplugging the cables at a co-lo isn't going to happen to moist systems, and so is not really a reliable way to determine the reliability of a journalled file system.

Re:My semi-Weekly Drunken Comment...

[clinko]

I booted and my TNT2 worked. Haven't rebooted since (because of that) in winXP

fsck... Is it needed???

[PimpNasty]

Do you still need the every 20th mount fsck???

Re:fsck... Is it needed???

[thefogger]

Well, yes, you should still do that fsck. But because of the journaling it's so fast that you barely notice it.

Re:fsck... Is it needed???

[Ark42]

tune2fs -c 0 -i 0 /dev/hdXX

Re:fsck... Is it needed???

[rew]

Do you still need the every 20th mount fsck???

No, really not needed. Actually one of my systems fscks about once a year. (the time-limit is set to six months, but it just never happens to be rebooted around that time... )

Roger.

The filesystem I want for Cristmas ...

[bockman]

... is one that allows for 'query directories'.

Explanation : I am of two minds abouth everithing, so I can never decide how to organize my files, i.e. for category (like executables, libraries, html, music ) or for products (like gnome, kde, MyPerferredApp ). So I want to do both.

I want a filesystem in which you can define directories by query of file attributes : e.g. :
mkdir ~/gnome_bin --query -type=executable -package=gnome
And then the system keeps update my directory, and I can handle it with standard filesystem tools.

I know that it isn't easy : that is why I'm aksing it as a cristmas gift.

Re:The filesystem I want for Cristmas ...

[bockman]

You can see my 'query directories' as specialised views of the filesystem ( exactly like you can define a virtual table which is a 'view' on the actual database contents ).

I relalize that not all the semantic of the file-system may apply: for instance moving a file in a directory with particular attributes does not make sense ( well, unless you make it means that the file gets the attributes of the directory ... which is interesting but a bit weird).

As far as weird goes, there is already something quite weird in the Unix filesystems: the hard links, which already allows a file to be in more than one directory.

Re:The filesystem I want for Cristmas ...

[timster]

In other words you want a relational database for a filesystem. I think some of IBM's mainframes have features like that.

Re:The filesystem I want for Cristmas ...

[shani]

Did you mean this?

Slashdot: News for nerds. Again, and again, and again...

Re:My semi-Weekly Drunken Comment...

[clinko]

As simple as your example is, it's perfect. Sums up everything quick and easily.

Now if only other people could understand this epiphany. (or spell it) :)

Who knows what ext means?

[imrdkl]

extreme, perhaps? extendable? extraneous? extatic?

Re:Who knows what ext means?

[Anonymous Coward]

> extreme, perhaps? extendable? extraneous? extatic?

extended

Ok which is best Reiserfs or ext3?

[ACK!!]

I just moved over to this Reiserfs a couple of months ago. I like it and all but is ext3 better or faster. Faster is always better.

Re:Distro battles? Nah. Journaling fs battles!

[kraf]

Yeah, but reiserfs was stable much sooner, so all my big filesystems are reiser. Now it would be a pain to convert them to ext3.
I'd choose ext3 for new installations however, if only for the purpose of trying it out and comparing to reiserfs.
I don't think that much advertised compatibility is going to count much. The faster/more reliable fs will be the sysadmin choice.

Re:My semi-Weekly Drunken Comment...

[91degrees]

Yes. Have you tried changing your hardware in WinXP? Besides, installing a new OS is not the easiest way for me to get hardware to work.

Re:Of course its been solid

[Lumpy]

excuse me but if it takes your servers more than 30 minutes to complete a shutdown then you have problems that are bigger than a filesystem

at my facility which is small and only has 15 servers the proceedure is this.... power drops, UPS's kick in, generator starts.

If generator starts then all is fine.
if generator doesn't start then the UPS's signal to the servers that power is lost and the servers shutdown. everything starts back up when power is restored.

It's happened 3 times without anyone there, and had no problems.... except for the NT machines hanging and one person (me,oops) leaving a NT install cd in a cd drive.

A properly designed backup power system will cause ZERO problems to a computer server system or network.

Oh and if you use one BIg UPS instead of dedicated UPS's for each server then you are asking for trouble. (reminds me of eggs in a basket)

I've seen the data center's 3 million dollar APC ups fail to work 3 times during tests. My APC 2200's never fail me (I replace all batteries every 18 months) so spending an insane amount of money for a power backup solution is not a smart thing to do.

Re:My semi-Weekly Drunken Comment...

[Lumpy]

Actually the "games" issue is going away.
I have 10 major brand games running on linux now, and 5 more under wine in linux.

No effort taken to install them.

as for better, you are mistaken. Linux is free. ZERO cost. I also dont have to agree to leagal bullcrap or am trapped to complying with M'S wishes. If I have a friend that wants my OS I just burn him/her a copy and legally give it to them.

It's the legal nightmare and Microsoft's dirty tricks that make linux better. Microsoft's lawyers are the best thing to happen to linux.
Their greed and stupidity digs the hole faster and faster for microsoft.

MS could overtake everyone instantly with one simple move. Non commercial use of their os is free. but that will never happen..

I'm using XFS

[Beowulf_Boy]

I am setting up a lab of 30 machines for internet surfing at my school. They are p200's with 32megs of Ram. I decided to go with XFS basically because I know SGI has been using it for a long time, and therefore, most of the bugs are probably worked out of it. For the Lab, I am using Redhat 7.1 XFS with IceWM as the window manager. The system boots, runs an autologin script I made, and goes into IceWM with Netscape.
I was using Blackbox, but I decided not to, because I didn't look "Windowish" enough, and I didn't want people confused by it. IceWM looks great, runs fast, and has a little Penguin for the start button. It took me about a month now to get all the net cards in the 30 computers (along with other stuff) and now all I have to do it haul them over to the middle school, and ghost them with the image I have on CD.
I am very happy, because I have been working the bugs out of this project since August, and am almost done. Next Wensday I hope to have all the machines done with. Then I get to find out how easily kids can trash linux. But, I didn't secure it that much, because I feel as if they want to mess it up, all they would have to do is boot with a floppy and nuke the partitions. And it only takes a few minutes to re-ghost them. The 486 lab they have now has been surviving for 5 years now with no reinstall, so I think I'm safe.
Does anyone have any comments that would help me out?

Re:I'm using XFS

[Anonymous Coward]

But, I didn't secure it that much, because I feel as if they want to mess it up, all they would have to do is boot with a floppy and nuke the partitions.

If possible, go into the BIOS settings, set the computers not to boot from floppy, and password-protect the BIOS settings. You should also add a password to lilo.conf and use the "restricted" keyword so people can't type "linux init=/bin/sh" and get a root shell (if you're using GRUB, similar options are available).

After doing this, a student would probably need to open the computer and disconnect the CMOS battery to boot from a floppy. Or they could find a local root exploit. Try to minimize the number of setuid-root programs, apply security patches when they're available, and use a recent kernel (older ones had security problems).

You might not expect your students to do stuff like this, but sometimes people try to hack their school's computers out of boredom. In my high school, a few people tried to run Netware exploits to gain administrator status (they didn't work). I've also heard of people installing keyboard sniffers on school computers to get passwords. Re-ghosting a machine will do nothing if someone knows your password.

Re:I'm using XFS

[Beowulf_Boy]

trust me, no one will ever guess my password,
and, they are little 7th graders, I'm plenty safe.

Re:I'm using XFS

[AaronMB]

Well, for best bets, you should reorder the boot order so that it boots from the hard drive first. Also, you should password protect lilo so that they can't type 'linux single' or its variants at the lilo prompt, and then you should chmod /etc/lilo.conf 600 so that no one else can read it. Beyond that, your best bet is to keep the packages up to date security-wise.
-Aaron

benchmarks

[stmpynode]

has anyone done any benchmarks comparing ext2 and ext3 to reiserfs? i know the article mentions differences in performance, but i wanna see graphs and pictures :)

Re:benchmarks

[El Prebso]

Namesys have compared ReiserFS, ext2, ext3 and XFS. They don't have graphs or pictures, but they do have easy to read numbers.

Remember that Namesys is Hans Reiser company, so they like ReiserFS, but I don't think they cheat with the bechmarks.

http://www.namesys.com/benchmarks/benchmark-resu lt s.html

Ext3 Is Dead at Birth

[Anonymous Coward]

Yet another Red Hat revolutionary product that the rest of the distributions promptly ignore. And with good cause.

This talk of ext3 being faster than Reiser or XFS is crap. It's not faster, and on IDE hardware the journaling capabilities are offset by the way the IDE drives work. Ext3 is the weaker of the bunch on IDE hardware, to the point that you might as well not even use it. It seems the point of ext3 is to eliminate the need of fsck and not the benefits that can be had with journaling (as in XFS's xfsdump and xfsrestore).

If you want a good journaling filesystem, use Reiser or XFS on FAST drive hardware. If you're not up to making the investment in SCSI or ATA 100 drives and insist upon running XFS or Rieser on your 5200 rpm 10 gig IDE drive, of *course* it'll be slow.

Re:Ext3 Is Dead at Birth

[Hast]

If you bothered to read the article you would know that there is one (significant) way which makes ext3 better than both Reiser and XFS. It can journal data.

This means that you will not open up your XF86config file and discover that the powerfailiure has now resulted in a file full of zeroes.

To me /that/ is a good reason to use ext3. I still use XFS on my file server though. Because that's what it (XFS) is great at. (Big files, lot's of files and lot's of accessing.)

XFS, Ext3, ReiserFS...

[SaDan]

I've been using all three filesystems on various machines at work (XFS being on SGIs), and I have to say that ReiserFS seems to be much faster than Ext3, Ext3 is much easier to upgrade from Ext2 (very convenient), and XFS is just plain powerful. I can't compare XFS under Linux to the other Linux journaling filesystems, but I'm getting ready to see what it's like.

If XFS for Linux is anything close to the SGI version, XFS is going to beat the socks off of both Ext3 and ReiserFS.

Re:XFS, Ext3, ReiserFS...

[be-fan]

Its really nifty. Its got attributes and ACLs and you can grow it without even rebooting!

Re:extensions

[Karpe]

Actually, you can use it, with ext2 *and* ext3. The ACL group implemented ACLs as extended attributes, that can also be used for metadata (icons, mime types, whatever):

Check out the ACL guys homepage for more details.

FAT12/16/32/vfs

[slittle]

Is it just me, or does ext3 sound like FAT16 > FAT32 and VFS, in that it's for all the little nancy boys who are too chicken/lazy to upgrade to a much better filesystem (and OS, while they're at it)?

Not that the work done by the ext2/ext3 people isn't excellent, it's just that time is coming for extX to move on (be incompatible), or move aside.

Re:how to convert to ext3? -- as far as I know

[nusuth]

I now wish I had waited for your reply, instead I did what AC said, tar everything, mkfs and untar. For some unclear reason, lilo refused to understand that I was trying to install it on /dev/hda5 (/) instead of /dev/hda1 (backup.) But your suggestion does not seem to be working around this problem either, how could I move boot stuff to ext3 and destroy reiserfs after transition?

Any serious crashes with ext3, anyone?

[yason]

I've been running ext3 fine for a few weeks now on my home box and my linux workstation at work. On Monday I decided to update our cvs server to kernel 2.2.20 (from .19) and ext3 and the next morning it was down big time. Reading logs, I could see that something had gone wrong during the big backup cronjob after 6am. It creates a 150-meg tmp tarball of our cvs repository for replication and it had only managed to do the first 4 megabytes. I also had a few "hda: lost interrupt" entries in the syslog, right during the time the backup process had halted. The disk was sloppy and not responding much, so it might be some h/w failure as well. I booted, the ext3 replayed the journal and everything seemed fine until I found some weird files with mysterious access bits set in some directories. I couldn't delete or move them. Also some files had disappeared and some others corrupted, AFAIK. I took the system down to runlevel one, remounted partitions read-only and run fsck.ext2 on them. It reported hundreds if not thousands blocks belonging to more than one inode.

This may just be some weird hardware failure but it just sounds too coincidental. The box has been rock stable for at least a year in its current h/w setup. I've been testing 2.2.20's fine on many machines before, both with ext3 and ext2. Now that I restored the old system from backups it's running on 2.2.19+ext2 again quite happily.

I'd like to know if anyone else has had problems that may be related to ext3? I'm still running it on my personal boxen but it seems that our servers won't be seeing this new filesystem at least until it appears on Debian Potato, included in the standard 2.2.x kernel release. If ever.

Re:Still same old 2GB limit?

[LunaticLeo]

ext2 doesn't have a 2GB file size limit. That was a operating system limit which went away somewhere in the middle 2.2.x stable series.

Further, ext3 is not the-next-version-of-EXT. It is an extention of ext2 which is fully compatible with ext2. Think of ext2 as two things: the format of bits on the disk, and the code to read/write those bits. Ext3 keeps the same format (actually with compatable extentions), but mostly it changes the code for reading/writing to the disk (journelling).

The ext2 filesystem is tried and true. You can go back and forth between ext2 and ext3 with no reformating or issueing of commands other than the mount command.
ReiserFS is a more "sophisticated" filesystem than ext[23], and XFS is a more "sophisticated" filesystem than ReiserFS. But I keep "sophisticated" in quotes because the utility, reliability, and speed of a FS relies more on your usage patterns, than on the genius of the filesystem designers/coders.

FFS-style: ext2,ufsFFS+journel: ext3, ufs+
B+tree directories, B+tree block layout, Journelling: ReiserFS
B+tree directories, B+tree block layout, extents, Journelling : XFS, JFS
Loggin FS: VxFS (my favorite)

I use ext3 at home. Good speed, no need to tar up all my files..reformat drives..untar all my data, journelling, mainline kernel support, tried and true.

One place I would seriously consider ReiserFS is for home directories. The place it really shines is constantly reading and writing lots of "small" files (small ~50k). For Gnome and KDE config files, Mozilla disk caches, CVS checkouts, and untaring of source, ReiserFS is going to be a leader of the benchmarking pack. You'll notice the difference.

But don't get into holy wars over FS, and don't think that Linux is whole generations behind Commercial Unixen. Linux Kernel is dramaticallly ahead in some areas and minorly behind in others. The only place it is dramatically behind is places where the computer you are running the OS on cost more than a half million dollars.

ext3fs not recognized by Norton Ghost

[tollieman]

I run a large lab and use IBM's LCCM Package to install OS images to 60 client systems that I use for benchmarks.
LCCM does not support installing Linux like it does Windows OS's.
I attempted to use the latest Norton Ghost, and it will only allow ext2 filesystems to be created.

Anyone out there used IBM's LCCM to install ext3 filesystems? Or have a good process for making an image of an already installed system for mass installs?

snapshots

[Anonymous Coward]

Not to "troll" for my fav OS or whatever, but I've been playing with snapshots in FreeBSD-CURRENT for the last few days, and I must say that this is quite possibly the coolest filesystem technology I have ever seen.

In short, a snapshot is approximately equal to an image of a filesystem. To create a snapshot, you run a mount command like "-u -o snapshot /var/snapshots/snap1 /var". Becase of the way snapshots work, the snapshot must reside in the same filesystem that it contains.

Now, once the snapshot is created, it can be treated like another filesystem. You can run fsck on it, dump it, or even mount it. The only difference is that within the snapshot, previous snapshots will appear as null files.

Basically, when you create a snapshot, you tell the filesystem that you want it's contents at the current time preserved, and the snapshot file is where it does this. Now, whenever said filesystem is modified, the modification is basically applied in reverse to extant snapshots. So, when a snapshot is first taken, it doesn't contain much information at first, but when you rm a file living in the directory, the file is saved into the snapshot. When you modify a file, deltas to reverse the change are saved to the snapshot.

This is extremely powerful used in the hands of a good sysadmin. Imagine your server that is backed up to tape every week. When someone comes asking for a file they clobbered or deleted by accident, you say "how old was the file?" - you know if they say "8 days", you have to go restore from tape, and if they say "2 days", you have to tell them that they are out of luck. Now imagine if a cron job was set up to take a snapshot once a day, and clear out old ones once a week. If they say "8 days", you still have to go fetch the tapes, but if they say "2 days", all you need is some mdconfig, mount, cp, and umount action to restore the file. How cool is that?

Snapshots essentially give your filesystems the "undo" capabilities that your editor has.

Re:snapshots

[PhotoGuy]

I'm guessing (and hoping) that the FreeBSD snapshot mechanism is similar to the way that Network Appliance filers do it. Basically, in addition to the current root inode, they create an alternative root inode, which shares all the same inodes and data blocks as the current file system as of the snapshot. But any modifications alter the current root inode tree (in kind of a copy-on-write kind of way), and leave the snapshot inode tree alone. Very cool stuff, efficient, and nice and low-level. (Not just a backup/restore/undo/trashcan, or whatever, but the way it should be done, at the inode level.)

In theory, the same thing should be possible with a compatible extension to the ext2 structure, (although, similar to the ext3 journaling debate, I'm not convinced building on ext2 structure is necessarily the best thing.)

Here's a white paper on the network appliance file system (WAFL):

http://www.netapp.com/tech_library/3002.html

Lots of other good white papers on that site, too. Interesting reading if you're into filesystems.

One very cool feature of the Network Appliance's file system (written from scratch), is that, in fact, there is *only* static snapshots, combined with a journal. There is no dynamic inode tree, just snapshots and a change journal. So snapshots are an integral part of their journaling mechanism, internally. Changes are written to a journal, and periodically those journal entries are applied to the former snapshot, creating the next snapshot. (And on the netapp hardware, journal entries are written to battery-backed up ram, etc., to add even more stability.)

-me

Re:snapshots

[psamuels]

In short, a snapshot is approximately equal to an image of a filesystem. To create a snapshot, you run a mount command like "-u -o snapshot /var/snapshots/snap1 /var". Becase of the way snapshots work, the snapshot must reside in the same filesystem that it contains.

Linux has snapshots too, but only if your filesystem is in a logical volume managed by LVM. An LVM tool calls the kernel LVM driver, which tells the filesystem in question to "quiesce itself" (i.e. make itself consistent on disk) if possible (only ext3 and reiserfs support this operation at the moment), then it creates a new snapshot logical volume, which is of course COW (as are, I assume, FreeBSD snapshots), and finally the filesystem is given permission to continue operations.

Unlike the FreeBSD snapshot facility (as you describe it, anyway) the new logical volume is read-only - you can't fsck it etc.

This is extremely powerful used in the hands of a good sysadmin.

Indeed, I've been thinking of using Linux snapshots more or less the way you describe. (Our shop is small enough that it's hardly worth doing daily backups, but if it's easy enough....)

Re:snapshots

[fatrat]

This isn't a new idea - NetApp boxen have done this for years. It is a really, really handy idea for a fileserver though.

Careful interpreting!

[zCyl]

Remember that Namesys is Hans Reiser company, so they like ReiserFS, but I don't think they cheat with the bechmarks.

Cheat, probably not, but accurate to common usage of a filesystem?

Be very careful interpreting those benchmarks, because the ones they consistently list first are the ones with a bunch of files that are 100 bytes in length, which is essentially the only area where Reiserfs really pulls ahead. Reiserfs is essentially tied with ext2 for all reasonably sized files that you would expect to find on a system. (Unless you're dealing with intense processing of millions of 100 byte files) When comparing ReiserFS to XFS and JFS, ReiserFS pulls way ahead for extremely small files, but the other filesystems perform notably better for reasonably sized files (10k) when synchronized.

For practical uses, neither filesystem seems to really pull ahead, so it's worth considering other features when deciding which to use.

ext3 not solid to me

[Anonymous Coward]

kernel 2.4 is not solid enough for me
to even start testing. if it doesn't
run on 2.2 then its not solid enough
for my needs. i don't want to have
to upgrade a kernel every 2-3 months
to fix a critical bug. reiserfs is
decent i use it on a few machines, but
ext2 is still the dominant filesystem
on my ~40 linux servers. most have
2 hours of battery backup and never
crash. so journalling isn't much of
an issue. the last power outage
that lasted more then 30mins that ive
experienced was back in 96 or 97 when
a tree branch broke a line and caused
most of the west coast to go to brownout/blackout state for 3-4 hours.

Re:ext3 not solid to me

[fredlwm]

There are ext3 patches for 2.2, but the recommended is 2.4.

So when

[wbav]

I've just recompiled my kernel to 2.4.14. So when will they add ext the the regular file systems rather than waiting for the patch to come out? I mean the first time I tried to apply the patch, bad things happened.

I don't like seeing kernel panic messages.

Re:So when

[fredlwm]

I'm using the ext3 patches since 0.0.1 for 2.4.5. ext3 was integrated in 2.4.15pre2.

Re:So when

[wbav]

Thanks. That will help when a stable 15 comes out.

Re:Still same old 2GB limit?

[richie123]

It's my understanding that 2gb limit was never ext2 related, and was a limitation of the 2.2 vfs.

And no you can make files as big as you want with both ext2 and ext3 with kernel 2.4.

Ext3 is a decent filesystem that offers solid reliabitily,performance, and feature set. XFS may be a better option in the long run, but right now ext3 is the best filesystem for linux.

You are missing the point

[sigwinch]

However, if you want reliability and avoid downtime, you must have redundant servers or replication; journaling will not protect against most of the problems that cause downtime.

Here in the real world we cannot afford triple redundant drives, motherboards, RAM, CPUs, power supplies, keyboards, mice, monitors, NICs, routers, and network cables for every single computer on every desktop in the entire organization. Sure, we could do it, but the cost would be ludicrous for a very small payback.

Most computers simply don't need guaranteed zero downtime. What they need is bounded downtime. It's OK if they crash every once in a while, as long as they reboot cleanly within a few minutes. The biggest contributor to boot time after a crash is the file system check. Since a journalling file system can recover the file system within a few minutes, it is a huge win.

Relying on it for "filesystem integrity" or "reduced downtime" or "reliability" is foolish.

Here in the real world, even the big real-time transaction processing systems occassionally have common-mode failures that wipe out all the redundant subsystems at the same time. Lightning strikes, idiots frob the emergency power switch, etc. Thus, the big real-time systems need journalling even more desparately than the small systems.

You pay for fast reboots in slower performance and more complex file system code.

Sheer ignorance. Replication of filesystems and databases has at least as much of a performance hit as journalling, and the complexity is likely to be vastly higher.

Good news and bad news...

[Lanir]

Good news first: Something similar to what you're describing does exist.
Bad news: It's for the GNU/Hurd, not Linux.
The servers I think may interest you would be usermux and hostmux. I haven't booted the Hurd in awhile, but as I remember usermux creates a virtual fs that contains usernames. If you cd into their name you end up in their homedir. Hostmux does something similar but links to networking info about a given host, not part of it's filesystem. These vfs's last across reboots in the Hurd by writing information directly to an inode and they're automounted as they're required. All of this is done in ext2fs and I'm told it works in the BSD fs as well.
Now, what this means to you... I'm not quite sure, to be honest. :) I'd imagine you could adapt one of these to suit you, at least under the Hurd. I am not a developer so I can only tell you that when people speak in general of porting the Hurd servers over to Linux, there is much groaning and ye olde mile long list 'o reasons why it's not such a great idea. If you're interested in taking a look anyway, feel free to mail me and I'll tell you the rest of what I know: I don't know that porting a single server over would get the same reaction but all the code is GPL'ed with the explicit intention of allowing people to adapt it to their needs. If this is what you need, then be prepared to do a lot of coding, though. They'll certainly wish you well, but I'm afraid no one from the GNU/Hurd project is gonna write it for ya. :)

Lanir

Re:Distro battles? Nah. Journaling fs battles!

[Mullen]

Actually it's more like:

umount /dev/sda1
fsck.ext2 -y -f /dev/sda1
fsck.ext2 -y -f /dev/sda1 (Just to make sure)
tune2fs -j -C 0 -i 0d -c /dev/sda1
mount /dev/sda1 /whereever

You have to make sure to check the filesystem before you put the journal on it. Also, set the fsck checktime to 0 so it will never be fsck'ed.