login
Header Space

 
 

Linux: Reiser4 FileSystem Stabilizing

March 28, 2004 - 1:06am
Submitted by Jeremy on March 28, 2004 - 1:06am.
Linux

Those following the evolution of the Reiser4 filesystem will be interested in learning that it has become "fairly stable for average users", so much so that Namesys is soon planning to push patches [story] to 2.6 kernel maintainer Andrew Morton [interview]. Once the two remaining known bugs are fixed, the warnings against using reiser4 on a production system will likely be removed. Hans Reiser explains:

"We have one NFS related bug remaining, and one mmap all of memory related bug (and performance issue) that you can hit using iozone. We will fix both of these in next week's snapshot, they were both multi-day bug fixes. When they are fixed, unless users/distros find bugs next week we will submit it for inclusion in the -mm and then the official kernel."

Hans goes on to note, "We need a lot more real user testers, because we have run out of scripts that can crash it, and there are distros that would like to ship it soon." Read on for the full thread, including links to the latest snapshot and changelog.


From: Nikita Danilov [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: [ANNOUNCE] new reiser4 snapshot released.
Date: Fri, 26 Mar 2004 19:45:10 +0300

Hello,

new reiser4 snapshot against 2.6.5-rc2 is available at

http://www.namesys.com/snapshots/2004.03.26/

It is mainly bug-fixing release. See READ.ME for the list of fixes and
caveats.

Should no significant problems be found in this snapshot, we shall start
sending patches to -mm next week.

Nikita.


From: Hans Reiser [email blocked] Subject: Reiser4 needs more testers Date: Fri, 26 Mar 2004 09:05:05 -0800 We have one NFS related bug remaining, and one mmap all of memory related bug (and performance issue) that you can hit using iozone. We will fix both of these in next week's snapshot, they were both multi-day bug fixes. When they are fixed, unless users/distros find bugs next week we will submit it for inclusion in the -mm and then the official kernel. We hope it is now fairly stable for average users if you avoid those two issues (we need to get rid of those dire warnings about its stability...., we will remember that next snapshot....;-) ) We need a lot more real user testers, because we have run out of scripts that can crash it, and there are distros that would like to ship it soon. Please also complain to [email blocked] and [email blocked] about poor documentation, etc., .... The new reiser4 snapshot (against 2.6.5-rc2) is available at http://www.namesys.com/snapshots/2004.03.26/ -- Hans
From: Jonathan Briggs [email blocked] Subject: Re: [ANNOUNCE] new reiser4 snapshot released. Date: Fri, 26 Mar 2004 10:23:54 -0700 On Fri, 2004-03-26 at 09:45, Nikita Danilov wrote: > Hello, > > new reiser4 snapshot against 2.6.5-rc2 is available at > > http://www.namesys.com/snapshots/2004.03.26/ > > It is mainly bug-fixing release. See READ.ME for the list of fixes and > caveats. A definition of fibration: http://mathworld.wolfram.com/Fibration.html I'm going to have to study math for about a year before I understand all that, I think. It's a good thing we won't have to understand "fiber bundles", "paracompact topological space" and the "homotopy lifting property" to USE Reiser4. *grin* If I missed the discussion or a web page, I am sorry. But could someone post a quick explanation or pointer to one about this fibration plugin? What does it do and what effects will it have? -- Jonathan Briggs [email blocked]
From: Nikita Danilov [email blocked] Subject: Re: [ANNOUNCE] new reiser4 snapshot released. Date: Fri, 26 Mar 2004 21:11:45 +0300 Jonathan Briggs writes: > On Fri, 2004-03-26 at 09:45, Nikita Danilov wrote: > > Hello, > > > > new reiser4 snapshot against 2.6.5-rc2 is available at > > > > http://www.namesys.com/snapshots/2004.03.26/ > > > > It is mainly bug-fixing release. See READ.ME for the list of fixes and > > caveats. > > A definition of fibration: > http://mathworld.wolfram.com/Fibration.html Reiser4 plugin was named this was due to some (arguably vague) similarity with mathematical fibrations. > > I'm going to have to study math for about a year before I understand all > that, I think. > > It's a good thing we won't have to understand "fiber bundles", > "paracompact topological space" and the "homotopy lifting property" to > USE Reiser4. > > *grin* Why, of course one has to understand it. Reiser4 refuses to mount unless supplied with the homotopy group of the tangent bundle of hard drive, for sure. > > If I missed the discussion or a web page, I am sorry. But could someone > post a quick explanation or pointer to one about this fibration plugin? > What does it do and what effects will it have? Fibration plugin affects how disk blocks are allocated for the files within the same directory. Basically, in reiser4 all file system data and meta-data (except for allocator bitmaps) are stored in a single balanced tree. Every piece of information in the file system (byte of file data, on-disk inode, directory entry containing file name, etc.) has a key that allows to locate this information in the tree. This imposes natural order on all file system data (because keys are just large integers, and can be compared). Block allocator tries to allocate blocks in a parent-first tree order. This means, that things with close keys have chances to be close to each other on a disk. This leads to the main high-level mechanism that reiser4 uses to control disk layout: through key assignment. In particular fibration plugin is called when new name is inserted into a directory, and, based on a name, selects some (otherwise unused) 7 bits in a key of directory entry. This allows to "slice" directory content into "fibers", hence the name. For example, one possible implementation is to place .o files in one fiber and all others in another. This significantly speeds compilations up, because .o files are created close to each other and don't interfere with sources. Fibrations, and well as other plugins, can be set per-object, see http://www.namesys.com/v4/pseudo.html for details. > > -- > Jonathan Briggs > [email blocked] > Nikita.
From: Hans Reiser [email blocked] Subject: Re: [ANNOUNCE] new reiser4 snapshot released. Date: Fri, 26 Mar 2004 09:11:00 -0800 Nikita, would you confirm that the default fibration is to sort all files with '.' as the penultimate character by their last character first and then by the rest of the name in the usual lexicographic order? (If that is not the default, then please make it the default.) Also, please note that the URL you supplied does not yet describe the fibration plugin and its available settings. Please correct that on Monday. -- Hans



Related Links:

finally!

March 28, 2004 - 3:32am
Anonymous

just as i lost hope and expected reiser4 to be ready soon just like hurd, it seems it will make its way into the 2.6 mainline kernel this year, probably in a suse 9.2/10.0 release :)
i'm really looking forward to that - thanks for the work reiser team!

