Slashdot Mirror
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."
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
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.
"Because there was a requirement to get rid of all these known issues" then you're admitting that they're gone, so why the hell are you bitching about it? something was wrong, it was fixed. wow...that makes it...bad...guess ill change my 60gb partition to ext2 cause of that!
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.
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
In addition what apps is he running in the background? Is this while he's ripping and encoding CDs?
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
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.
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!!!
Netcraft says there are 2 million websites using freebsd.
Could you do the math for that too.
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.
Yes, praise the Lord Jeebus Almighty for our good, wholesome, heterosexual FileSystems! Hallelujah!
I've been running ReiserFS for 36 months without issue. Can't say the same for JFS, XFS, ext2, or ext3.
That may be true, but your statement would still be true even if you never tried any of the other filesystems...
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?
> > 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 is important that you use a distro that bases their kernel on 2.4.18, or later, when using ReiserFS. There exists a distro that bases their enterprise server kernel on 2.4.9, and intentionally declines to add any reiserfs bugfixes since then. (This is the same distro that once shipped their kernel with the ReiserFS debugging code turned on so that we would go slow.) Do NOT use their kernel with ReiserFS. Generally when someone reports that they are having really bad experiences with ReiserFS, it turns out they are using that kernel.
I generally recommend using the latest official kernel from Marcelo, and not any distro kernels, but the SuSE kernels tend to have effective ReiserFS support also, and not everyone out there shares my non-technical preference for a common community developed kernel.
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.
Pretty conclusive. 2.4.9 is also pretty ancient by now. Are these people afraid of new kernels?
I always do my own kernel from the sources at the
end of an installation. It avoids just so many problems and you can do thinks like monolithic kernels.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
I tried all of the different filesystems, under different kernel versions. They either weren't soup yet, caused stability problems, or performance bottlenecks.
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?
I certainly hope so, since I'm using SuSE myself, and ReiserFS is the default filesystem.
As a side issue, it'll be interesting to see how the plugin-part of ReiserFS V4 will be used. Do you know of any concrete plans to use this feature?
No Red Hat isn't afraid of kernel upgrades.
Red Hat is providing an ABI guarantee that Linux normally doesn't provide though.
Specifically, other vendors (Oracle, Veritas, IBM, etc) have kernel modules compiled specifically for the Red Hat enterprise 2.4.9 kernel.
Red Hat has committed to keeping the source and binary interfaces stable and compatible for the duration of the 5 year life cycle of Red Hat Linux.
Updating the kernel would break all of that.
BTW, yesterday Red Hat released a beta of the RHEL 3.0
....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
> There exists a distro that bases their enterprise server kernel on 2.4.9,
> and intentionally declines to add any reiserfs bugfixes since then.
Seeing that they don't ship or support ReiserFS, that's understandable.
Enterprise customers are not interested in toy filesystems (ie. V3). I'm sure
that will change when V4 is stable.
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.
"There exists a distro that bases their enterprise server kernel on 2.4.9, and intentionally declines to add any reiserfs bugfixes since then."
:-)
: //www.rootshell.be/~krang/
Redhat AS 2.4.9 kernel mustdie
http://www.excom.ru/~andrey/windowze.html
http
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."