Anyone(lau?) use ReiserFS?

Post Reply New Topic

I hear its faster than ext3. Shall I use a murderers file system?

just because the author is a "convicted" murder does not make the technology inferior, primitive constructs such as ethics and morals do not apply in science for they are dead weight, I mean take the whole stem cell research issue as a referencing example.

Reiserfs is a brilliant file system although work on version 4 has slowed as result of this.

I have no problems with using a file system just because of the author. Although, I've always used XFS on Linux. I'd prefer to use ZFS though.

Why would I be trying ReiserFS if I thought it inferior?

That I mention the creators conviction is merely a point of interest. If I was concerned his ethics impinged on his intellect, why would I make this post? Why would I be interested in trying ReiserFS?

Reiser4 is superior compared to the original ReiserFS. Eventually Btrfs will be more useful than all of the current linux file systems. So you'd probably want to convert to that later.

Ah! That explains why tests are not showing much speed differences between ext3 and ReiserFS. The Reiser I am using is the version that is formatted with Debian installers.

Stay with ext3. You can convert it to btrs (the utility is already available, but the current version of btrs isn't considered stable enough).
Btrs is pretty much a clone of ZFS, but it uses the GPL so it's compatible with linux.

* wanders in, rubbing eyes, yawning, wondering what the big deal is *

I've never happened to make any great demands on my file systems. I crept up from ext2 to ext3 (only when that became extremely stable), purely to avoid the small irritation of the time it took when fack wanted to run.

ReiserFS never really appealed to me.

What is this about all the different filesystems? You lost me there.

Just a small step in the install process of Linux systems. You've probably googled more info than I could share with you.. the differences to the end user as so superficial.

ext2 was the standard FS for linux for a long time, just as NTFS is for windows. NTFS replaced fat32 and fat(16), and ext3 has replaced ext2.

Ext3 features journalling, which is why disk fragmentation is not an issue as it is in windows.

The ext file systems and ReiserFS as well, have more sophisticated permissions than NTFS. If you have ever used chmod in linux, you've touched upon it. You can do it graphically as well; right click a file and select permissions tab.

ReiserFS was said to be faster, so in my quest to break every aspect of an install, I tried it out.

Hm. I'm using hfs+, ntfs, and ext3 filesystems for my OSX, Vista, and Ubuntu partitions, as well as zfs in my Solaris VB. I'll have to start looking into more information on these various systems and what exactly they do.

Slight correction... disk fragmentation is not a problem in ext2, either. Journalling is what helps when you crash your system (or rather, seeing as Linux systems don't crash, when your power cut happens, or you trip over the power cable, and so on).

With a sensible operating system, writes to the hard drive don't happen immediately - they are queued up. If a problem results in them not happening, your file system is probably going to end up in a mess.
With ext2 (and FAT, etc), this means a pretty extensive trawl through the entire file system, to hopefully figure out what got messed up, and making adequate corrections so that the structures are all repaired. Hopefully, at worst, you may lose an odd file, say, that had been in the process of update.

With ext3, the main thing that is added is a system whereby it remembers exactly what it is doing at each point in time. On the face of it, as this journal data is also being written to the drive, it sounds as if it would make the situation worse? But no... the overhead writes are not that bad, as they don't hold all the detail, just the broad idea of what is "in progress". For recovery purposes, though, the journal shows exactly which places to look at, to see what has, or has not been completed. None of the rest of the file system has to be looked at.

Interestingly, ext2 and ext3 can be trivially converted, each to the other, as ext3 is essentially ext2+journalling, where that journalling is "detachable".

I'd prefer that you substitute "sane" for "sophisticated".

Thanks for the corrections and education lau. Its always muchly appreciated.

One thing I tried was setting reads and writes to 'sync', thinking this might be a superior way to do things. Turns out it is NOT.. it really slows things down.

Sane for sophisticated... haha! Yeah, that might be true.

Try "man sync".

I come from the days when it was recommended that you always invoked "sync" three times, before halting your machine. (I've no memory of any justification for the "three times" - I suspect it was just standard magic.)

I'm not certain, but I would imagine that selectively operating particular mounted file systems in "sync" mode would appeal to people who run multiply redundant systems, where the hot takeover is to be instantaneous. I.e. one machine crashes, and another can immediately carry on, as the critical file systems do not need ANY checks on them, since they are always structurally valid.

I.e. you take a continuous hit in efficiency to wipe out a few seconds of unavailability. This is the definition of "real time" - it DOESN'T mean "fast", it means something far more subtle: "subject to some time constraint that MUST NOT be exceeded".

I once had to decide between using one or other of two similar microcontrollers for a video processing task. I won't have the details right, but it was roughly as follows. The H8 was twice as fast as the PIC17. However, the H8 had an interrupt latency of one to seven cycles, whereas the PIC17 was just one or two cycles. I.e. the variability with which a timed interrupt could be serviced (edge event -> output result, in this case, a synthesised HSYNC) was 6 cycles on the H8, versus a single cycle on the PIC17. Although the H8 was twice as fast, its "jitter" effect was three times worse. This was way outside our acceptable range, so the H8 was dead in the water. Double the overall speed, but incapable of real time (for this, or indeed any, application that could not tolerate jitter).

Hm. I suppose we could drift back on topic, sometime soon?