Coolio

March 28, 2004 - 4:23am
Anonymous

Glad it looks to be stabalizing, and if it is truely stable then its obviously worth the wait. However, I am curious - is it subjectively faster then say Ext3 or Reiserfs 3.x? Benchmarks are fine, but would I /feel/ the difference in day-to-day crap? Say, backing up the entire contents of my /home into another HD or across the network to another machine? Not every day kinda stuff, but surely more stressful on the FS then merely launching apps or writing file saves.

Ready, and then?

March 28, 2004 - 8:25am
Anonymous

Is Reiser4 the FS that can compete with the already much-hyped (but really pretty) Longhorn FS, perhaps using Reiser4's plugin ability?

Is it possible to migrate a ReiserFS 3.6 disk to Reiser4 without too much trouble?

No migration

March 28, 2004 - 8:37am

Is it possible to migrate a ReiserFS 3.6 disk to Reiser4 without too much trouble?



I asked this question of Nikita. I'm afraid the filesystem is completely different so there is no way of converting a 3.x reiserFS partition to 4 without starting with a clean partition.

I suppose it is possible

March 28, 2004 - 8:39am
Anonymous

Usually, migrating from one version of ReiserFS to the next is so simple as just mounting it with an option. The problem is downgrading from one version to the previous one.

Check this tool

March 28, 2004 - 9:52am
Anonymous

Convertfs can convert from any fs o others as lon they are able supported by linux and a few things more

little description:
http://packages.debian.org/unstable/admin/convertfs

I did a little experiment

March 28, 2004 - 3:07pm

I did a little experiment with loopback-ed partition images a while back to test convertfs (I was wanting to see if it was "safe"), and at least converting from XFS to ext3, there were a couple files ruined. (mainly a very large gimp XCF file that still had binary data, but was unreadable by gimp). So I'm not sure if I would trust convertfs in a production environment.

Considering reiserfs's histor

March 28, 2004 - 6:58pm

Considering reiserfs's history (I've lost data to it twice, I'll never use it again and I'll be sticking with XFS) and the fact that WinFS is no longer a full filesystem, I doubt there's much to compare between the two.

My luck has been quite good

March 28, 2004 - 10:59pm
Anonymous

I've never lost any data to it ever, and I've been using it since it became an option with some early Mandrake release. I too, currently, prefer XFS but ReiserFS is quite solid now IMHO.

many people use reiser

March 29, 2004 - 6:40am
Anonymous

There's always the hardware failures. I've been using it in production on a dozen machines starting about 1999. All this time I have never had it lose data. For a long time they didn't have a working fsck, but they seem to do better this time. Personally I prefer restoring from backups when I've had hardware problems.

re:many people use reiser

April 3, 2004 - 7:57pm
Anonymous

One thing that seems to be the case about reiserfs is that if you do have hardware problems, it seems more likely that reiserfs will cause big problems than, say, ext3.

Now that just *seems* to be the case from my point of view. I have no evidence to back up this claim.

On good hardware though, reiserfs is stable. The only problem I ever had was when I overwrote the first 50 or so MBs of the filesystem, due to overlapping partitions.

XFS didn't like me much for some reason, I don't know why. Maybe that hardware was bad or I used the wrong compiler or something.

