Reiser4 Benchmarks
unmadindu writes "Hans Reiser has benchmarked Reiser4 against ext3 and Reiserfs 3. Reiser4 turns out to be way faster than V3, and for ext3, why don't you check out the results yourself ? Hans Reiser states, "these benchmarks mean to me that our performance is now good enough to ship V4 to users", and he will be probably sending in a patch within the next couple of weeks to be included in the 2.6/2.5 kernel."
THis fp sucks.
My one concern is reliability and recovery from failure; I've had a few cases where my belief in ReiserFS has been questioned; however I can't get Ext3 to build on larger than 500GB arrays.
At this point I'd happily choose based on reliability/recoverability/stability not raw speed.
With all of the focus on the latest hardware and graphics, it's good to know that improvements are being made across the board like this. It gives me faith that Moore's law is a long way from failing!
stuff |
Does anyone know if there will be a conversion utility available - i.e, to convert ReiserFS v3 partitions to v4?
This space intentionally left blank.
how can I install this into Redhat9?
If you use Linux, please help development of Autopac
I once used ReiserFS since then never trusted it anymore. ReiserFS looses data, corrupts the filesystem, causes no good things. And if something goes wrong then your binary data in first view looks ok but usually is filled with trash. Even files that are not touched, read, written during 'the bad condition' will be trashed.
If you want to use some serious FileSystem for Linux then continue using EXT2/EXT3 or switch to XFS. everything else is simply a risk.
You may think that I may some standart troll or something but then you should ask yourself why there was a need to rewrite ReiserFS at all. Because there was a requirement to get rid of all these known issues.
hey, I can live with an unstable gnome or Kicq, but a beta filesystem?? no thanks dude!
After reiser4, what filesystems are actually decent competition for it? It'd be nice for OSS to claim not only the best web server (apache), best kernel, and best filesystem.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
I am curious as to whether there are any projects to port Reiser4 to *BSD, particularly FreeBSD 5.x. Does anyone have any thoughts on how difficult a port might be? Can somone more versed in filesystems on *nix enlighten me as to the implimentation differences?
**AA: a bunch of mindless jerks who'll be the first against the wall when the revolution comes
...is mostly funny, but is too much of a company filesystem to trust completely.
In case anybody cares, "strelka" means "arrow", and "belca" means "squirrel"
Wonder what naming system they're using. I use names from Alice in Wonderland.
All these numbers are nice, but I can't make heads or tails of them. Since these are times, I assume lower numbers are better? If so, they why are they usually in red in the report?
Would this increase the speed of a normal system by any noticable amount? Is it worth my time to switch over my EXT3 filesystem to reiser4? Are there programs that can perform the filesystem change for me?
-"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." -EH
The statistics on that page are measured in seconds, no? So larger numbers are worse.
The comparisons are done with [foreign filesystem] divided by reiser4.
One would think that numbers greater than one, where the foreign filesystem has a long running time and reiser4 a short one, would be the ones that benefit reiser4.
Yet the numbers *less* than one are green, where Hans says reiser4 is considered better.
What's going on?
(Incidently, after having a friend lose a filesystem to buggy reiser code, I'm a bit inclined to wait until people have *seriously* hammered on this).
May we never see th
While great, this announcement/benchmark/statement does not mean that ReiserFS V4 is ready for production use, just that it is fast. It needs a lot more bug testing before then, so don't rush out and mass-convert to V4 just yet! See here for the full thread, rather than just the first post...
* Several monkeys are here, playing banjos and wearing small hats.
Is it just me are these numbers meaninless?
:(
Summary:
(BAD)Reiser takes considerable more CPU time.
(NEGLIGABLE)Everything else is a little slower but without them telling me what the measurements for their time numbers it's moot.
picoseconds? milliseconds? Who knows?
What kind of machine? What the hell is a "belka/strelka"? Are these the names of the machines?
Why only 256MB of RAM?
Come on, the test was probably run on a Pentium 133. Why should I assume otherwise?
I'll continue to use ext3 until I see some real stats. These might be it but I need more info than what they gave.
It is official -- Netcraft is now confirming: *BSD is dying
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
How does this compare against say AIX or HPUX's implementation of journaled filesystems?
I realise that it is a bit early to adopt V4, but stable issues aside, which filesystem would YOU choose to for database volumes for fx. Oracle or MySQL?
my sig
How does it compare against everyone's favorite, XFS?
Prescriptive grammar:linguistics
So he's submitting it to 2.6, but what are the chances it'll get submitted? Isn't this what caused all of Reiser's bitching a couple of years ago? He waited to long to get RFS into the kernel and ran into the feature freeze, and then pitched a hissy fit.
.
Anybody know what, if any, features are being added for the laptop user? Last time a checked, journaled filesystems, like ext3, were generally a no-no if you wanted you battery to last.
Maybe a filesystem just for laptop/tablet pc users?
DELETE (time in secs to perform action)
:(
40.13(R4) 0.797 (ext3 journal) 0.837 (ext3)
woo-hoo! now it corrupts my data even quicker
http://milkshake.dexy.org
I know a lot of people will pull their hair out when they hear this, but: Speed is my primary concern. On long compiles of new programs or kernels for example the speed difference on a good FS can be important. I'm not saying that I'm willing to have a FS that corrupts every last file and directory, only that given two FSs which both have seemingly similar stability I would prefer the speed boost.
I have tried one or two of the FSs but I haven't used them for any length of time to be able to compare one against another.
In this note, Hans Reiser clearly states his position: you trade off filesystem metadata performance against data integrity.
Once you realize that this maintains your filesystem structure but turns your files into Swiss cheese (this happened to me several times) you'll switch to ext3 or XFS.
Since reiserfs continuously rebalances the block tree, files that are only open for reading can be trashed by having a block exchanged with the last file written before a crash.
Hans is recklessly pursuing optimization of one aspect of filesystem performance. I honestly believe DARPA should reconsider funding his current track of work.
I can see where your stated "faith that Moore's law is a long way from failing" is "kind of" in keeping with Moore's law...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
The GNAA is a small loose knit group of trolls whose sole purpose is to post retarded shit to various websites. Membership of the group is really irrelevant, but they do have guidelines, which are really just part of their elaborate "troll". Basically, you gotta be a nigger, gay, or both, blah blah. Post an fp for the group and your ub3r l33t, bs ,bs . ...
The cold hard facts about the GNAA
There's nothing gay or black about the GNAA. In fact, the GNAA doesnt have a single gay or black member at all, and most likely never will.
IRC Chat log
(Nws4Turds) pocide
(Nws4Turds) i m teh luv j00!
(koft) yo, st0p b3ing teh gay
(koft) gh3y is teh sux0r
(pocide) i luv u 2 Nws4Turds !, lets felch!
(Nws4Turds) y3s!
(Nws4Turds) pocide
(koft) ph3lch is teh sux0r
(Nws4Turds) i like teh ph3lch
(koft) thats nasty, yall are gay niggers if i ever saw gay niggers
(Nws4Turds) i'm a gay nigger
(koft) stop being t3h gh3y.
(Nws4Turds) actually, i'm a straight honkey
And at this point, Nws4Turds ebraces his heterosexuality, coming out of a "reverse closet" for a brief moment, exposing his inner self. He then feels the need to expound on this idea.
(Nws4Turds) i had sex this morning
(Nws4Turds) it felt good
(Nws4Turds) she came twice
After these statements i was threatened!
(pocide) k0ft: do not even attempt to fr0st
(pocide) not only will YFI but you'd be testin my gangsta and you don't wanna do that, oh no
Following our conversation, my ids picked up a portscan from 24.174.81.26, the address from a user in the channel known as "penisbird".
(pocide) I see your running IIS and exchange. your machine is going down the deep dark anus hole of goatse!
(koft) Damn, i didnt realize that apache and sendmail were part of IIS and exchange... You guys are leeter that i immagined...
Truth: GNAA is a group of wanna be script kiddies who troll on lame message boards like 'Slashdot'
Truth: All GNAA members are white
Truth: None of the GNAA members are gay
Truth: All GNAA members live with their mothers
Don't take my word for it though, check out the lameness for yourself. efnet #GNAA
The room was packed full of naked 14 year old boys. All of them had a number and were waiting their turn. After the boys had stripped naked and had put their clothing into lockers, they walked into the next room. In this room were a bunch of male nurses, who, unbeknownst to the boy, were in fact eunuchs. The nurses took the boys' vital signs to make sure that they were all fit and able to use the Machine. Once they were sure the boy could handle it, a nurse would use a spray-type injector to give each boy a shot. Within 30 seconds the boy's penis would become rock hard. The boy would not loose his erection until the drug began to wear off 8 to 9 hours later.
Once the boy had received his shot he would be taken into the next room to take a number and wait for his number to be called to go into the Machine Room.
As the boy waits, he will notice that the room he is in is rather hot. This room is kept at a higher temp so a boy's balls will become hot and hang lower in the scrotum.
Cody Miller had pulled the number 14. He thought that was kind of cool seeing that he was 14 years old. Just like the old style military draft, Cody had to register on his 14th birthday. 8 out of 10 boys all over the world would get picked to use the Machine, to help keep the birth rate down. Cody thought he was going to make it and not get called, but his luck ran out the day before his 15th birthday.
If he had made his 15th birthday, he would not of been called to use the Machine unless he committed a high crime and sentenced to use the Machine as part of his punishment.
Cody had arrived just after the clinic had opened up and he walked in. A eunuch volunteer talked with Cody and told him what was going to happen to him that day and what he needed to do. Cody, just like 99% of all boys, already knew what was going to happen and how it happened. He had spent the night at Keith's house. Keith was his very best friend who had to use the Machine just 2 days after his own 14th birthday. Keith had let Cody watch the DVD recording of his use of the Machine.
The one thing that Keith did not know was that Cody had sneaked into the bathroom after bedtime and jerked off to a powerful orgasm while thinking of what he had watched on the wide screen TV. Now that is was his turn to use the Machine, Cody was not turned on at all. As a matter of fact he was on the edge of tears. When Cody had taken his ticket with the number 14 on it, he had looked up to see that they were working on boy number 89.
Cody had sat for a while in one of the chairs and had checked out the other 14 year old boys that were in the waiting room with him. Cody was thankful that all of the boys had a hard penis, because Cody knew he would of had a hard cock even without the shot, checking out all the hot looking boys.
Once about every 10 to 15 minutes a nice-sounding voice would call the next number and a door would slide open. The boy with the called number would walk through the door and the door would slide closed faster than it had opened.
As his number got closer to being called, Cody got more jittery. Finally, he could not sit any longer and he walked all around the room. The number 13 was called and Cody saw a very cute blond boy stand up. The blond boy had a bead of pre-cum hanging off of the tip of his 7-inch long, uncut dick and it leaked down his shaft and dripped off of his balls, landing on his foot as he walked to the open door. Cody stood there knowing he only had a short time left and had to put extra into his mental state to keep from crying.
The voice then said Cody's number and the door slid open. It took several seconds for Cody to get his feet to move. He walked into the next room and felt the wind of the door closing on his bare butt cheeks.
A eunuch technician was waiting for Cody. He took Cody's number and led him to a small booth. He had Cody sit down on a seat, and then used a hand to guide Cody's low hanging balls into a hole in the seat. He then guided Cody's hard 5-inch penis
I once used ReiserFS since then never trusted it anymore. ReiserFS looses data, corrupts the filesystem, causes no good things. And if something goes wrong then your binary data in first view looks ok but usually is filled with trash. Even files that are not touched, read, written during 'the bad condition' will be trashed.
If you want to use some serious FileSystem for Linux then continue using EXT2/EXT3 or switch to XFS. everything else is simply a risk.
You may think that I may some standart troll or something but then you should ask yourself why there was a need to rewrite ReiserFS at all. Because there was a requirement to get rid of all these known issues.
I attended Hans' presentation at Linuxtag.
Basically, reiser4 is optimized for the case where you unpack a large tarball, say the Linux kernel, and have enough memory to hold it all in cache, which is true for most of us these days. reiser4 will then choose the optimal disk layout for these files and flush them to disk.
Hans also has aspects of a log structured file system in reiser4, which means you don't write to the file, you write to a log file which basically encompasses the whole disk. The up side is that you mostly write linearly, the down side is that the files get badly fragmented if they are updated at all. Most files are not updated, just written once at installation of the package. The files that are updated frequently tend to be source code from CVS, which are small enough to fit in memory completely and have reiser4 choose an optimal disk layout again.
The case where this model completely sucks is the case where you update many portions of a large file. For example, running an SQL database with files on a reiser4 file system as backend, or maybe a DNS server with DDNS, or a berkeley db backend for Postfix or qmail to keep the SMTP AUTH users or something. Also, log files will probably be badly fragmented.
Hans proposes to have something like a transparent defragmenter running in the background, which he calls "repacker". This would run in the kernel space, as part of the file system, and defragment badly fragmented files that are accessed frequently. This would solve most of the down sides of his approach, but this repacker is not finished yet.
My personal view of reiser4 is: it looks like it is optimized to perform well in benchmarks. It tries to be fastest for updating databases, but buys the performance by being slower when reading the data afterwards. The critical question is whether the repacker can alleviate these concerns, and as long as it is not finished, reiser4 is basically out of the question except for a little testing here and there. I reckon reiser4 would be a great filesystem for keeping your mozilla and gcc CVS checkout handy. But until the repacker is done, I will not even use it for testing, because the repacker really is the crucial component that makes or breaks this.
By the way: my previous experiences with reiserfs were less than stellar. Some people call it shredderfs instead. The main complaint with reiserfs is and always was that the fsck is not nearly as trustworthy or stable as the one from ext2/ext3. So even if I use reiserfs at all, it's only for data I can afford to lose completely, like my CVS checkouts or the squid cache directories or something like that.
The benchmarks do look good though, and I am glad that at least someone is still trying major innovations in this area. Since most Unix vendors or divisions are no longer profit centers, file system innovations have largely stalled or moved to specialized companies who regard them as proprietary (Veritas) instead of releasing them as free software like IBM and SGI did.
I know ext2 isn't a journal fs, but it would still be interesting to see a direct comparison again reiser4.
Marge, get me your address book, 4 beers, and my conversation hat.
WARNING!!!!!!
ReiserFilesystem trashes your data!
WARNING!!!!!!
It's still not time to swap it for ext3 for general use.
The first table with the mixed file sizes is the most compelling. The fact that reiser4's Create and Copy times are less than a third of the ext3s in real_time is impressive.
But the fact that the CPU consumption on Read is double that for R4 as it is for ext3 is a serious problem. On a 1.3 Ghz machine saturating a generic UDMA 100 60G bus on RH 9.0 it's about 10% of the CPU, so the home user might not care. For a system capable of delivering serious data (like a 4 drive, 15k rpm SCSI RAID array @~3 times the read throughput) going from 30% CPU to 60% CPU usage is a definite problem. Even with a 2.6 Ghz cpu it would still move from chewing up 15% to 30%. I know these numbers don't scale exactly, but they could in fact scale ugly depending on how much CPU is dedicated to communicating with the hardware and how much is in fiddling with the filesystem. My production boxes spend > 80% of their disk activity reading, so I'm not yet inspired to go out and spend the time running benchmarks on highperf. systems just yet.
Nevertheless, I always admire it when a new version of software comes out and it's noticeably faster than the old
That would be interesting.
Not only that, but this 'Han' guy has even achieved getting his 'Reiser' to promote his FS' performance on Slashdot.
Silly apostrophes.....but however remember that both have different strong points:
XFS is especially good in dealing with large(and when I say large I mean *LARGE*) files, and IIRC, the all idea behind the Reiser filesystem is to deal with small data objects.
Anyway, it'd be interesting to see such a benchmark as XFS has the reputation of one of the best(the best???) fs to be used with high hard-disk I/O-s and even higher system loads.....
1. No sig. 2. ???? 3. Profit!!!
Apple benchmarked their new G6 processor against the latest 10 GHz Pentium V. They say that despite its lower clock speed, it runs their suite of PhotoShop 8 filters almost four time faster than the Pentium.
Seriously, Hans Reiser is benchmarking his own file system, and he's using benchmarks that make his system look good. Like the SpriteLFS, his filesystem has a log structure for sequential writing, which makes it look really good in tests like he performed where you write the files once.
Compare a database load, where you write small chunks of big files all the time. Without the repacker (like the cleaner in LFS), the disk becomes horribly fragmented. With the repacker, you have to include the slowdown of this background process defragging your hard disk. Ick.
I'll trust his benchmarks when he presents a final, stable release, with the repacker on, and tests it under workloads such as would be encountered on a server. I might use it on my homebox even if it sucks on a server, but it would be nice to know that he considers his structure's impact on other workloads.
I hereby place the above post in the public domain.
Didn't linus say no more new features at this point? Didn't Reiser try this same damn thing last time, fighting with the kernel people to get his stuff in after the feature freeze?
Need Free Juniper/NetScreen Support? JuniperForum
ReiserFS is very fast at writing large numbers sub-blocksize files, granted, but has anyone out there ever gotten its filesystem recovery tools to run 1) faster than ~1 hour/GB/1000BogoMIPS and 2) without crashing near the very end? In other words, in the (ostensibly unlikely) event that ReiserFS screws up and you do have to check its consistency, is there any way to do it? My experience has been to the contrary several times now, and I end up having to rebuild the entire FS. Fortunately I'm fanatical about keeping backups, so I can afford to do this; I certainly wouldn't recommend it to anyone who wants to maintain filesystem integrity, but the speed is breathtaking.
of course if you've got a cluster of 100 machines that are all doing the same things and you can even make the app go 5% faster by a different filesystem, that can be a saving of $20,000 or so.
I'm not putting thousands of files in a single directory. I'm not using tons of small files, and my hard drives are more than big enough to hold my data. Is there any reason to use reiserfs instead of ext3?
BEWARE FROM REISERFS!
If you have important data for your private usage or your company then
DO NOT
use ReiserFS.
> > they would just hit the reset button
>
> I've found users doing that to my servers before now. I find
> that hitting them on the nose with a rolled up newspaper and
> shouting "No! Bad monkey!" in a stern voice tends to stop this
> behaviour...
Even better: configure the services that the users use so that
they don't start up at system start. Write a short script that
starts them all, and whenever you restart the server ssh in and
run it. That way, if users cold-reset the server, nothing will
work until you fix it anyway, so you might be able to break them
of that habbit then. (Otherwise, they'll just do it behind your
back and not tell you; this way, they HAVE to come to you.) The
only internet service that needs to start at system start in such
a setup is sshd, and with that you can start up everything else
from anywhere easily.
If you have any coworkers (or underlings) clueful enough to handle
a shell prompt, you can train them to ssh in and do a _proper_
restart, and tell them how to start up all the services by running
your start-services script.
One more option: you can disconnect the reset switch. However,
that won't stop them from just unplugging it, which I've found
myself doing to Win9x systems when the reset switch does nothing,
or on some Linux systems when shutdown -h doesn't turn off the
power when it's finished, if there's no real power switch other
than the on-only kind a lot of newer cases sport.
So, just fix it so that doing Bad Things (like power-cycling)
doesn't achieve perceived positive results.
Cut that out, or I will ship you to Norilsk in a box.
Actually, come to think of it, he still doesn't know that until he switches the root across- a journalled disk operating system doesn't usually guarantee the contents of the files, only the metadata (although you can sometimes configure it), so it may very well be that it doesn't make much difference.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"The first thing that popped into my head when I read that was "uh... feature freeze two weeks ago." I'm sure Reiser's going to have another of his babyish hissy fits. I see another slashdot story in the near future.
<Reiser> Oh, what about my sponsors! Why are you all playa hat'n on me?
<EveryoneNotOnTheReiserCheerleadingSquad> You don't get special treatment. You waited too long, and we're not putting your untested code into a frozen code base.
<Reiser> You're oppressing me! The GPLv3 will fix you all!
<SomeoneFromFSF> Please shut up, Reiser. You still don't know what the fuck you're talking about.
<Reiser> Wahh!! My sponsors!
<Everyone> SHUT UP REISER.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
What about upgradablity? The nice thing about ext3 is that upgrading to a new
version is a reboot away. With ReiserFS, you had to re-format the drive, in
order to upgrade. Has this changed?
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
I used Reiserfs several times since it got advertised over and over as a good os.
But sadly, ReiserFS didn't recover my files to a working state after my disk half way crashed.
I could do nothing to get the data back. damn i was happy to have some backup of the living data, so i just needed to reinstall my linux.
but this time i decided for XFS. And for some strange reason, the disk crahsed again. but thanks to the recovery tool of xsf, i just ran it once, and all my data were back up working.
so i'm sceptical about reiserfs, but might be reiserfs4 will be better!?
reg.
Anonymous Coward
It nice to see that SCO is planning to relase an excellent feature for Unix. This should allow Unix to make better in roads with large companies like IBM. Looking forward to buying an license to run Reiser4.
Keep up the good work SCO, and keep those new invoations comming.
XFS is good. We've used it for years and years on SGIs without fail.
file system performance under soft realtime constraints is of major importance for the linux audio users crowd... how does RFS4 stack up in this regard? is it a priority for the development team?
Why must we make nouns into verbs. "Benchmark" is not a verb. Instead, the person could have used 'compared' or 'tested against.'
Remeber kids, verbing wierds language.
I just wonder who will be first to declare this their IP; SCO or MS?
I don't understand it. In first table there is comparision between reiser4(A) and ext3(C). Big numbers in C/A are red, small numbers in C/A are green. Small C/A means that ext3 is faster than reiser4. So green color is bad for reiser4.
But in next table A is reiser, and B is reiser4. So B/A is small and green when B is faster. So this time green is better for reiser4.
Am I only person confused?
Just wondering :)
Your statement is missing arguments...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I have done filesystem testing and find that when comparing Reiser and EXT3, it is unacceptable to omit XFS and somewhat JFS (which is robust, but a little slow.) Most people forgo in both EXT3 and Reiser the features that slow things down a bit but are more durable in a failure situation. With XFS I get the full protection of the filesystem while enjoying great performance.
XFS is by far the most durable, mature [given a long history inside IRIX] and featured of the Linux filesystems. I also am quite annoyed that RedHat doesn't make it easy to facilitate XFS right out of the box (rootfs support). They merged everything else in there, but somehow seem to favor ext3.
About the only thing I miss when using FreeBSD is XFS. While UFS2+S is robust and very quick, XFS is still my favorite.
I am also offended by RedHat that baits and switches a community by having popular (5.2/6.2/7.1-7.3) versions for free, then they start charging for this Advanced Server product on the same order of magnitude as Microsoft software [RH-AS is over $1000]. RH 8 and 9 are embarrassing. I obtained a copy of RH-AS, and the up2date feature doest work without a subscription, and the RPMS are not distributed in binaries. I'm glad there are several projects to replace up2date server for RedHat. All these problems on an OS that cant even be bothered to support XFS root filesystem.
FreeBSD is still Free. Thank goodness.
Legalize the constitution. Think for yourself question authority.
I have some questions abou ReiserFS and was wondering whether someone out there would be able to answer them.
.../customers/0001/name .../customers/0001/phone .../customers/0001/agent -> .../personnel/0021
First off, there's this stuff with ReiserFS storing fine-grained data. Does this imply that using ReiserFS (v3 or v4) directly as a database would be efficient? I know RFS doesn't have Relational features, but these might very easily be implemented in userspace if you can store e.g.:
(...etc.)
Am I losing this or getting this???
My other question was about this metadata-as-file thing. Hans can implement whatever he wants, but it just so appears that Linux behaves like Unix. I've just made a ReiserFS partition to check, and there's no way I can "touch foo; ls foo/" to see e.g. permissions etc.
Now I'm aware that this might be v4 stuff, but I wonder if anything of this is ever to be seen back in Linux userland? E.g., will it be possible for projects to use ReiserFS to change the paradigm used for metadata using a straight Linux kernel?
See, from time to time I just happen to be quite impressed with the "everything is a file" applied to metadata, and I hope we can make the shift to this future one day, and finally get rid of file extensions, MIME guesses and app association registries in Linux, and store this stuff in metadata space.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
You wouldn't happen to have a URL from which one can obtain "convertfs", would you? Google is stumped.
That's why you don't like it deep down.
If it was called abc3 or ext4 you would be an avid supporter, too.
Heh. Don't worry, I'm not an antimac troll. I have an eMac at college, and my family might get a G5. I believe that their benchmarks are at least close to reasonable this time around.
Their past ones, for the later G3 and the G4, were total bullshit. The computers were good, but fast they were not. And Apple kept pulling all these specialized benchmarks out to make them look faster. Clock speed may not be the be-all and end-all, but it is still important, and the G3-G4 were sorely lacking.
Now, on RISC vs CISC, you are just plain wrong. Both architectures have their advantages and disadvantages. CISC is not inherently slower or hotter. Just look at the Transmeta Crusoe proc. It used VLIW, which can be viewed sort of like CISC to the extreme, and it was really efficient and pretty fast too. (This is sort of a stretch; VLIW shares some of the benefits of both RISC and CISC, but still, CISC does some things very well). I personally prefer RISC because it's easier to code for, but that only matters if you're writing compilers or firmware.
In terms of laptops, while the G5 runs cooler than a Pentium, it still runs quite a bit hotter than the G4 and especially the G3. You most likely don't need that sort of power in a laptop, unless you're gonna replace your desktop with it. I doubt Apple will come out with G5 laptops for some time. The best proc to get in a medium-fast laptop would be the Crusoe for its high efficiency, but consider a G3 or a VIA cool-running X86.
I wonder how cool and power-efficient Intel or IBM could make a laptop proc if they didn't push for insane clock speeds. I'd be perfectly happy with a cheap, power-efficent laptop running at 500 MHz x86, or even less with a G5-like system. The keywords being cheap and power-efficient; I'd just use it for email, programming and web anyway.
I hereby place the above post in the public domain.
Having used and tested about every file system, I have been using XFS exclusively even for my customers. Ext2 is solid but not good for production machines which need to be able to reboot without a manual fsck (this is why we started discussing journaling file systems in 1997 after all). ReiserFS managed to shred some of my files on root filesystems. Ever had a file which you could not delete without the rm command going haywire? Since then, I've been using XFS even on the largest RAIDs without any problem.
But let's wait and see how fast and stable reiser4 is once it matures into the stock kernel.
open (SIG, "</dev/zero"); $sig = <SIG>; close SIG;
The drivers are crap, and the box dies about every week or so
You should call the server "Kenny"!
As in Southpark: Oh my God you killed Kenny!
From excellent karma to terible karma with a single +5 funny post...
It would be a very, very silly idea to put your journal on flash. It's a small block of space that gets repeatedly written and rewritten by lots of small changes, pretty much every time any file changes. Precisely the usage pattern that would wear down a flash chip in the shortest time.
The only sensible places to put a journal are (1) on (fast) magnetic media (2) on battery backed RAM.
I work at an ISP and I can give you our data points.
ext2/ext3 filesystems trashed beyond repair : 4-6 per year
XFS filesystems trashed beyond repair : 3 (100% failure rate at which point we stopped using it altogether)
reiserfs filesystems trashed at all : zero
NTFS filesystems trashed at all : zero
At this point we have 90% of our systems on reiserfs and have zero trashed data or filesystems.
Shrug.
The core XFS might have been mature in IRIX but it most definitely is not in Linux.
XFS is still not a fully linux-native fs, it is IRIX code pasted into Linux through a special translation layer. And thats where most of the problems arise, as it has to translate IRIX-isms to Linux-isms.
The real question is if linux will accept this into the 2.6.0 kernel or not. I thought that a feature freeze had already been set, although if it is for something as siginificant as reiserfs which obviously has been put through extensive tests, then he may reconsider. If not I guess we could patch it ourselves or wait for 2.6.1
History will be kind to me, for I intend to write it - Sir Winston Churchill
Being a Windows dork, all this talk of multiple filesystems and how you lost this and that on ext3 and how reiser corrupts your data, and formatting many different FS's on one box to balance/optimize these risks, I have to wonder, are these file systems really significantly faster than say NTFSv5?
I've not had any corruption or loss issues on NTFS even with hard powering off the system during a write (except for the particular file in write or the particular change not completed) but it's not writing my WMA over my NTOSKERNEL.EXE or anything funky like that...
The most i've done with FS though is change my block size on my video editing drive for better large file streaming...
For a file system, what is considered the most stable/reliable FS out there that doesn't suck horridly performance wise?
....live us hobbyist home linux users. I've read "million files this" "lost that" and other grandiose comments but what benefits/pitfalls are there for us home users? As an OS choice I use SuSE with an ext3 filesystem and I've had no problems (touch wood) yet but I am interested to know what benefits, if any at all, exist for single machine users of Linux and the Reiser filesystem?
I've noticed that everyone who is for abortion has already been born - Ronald Reagan
or just sometimes...?
most of us weren't born w/ cat500 up our butts..
So, Hans is doing it again. Why does he have to push a new ReiserFS release every time a new stable kernel series is about to begin?
I predict ReiserFS v5 will be out about at the same time 2.8 or 3.0 ships.
*BSD experienced moderate success about 15 years ago in academic circles. Since then it has been in steady decline. We all know *BSD keeps losing market share but why? Is it the problematic personalities of many of the key players? Or is it larger than their troubled personalities?
The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.
User: Um, I rebooted the box. Er, was that, like, okay?
You: Und so... Ve haff earned ourzelfs ein timeout in "The Box", hein?
User: Aiiieieieieeeie!
You: Mua-ha-ha!
[Fade to black]
I like the UFS2 FS for FreeBSD. Its stable but a little sluggish. I think it would be cool to have internal competition but the MS GPL == viral crap has made a dent into the BSD developers. They fear linking to anything gpl would make their kernel gpl as well.
Anyway this is just a pretty please with a cherry on top. Especially since you are being paid for by grants from DARPA who use Solaris, Linux, FreeBSD, and every Unix os under the sun.
http://saveie6.com/
>> ...we also have some 3Ware cards we could try if the new Promise drivers don't do the trick. ;).
>>
>
> What are you waiting for! You'll be trying the 3ware cards in a couple weeks almost guaranteed
Is that a promise?
include $sig;
1;
ReiserFS is really good at some things (and I actually recommend it for some things) but for my main system filesystems, I find that Reiserfs lacks some of the things that EXT2/3 has that are very useful--
File attributes including things like "Append Only" although these can also be ways of screwing up your system (who'da thunk Qmail doesn't like append-only log files?).... See man chattr for more info....
So I am happy to use it for directories where I don't have special needs for the filesystem, but for others, I have to still use ext3.
LedgerSMB: Open source Accounting/ERP
With FreeBSD for example, GNU Floating Point emulation is available, however, to comply with the GPL terms and conditions, they don't distribute it precompiled into the default kerne, thus, one needs to manually compile it into the kernel if one needs it.
If there were to be a move by FreeBSD, they would have to firstly make a ported module then an application which would convert the filesystem from UFS to ReiserFS. Being a complicated and risky process, I can't see it happening.
The last question would be, of what benefit would it bring to FreeBSD when there is already and adequate solution, UFS2, sitting there ready to be used.
With that being said, there is nothing stopping the FreeBSD community from making a clean room implementation of ReiserFS 4 using brand new, original code, simply based on the ReiserFS documentation and specifications.
"The difference between pornography and erotica is the lighting" - Woody Allen
I've done some benchmarks and reiser won in terms of speed against ext3 and jfs. Haven't tested with ext2 or xfs yet. Here are the reiser vs jfs results for writing data onto a reiser/jfs partition:
# jfs write
real 7m51.178s
user 0m1.980s
sys 0m57.710s
# reiserfs write
real 6m7.302s
user 0m1.780s
sys 1m16.590s
Also I haven't had problems with it but then again, I'm not using reiserfs on RAID arrays in heavily loaded mission critical environments or anything like that.
I hope that reiserfs4 would allow data integrity checking and not only metadata. Also allowing to have the journal hold on a separated partition. IMHO current reiserfs3 is very dangerous, as in case of system blackout you get files corrupted, and the system doesn't boot anymore. I sometimes got junks into system files in this situation. E.g. junks coming from log files goes sometimes into system files like /etc/modules.conf, and so the system
doesn't boot anymore with the proper drivers...
(imagine it doesn't insert the ethernet
driver). Who cares about having a fast filesystem
if you get junks even in file readonly file?
Bye.
I'm wondering if this would be a benifit for me.. I like to play with video, but I'm not rich, all I have to play with is a mediocre 900Mhz processor, 512MB ram, 3x80GB+1x40GB (241GB used...) drives LVMed into one large ext3 volume. I mainly use it to store video sequences, many (thousands) ranging in size from 100MB to 600MB (with some >1GB files now and then).
;).
I was using ext2 previously till I had to sit through one to many fsck's
So, will Reiser4 be any more useful than ext3 in my case?
Sig? What sig?
I've been beating my SuSE box mercilessly with software development, web servers, print serving, Oracle, Sybase, DB/2, and Postgres for about a year now. Absolutely no problems with any of the ReiserFS data partitions.
Ext3? No thanks -- it just doesn't strike me as a clean design. Maybe XFS on the next box, but not for any reason other than trying it out.
I do not fail; I succeed at finding out what does not work.
I've seen the warnings on ReiserFS, about using shred to delete.
So how do you securely delete data using ReiserFS, or Reiser4, or any other journaling filesystem, whether it is meta-data only, or all data?
An argument has been going on at one of the distro mailing lists. It basically boils down to this:
ReiserFS, currently, requires a reboot after the filesystem is installed, but prior to completion of the installation of the distro, does it not?
I know that this was a requirement earlier. Whether this was "fixed", or the reboot requirement was removed in a subsequent update, I do not know. But I do remember reading this at the Reiser site, and elsewhere. I also remember reading that the reboot requirement would be removed with Reiser4. Whether this reboot requirement has been removed somewhere in the 3. series, I do not know.
The distro authors have justified their non-reboot installation by saying that it is not required under Suse either. I remember reading elsewhere, though I can't remember where, that Suse had developed specific patches to Reiser 3. series to eliminate the reboot requirement, and a comment was made as to a hat tipping or something similar, to the coding abilities of Suse.
Since I can't find the above information, and can't remember where I read it, the concerns have been dismissed. But the reboot issue has cropped up again on the list.
Other than Suse, does the current, ReiserFS, the versions prior to Reiser4, require a reboot? If not, starting at which dot release has the reboot requirement been removed?
And thanks for a great filesystem! I use it for everything.
As a side note, one or several distros require to dump everything into
what the settings should be, tail, no tail, byte size, etc., when using raid 5 across disks? Or other raid numbers?
Is there a guide for newbies? I've read all the documentation on the Reiser site. And the man pages. But I can't figure out what should be the correct settings when installing the filesystem.
I'm using adaptec's card, the ide version capable of raid 5. I'm sure others would be interested in their own cards.
I know that there are different recommendations depending upon implementation, so how about a short guide, or man page, that lists, file server, raid 5, file server raid 0, web server raid 5, web server raid 0, heavy video editing raid 5, heavy video editing raid 0, etc., use tail, no tail, byte size:, and any other options I can't remember right now.
That would help a great deal!
Thanks again for a superb filesystem!
Thanks. Now I can consider writing a filesystem-based backend to my PHP-based object data storage thingy.
;-)
Not to be nitpicking, but I was wondering whether the "filenameX/..owner" syntax already has been decided upon. I just happen to think it's not all that beautiful (really just a matter of taste) to have all these metadata files together with other dotfiles in every directory. Although the common solutions for HFS/ AppleTalk on UNIX systems don't really seem to suggest anything better. The OSX approach is dubious because it's actualy two approaches in one (reserving the "rsrc" filename and the "..namedsource" filename for just about the same purpose). One advantage is that at most you're faced with these two special files inside a normal directory(?), and not e.g. 20 different ones ("..user", "..group", "..access", etc.).
In an ideal world, you should be able to open a file or directory with a mode ("data", "metadata", and maybe even "directory"), and have the accompanying command line utils for this. But this of course doesn't fit in well with the current UNIX/ ANSI C approach of things. Of course, treating normal files as directories is a nice alternative, but the problem lies within the metadata for directories, which will still be visible as any other normal (hidden) file.
Hey, I realize that you have probably already given this stuff some thought, but anyway
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
just some days ago a xx Gb reiserfs partition with
~4 million files decided to be partly unaccessible,
the disc reads first 1/3, however last 2/3 of
part is sectors unreadable - hardware fault
a way to get at least the good data back?
...Yes, there is more than one of him.
CAn'T CompreHend SARcaSm?
all the psuedo-files like ..user and ..access are hidden, so you're not going to see them in an ls -la, even if you wanted to. To get a list of all the psuedo-files for a particular object (directory or file) you just cat objectX/..psuedo
Have a look at the docs.
How we know is more important than what we know.
very informative, thanks.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Yeah and it'll make you go blind too!
It's fast when it's all 0's. Real data is a bit slower than ext3.
What are plug-ins for a filesystem?
Why are they such a great thing?
"Provided by the management for your protection."