Considering hardware issues a

April 5, 2004 - 2:57am
Anonymous

Considering hardware issues all bets are off. I have had RAID 5 arrays lost due to a bad raid controller.

I dont really think it is fair to try to judge a file system when it comes to hardware failures because sometimes you get lucky and sometimes you dont.

As far as me I have lost more data on ext3 than on reiserfs.

In reiser4, the journelling m

March 31, 2004 - 3:38am

In reiser4, the journelling mechanism should be alot better now, because it uses atomic writing, so it either writes or it doesn't.. In the old one they basically had to make a copy of the data for journelling too, so was much slower too.

I also might be wrong, but I heard that unless you have a fast drive, due to the way XFS works, unless you have a fast drive there is a possibility you might lose data.

And for the record, I've been running reiserfs for a few years too (at least 3 now), and have never lost any data (or have never noticed any corruption). I remember hearing that there were a few data corruption bugs in the first few releases of reiserfs, but reiser4 I doubt will have any of those probs because hans reiser is right, they do have more thorough testing scripts to ensure that reiser4 has no such problems.

XFS is *DANGEROUS* unless you have a UPS

March 31, 2004 - 6:16am
Anonymous

XFS keeps stuff in ram to keep things fast. Theres a downside to this, namely, if the power goes so does your data. As for RiserFS, I've only lost data due to a broken harddrive which is hardly the filesystem drivers fault.

Also me. Reiserfs was finer for me than XFS or ext3

August 30, 2004 - 12:32pm
Anonymous

I've lost data more than once using XFS and ext3.
(I use/install linux in lots of computers, and I tried fs).

I only lost data in reiserfs ONCE, and there was a HUGE hardware problem.
I can say that reiserfs resisted against hardware failures really fine. Really really fine.

By now, I would never choose XFS or ext3 for production environment...

(The only parameter I look when choosing a filesystem is the data loss)
(I'm viric at vicerveza.homeunix.net, if someone thinks really different than me and wants to let me know. I encourage that! :) thanks!)

XFS is *DANGEROUS* unless yo

September 6, 2004 - 6:13pm

XFS is *DANGEROUS* unless you have a UPS


XFS caches no more than any other filesystem on Linux.


I've lost data more than once using XFS and ext3.
(I use/install linux in lots of computers, and I tried fs).


I have never lost data to ext3 or XFS and I've been running both for years. XFS can leave NULLs on disk in place of data if the buffers are never flushed to disk, but no filesystem can handle that gracefully every time and if they weren't NULLs they would probably be old data which may or may not be correct.


I only lost data in reiserfs ONCE, and there was a HUGE hardware problem.
I can say that reiserfs resisted against hardware failures really fine. Really really fine.


I've had reiserfs lose data on multiple occasions and none of them were hardware related, putting the data back on XFS or ext3 solved the problem.


And right now I have 2 machines with 1 dying drive each. One is in ext3 limbo right now because of read errors but the system is still running right now, I just turned off ntpd because it was bitching about not being able to update the drift and stats files.


A few months ago I had a reiserfs filesystem on the above mentioned machine and the filesystem got borked in some unknown way. I never figured out what really happened because whenever the system started up the screen would go black and the box would hang, the only way I narrowed it down to reiserfs was to hook up a serial console to see the oops. reiserfsck did absolutely nothing, it said the filesystem was fine which was far from the truth.


By now, I would never choose XFS or ext3 for production environment...


And I will never trust reiserfs in any environment.

pseudo files

March 28, 2004 - 1:28pm
Anonymous

Pseudo files sound interesting [http://www.namesys.com/v4/pseudo.html], but I wonder how you would access them for a directory that contains a real file/directory called "metas"?

Re: pseudo files

March 29, 2004 - 4:38am

pseudo files sound interesting [http://www.namesys.com/v4/pseudo.html], but I wonder how you would access them for a directory that contains a real file/directory called "metas"?

Do directories contain pseudo-files? All the examples I've seen have been plain files. plain-file/metas would not be a valid path otherwise, so there's no problem. But if this is supported for directories, then it sounds like there's a problem...

Re: pseudo files

March 31, 2004 - 6:11am

The problem has been discussed on the reiserfs list. At the moment
there is a conflict, dir/metas/ being reserved, but there are
alternatives and the name will be macrotized.

I think it's pretty thoroughly chewed here

-- 
Markus Törnqvist

so is it in now?

June 3, 2004 - 11:01pm

or when will it be?

....bump

July 20, 2004 - 5:28am
Anonymous

Any news?

I see the benchmarks at namesys haven't been updated in a long time. In fact, I haven't heard anything about reiser 4 in months.

For some info read their mail

July 20, 2004 - 8:52am

For some info read their mailinglist archive, link at namesys.com. They need money, so they do other work than Reiser4 too.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary