Slashdot Mirror


New Ext3 vs ReiserFS benchmarks

An anonymous reader writes "Saw this new benchmark on the linux-kernel mailing list. Although NAMESYS, the developers of ReiserFS has many benchmarks on their site, they only have one Ext3 benchmark. The new benchmark tests Ext3 in ordered and writeback mode versus ReiserFS with and without the notail mount option. Better than expected results for Ext3. Big difference between ordered and writeback modes."

191 comments

  1. REPLY WITH PR0N! by Anonymous Coward · · Score: -1, Troll

    Reply to this FP with pr0n to claim it!

    -DFW - Banned!

  2. The results are in by l33t+j03 · · Score: -1

    Windows file systems blow them both away. Try again next time geeks.

    1. Re:The results are in by baxshep · · Score: 1

      Why do you troll so much? Are you really that bored? I won't even bother sending you benchmarks.

  3. booyah by on+by · · Score: -1

    Ifthedesignersof X-Windows built cars, there would beno fewer thanfive steeringwheels hiddenaboutthecockpit, noneof which followedthesame principles-- but you'd beable toshiftgearswith yourcarstereo.Useful feature,that.

    - Marus J.Ranum, Digital Equipment Corporation

    X-Windows istheIran-Contraof graphical userinterfaces:atragedyof political compromises,entangledalliances, marketing hype, and justplaingreed. X-Windows isto memoryas RonaldReagan was tomoney. Years of"VoodooErgonomics"have resultedin anunprecedentedmemory deficit ofgargantuan proportions.Divisive dependencies, distributed deadlocks,andpartisan protocols havetightenedgridlocks, aggravatedrace conditions, and promulgated doublestandards.

    X has had its share of$5,000 toiletseats-- likeSun'sOpen Lookclocktool,whichgobblesup 1.4 megabytes ofreal memory! Ifyousacrificed all the RAM from22 Commodore 64s toclocktool,it still wouldn'thave enoughto tellyouthetime.Even the vanilla X11R4 "xclock"utilityconsumed 656Kto run.AndX'smemory usage isincreasing.

    X:TheFirstFullyModularSoftware Disaster
    X-Windows started out asoneman'sprojectin anoffice onthefifthfloorof MIT's LaboratoryforComputer Science.Awizardly hacker, who was familiarwith W,awindow systemwrittenat StanfordUniversity aspart oftheVproject, decided towriteadistributedgraphicaldisplayserver.Theidea was toallowaprogram, calledaclient,to run ononecomputer and allow itto display onanothercomputer thatwasrunningaspecialprogramcalled a windowserver.Thetwocomputersmightbe VAXes orSuns,or one ofeach,as longas the computers werenetworkedtogether and eachimplementedtheXprotocol.

    [Footnote:We havetriedto avoid paragraph-lengthfootnotesin thisbook,butXhasdefeated usby switching the meaning ofclient and server. Inallotherclient/serverrelationships, the serveris the remotemachinethat runstheapplication(i.e., the serverprovides services, suchas databaseserviceor computational service). For someperverse reasonthat's betterleft totheimagination, X insists oncallingtheprogramrunningon the remotemachine"the client."This program displaysitswindowson the "window server."We'regoingto followXterminologywhen discussinggraphicalclient/servers.So whenyousee"client" think "theremote machine where the application isrunning,"andwhen you see "Server"think"the local machine thatdisplays outputandacceptsuser input."]

    The NongraphicalGUI
    X was designedto run three programs: xterm,xload, and xclock. (Theidea ofawindow manager was added asan afterthought, and itshows.)Forthefirstfewyearsof its development atMIT, these were, infact,theonly programsthat ran under the windowsystem.Notice thatnone oftheseprogramhave any semblance ofagraphicaluser interface (except xclock),only one oftheseprograms implementsanything inthewayof cut-and-paste (andthen,only a singledata typeis supported), and noneof themrequires a particularlysophisticatedapproach tocolormanagement.Is itanywonder,then,that these are all areas inwhichmodern X falls down?

    Ten years later,most computers running X run justfour programs: xterm,xload, xclock, and a windowmanager. And mostxtermwindowsrunEmacs! X has tobe the mostexpensivewayever ofpoppingup anEmacswindow.It surewouldhave beenmuch cheaper and easierto put terminalhandling inthekernel where itbelongs, ratherthan forcing peopleto purchaseexpensivebitmappedterminalsto run character-based applications. Ontheotherhand,then users wouldn'tgetallof those uglyfonts. It'satrade-off.

    The Motif Self-AbuseKit
    X gaveUnix vendors something theyhadprofessedto wantforyears: a standardthat allowed programsbuiltfordifferentcomputersto interoperate. But itdidn't givethem enough. X gaveprogrammersawayto display windows and pixels, but itdidn't speak tobuttons, menus,scroll bars, oranyof the other necessary elementsof a graphical userinterface. Programmers inventedtheirown. SoontheUnix community had six orso different interface standards.Abunchof peoplewhohadn't written 10linesof codein asmany years set upshop inabrickbuilding inCambridge, Massachusetts,that was the formerhome ofafailed computercompanyandcame upwith a "solution:" the OpenSoftware Foundation'sMotif.

    WhatMotifdoes ismake Unixslow.Real slow. A stateddesign goalof Motif was togive the X WindowSystem the windowmanagement capabilitiesof HP'scirca-1988 windowmanagerandthevisual eleganceof Microsoft Windows.We kid you not.

    Recipefordisaster:startwith the Microsoft Windows metaphor, which was designedandhand coded inassembler. Build something ontopof three orfour layersof X tolook likeWindows. Callit "Motif."Nowputtwo486boxesside byside,onerunningWindowsandonerunningUnix/Motif.Watchonecrawl. Watch itwither.Watchit dropfaster thantheputsch inRussia.Motifcan'tcompetewith the Macintosh OSor withDOS/Windowsas a deliveryplatform.

    1. Re:booyah by TheSpoogeAwards · · Score: -1

      Thank you. That made my day.

    2. Re:booyah by cyphixation · · Score: -1, Troll

      i have really enjoyed reading the first third of this
      post and would have continued, but this
      stupid shit made me stop.

      Seriously, post this again..with out the shit. i really
      want to read it....'cause i'm not writting any damn script to fix it myself. i'm busy drinking.

      --
      odium|||nunquam|||obticesco
    3. Re:booyah by on+by · · Score: -1

      see my other comment for a link to the entire thing... it's just above yours... hth

    4. Re:booyah by cyphixation · · Score: -1

      off to check it. thanks again.

      --
      odium|||nunquam|||obticesco
  4. Benchmarks by prof187 · · Score: 0, Insightful

    Granted, you can get some stuff from benchmarks, but I don't really believe them anymore. I mean, you can make a benchmark look good for you by simply using programs that run well w/ it. Don't take this as Linux bashing, because it isn't. I'm just saying that I don't trust benchmarks that much anymore.

    --

    My other sig is an import.
    1. Re:Benchmarks by Anonymous Coward · · Score: 0

      You need to see 3rd party benchmarks w/ no influence for either side. Other wise Intel says their chip is better and AMD says theirs happens to be while a 3rd party like (insert your fav hardware reviewer here) shows real world tests pitting them head to head.

    2. Re:Benchmarks by fliplap · · Score: 2

      Forget reading the article, did you read the Slashdot posting? Lets see,

      First problem: They weren't trying to make anyone look good, this was a 3rd party test.

      Second: Why would they try to make anyone look good, neither of the "products" tested are for profit projects. They have nothing to gain from false benchmarks.

      Third: How could that be taken as Linux bashing? Both filesystems are linux only, they aren't being compared to anything non-linux nor are you comparing them to anything non-linux.

      Please read both the article and posting before you take the "How to post" (early and often) of slashdot very seriously.

    3. Re:Benchmarks by Anonymous Coward · · Score: 1, Informative

      Does it seem odd to anyone else that *reading* the ext3fs has a 4X performance gain for writeback vs ordered?

      Since ext3fs writes in a way compatible with ext2fs, shouldn't you get (at least somewhat close to) the same speed reading it nomatter how it was written?

    4. Re:Benchmarks by Anonymous Coward · · Score: -1, Flamebait
      I rememember one laughable episode from recent history. Various operating systems were tested "out of the box" to see which fared best. As with most good competitions there were winners and losers. The funny part is that the losing operating system's fans whined and cried like baby children and demanded that their system receive professional configuration and tweaking before it was benchmarked. They demanded a "do over".

      Of course, the whole point of the benchmark was "out of the box" to begin with, so a professionally configured "do over" by one participant queers all the results. What were we supposed to conclude from such a bogus methodology?

    5. Re:Benchmarks by Bitter+Old+Man · · Score: -1

      That Linux users are all braindead fags? And you were surprised?

    6. Re:Benchmarks by vadim_t · · Score: 1
      Actually, ReiserFS does produce a profit. Look at their web site. ReiserFS is licensed under the GPL and free for anybody to use. But if you want a feature you can pay them and they will write it for you. Then it will be available for everybody for free.

      I agree with the rest of your points though

  5. Anyone care to explain ordered mode? by glrotate · · Score: 1, Interesting

    I think I know what writeback is (like with cache?), but can anyone explain ordered mode?

    1. Re:Anyone care to explain ordered mode? by *xpenguin* · · Score: 4, Informative

      Your question is answered in the Linux ext3 FAQ

  6. Writeback kicking it by jred · · Score: 3, Informative
    Writeback kicks ordered's ass. They do warn you about it, though:
    However, it is clear that IF your server is stable and not prone to crashing, and/or you have the write cache on your hard drives battery backed, you should strongly consider using the writeback journaling mode of Ext3 versus ordered.
    I didn't see where "notail" made much of a difference on ReiserFS, though.
    --

    jred
    I'm not a mechanic but I play one in my garage...
    1. Re:Writeback kicking it by alext · · Score: 2

      FWIW, the issue of whether writing to volatile storage counts as a committed transaction has been kicking around for a long time.

      I remember in the mid-80s, Stratus and Tandem would duel over TPC benchmarks, and while Stratus did respectably on conventional disk-based writes, they did try to get the TPC council to allow writes to their resilient (duplicated), battery-backed memory to count too. I don't think they succeeded then, and IMHO some rather cruddy PC memory system should not be allowed to count now.

    2. Re:Writeback kicking it by Zwack · · Score: 3, Insightful

      But if you look at the NAMESYS benchmark comparing ext2 to ext3 and ResierFS then it is clear that for sheer throughput ext2 wins...

      IF Speed is your reason for choosing a Filesystem then writeback wins on almost everything in these examples...

      But using a Journaled Filesystem isn't usually done for Speed... Unless you count speed booting after a crash. It's done to (more or less) guarantee filesystem integrity after a crash. You may lose data, but you only lose writes that never completed.

      So, if you are choosing ext3 with writeback, is it faster than native ext2? I don't know. But it doesn't sound like it is any safer.

      Of course, if you're worried about data integrity, you will have a mirror across multiple striped drives using multiple controllers. And then use a Journaled Filesystem to improve boot time.

      Z.

      --
      -- Under/Overrated is meta-moderation, and therefore is Redundant.
    3. Re:Writeback kicking it by Wesley+Felter · · Score: 2

      If you want to be sure that the data is on disk, use fsync().

    4. Re:Writeback kicking it by cduffy · · Score: 3, Interesting

      ext3 with writeback is indeed safer than ext2, inasmuch that all corruption will be with regard to the data -- your metadata is still safe.

      Now, data corruption can be a Very Bad Thing, depending on what you're doing... but in many cases, preventing metadata corruption (and thus being sure that your filesystem is always usable) is Good Enough.

    5. Re:Writeback kicking it by green+pizza · · Score: 2

      or you have the write cache on your hard drives battery backed

      I've seen such an option on big external RAID arrays. Makes sense, lets the write cache be written to disk before the power goes out.

      I'm curious, though, do any hard drives have this feature? Maybe not a full battery, but perhaps a capacitor to store enough juice to write that 8 MB of cache data down to disk before it's gone for good? Or perhaps some sort of bolt-on option for existing internal drives?

      I ask this as I'm an average joe with home-brew and cheap-label servers (I built most, a few are PII Dells and Gateways). My machines are pretty stable, but I only have about 70 minutes of battery backup from my UPS... and there's no way I could justify buying a generator.

    6. Re:Writeback kicking it by electricmonk · · Score: 2, Informative
      Of course, if you're worried about data integrity, you will have a mirror across multiple striped drives using multiple controllers. And then use a Journaled Filesystem to improve boot time.

      This is a misinformed opinion, at best. Your RAID setup will only save data in the case of hardware failure (i.e. one of your disks fails). It will do nothing about incomplete writes. The whole purpose of journaled filesystems is to ensure that writes completed, to minimize filesystem corruption. It just so happens that the way it does this allows for a faster boot, which is an added bonus.

      --
      Friends don't let friends use multiple inheritance.
    7. Re:Writeback kicking it by electricmonk · · Score: 1

      Why bother? If you have a UPS, all you need to do is let it alert your servers to the loss of external power and the servers can begin a clean shutdown sequence, certainly well within your 70 minute range. Most APC UPSes that I know of have a serial cable hookup. If you have more than one server hooked up to one UPS, I'm sure you could devise someway of one server recieving the power-down signal and broadcasting it to all your other machines over the network.

      --
      Friends don't let friends use multiple inheritance.
    8. Re:Writeback kicking it by Anonymous Coward · · Score: 3, Informative

      Nope. That's the problem. fsync() guarantees that the disk controller hardware is synced with the OS. It does not guarantee that the disk platters hold the data. It probably should, but implementing that is not always possible. Many controllers lie to look faster.

    9. Re:Writeback kicking it by supz · · Score: 2, Informative

      No need to devise a way of sending out a power-down signal for those with APC UPSes. They have a product named PowerChute (and even a linux version!) that machines connected to a UPS can use to communicate to each other. It has configurable shutdown times, so mission critical servers can stay up for the longest time possible, while not so important ones can be shut down immediately. We use it extensively in my office, and it really lengthens the battery length on our UPS.

      Also worth nothing -- we have our Exchange server begin shutdown almost immediately after the power goes out, as it takes exchange nearly 15 minutes just to shut down. We are actively looking for an alternative to Exchange.

    10. Re:Writeback kicking it by Sabalon · · Score: 3, Interesting

      There is also an apcupsd. This way, you can have one machine that is hooked to the UPS (no need for additional hardware to let multiple machine monitor the UPS.) When power goes down, the apcupsd then lets the other servers know what is going on (power off, power on, shut down now, etc...) Ports to Unicies galore, and winders.

      This all assumes that you have the network on a UPS and with the power out all machines can still talk.

      Pretty nice tool with tons of options. http://www.apcupsd.org (oddly, with the exception of the what's new pages of the docs, the url isn't listed in the docs.)

      Of course, I like my option - buy a UPS with enough capacity to hold the whole room for about 30 minutes (40KW) and a big ole generator in case things go down for a while.

    11. Re:Writeback kicking it by doorbot.com · · Score: 2

      I second the vote for using apcupsd. However, I think it is important for me to relay my experiences with it just to avoid potential problems for those of you uptime zealots (like me).

      A few months ago, I had a short (2 minute) power outage and of course my UPS kicked in and my server stayed online as you might expect. However, when power was restored, the apcupsd scripts were (by default) configured to reboot the server after a return to utility power. Why this is the case, I cannot answer, however I'm sure there is a logical explanation. In my case, I found this very unsettling as it caused my 100+ days of uptime to return to zero whence they came. The scripts were easy to fix, but hopefully this will serve as a warning for those of you who cannot afford the restart.

      On a slightly different note, I'm still not understanding the whole journalling file system issue; I understand the benefits, but are you really crashing that much (which must be hard locks), that you need to do a hard reset and let the journal replay the transactions? Personally, I have a tape backup, and a UPS. Do I really need a journalling file system, other than the obvious advantage of impressing the ladies? At the moment, I'm interested in XFS because of the ACLs and the "intensive disk usage" features SGI has in the IRIX version, and I'm hoping those make it into the "final" Linux version (if there ever will be a "final" version).

    12. Re:Writeback kicking it by Znork · · Score: 2

      Have you considered Samsung Contact (formerly HP Openmail)? As far as Exchange replacements it should be a viable alternative. Runs on Solaris, Linux, HP-UX or AIX on the server side and supports pretty much everything Exchange does on the client side (and of course it supports most other email clients).

      Of course, if you dont need a feature for feature match with Exchange there are unlimited cheap alternatives for mail servers.

    13. Re:Writeback kicking it by Sabalon · · Score: 2

      well...the simple reason for a better file system is simply shit happens

      On one of our old systems, the network admin asked what a button did as he pushed it. It was the power button. At another time the same guy accidentally dropped a pencil that hit the same power button (actually a rocker switch) again. Someone else was curious as to what the inside of that machine looked like, so they opened the swinging back door of the case, which caused the system to power down (oh that poor TI 1500)

      Power cords get tripped over. UPS's fail. UPS software does odd things. Hardware fails.

      Yeah...you have backups. Those fail as well, and restores take time. A journaling file system takes a few seconds after an abnormal startup to fix itself.

      Just think of it as yet another layer of protection beyond the UPS and backup tapes. And of course it helps get the ladies :)

    14. Re:Writeback kicking it by eam · · Score: 1

      What if the reason for the power failure is that someone tripped over the cord running from the UPS to the PC & pulled it out, or if the Power supply in the PC failed? How about if you were in the computer room & saw smoke & fire pouring out of the server? How about if the UPS failed?

      There are cases where a UPS won't prevent an "unexpected downtime". In these cases, it might be helpful if the drives were able to finish their last write on their own power. It might give you something to boot after you correct the problem.

    15. Re:Writeback kicking it by Zwack · · Score: 1

      This is a misinformed opinion, at best.

      No, it's what you get too late on a Friday evening... :-P

      Please let me try and clarify my thought processes...

      Your server is on a UPS. Your disks are fully redundant(Raid 0+1, Stripe and Mirror) your path to your disks is redundant (two controllers) you have (of course) got ECC memory in your server, and multiple processors...

      The only thing that is going to cause data loss is major hardware failure, or faulty software, and your software should deal with that for you IF THAT IS IMPORTANT TO YOU. Transaction logs for your database...

      A Journalled file system does not gain you anything other than speed over a non journalled file system in synchronous mode.

      If you can think of anything that would cause an incomplete write under these circumstances I would be interested to hear it...

      Z.

      --
      -- Under/Overrated is meta-moderation, and therefore is Redundant.
  7. IMPORTANT ANNOUNCEMENT by Anonymous Coward · · Score: -1, Troll

    My DICK is LONG and my ASS is HAIRY. Spread your honey and ENJOY them both.

    Thank you.

  8. I'm spoiled by Torgo's+Pizza · · Score: 1, Funny

    I know that I'm stupid for saying this, but after the past few years, a benchmark isn't sexy unless it has scenes of flying dragons or a copied scene from the Matrix on the screen. I must have sold my soul to the devil for saying that.

    1. Re:I'm spoiled by Anonymous Coward · · Score: 0

      I must have sold my soul to the devil for saying that.
      Actually, you sold it to the Daemon. The matrix was made with FreeBSD. >=)

    2. Re:I'm spoiled by spectecjr · · Score: 2

      Actually, you sold it to the Daemon. The matrix was made with FreeBSD. >=)

      He's actually referring to the MadOnion 3DMark2001 benchmark.

      http://www.madonion.com

      If you've never seen it, it's a killer.

      Simon

      --
      Coming soon - pyrogyra
    3. Re:I'm spoiled by Anonymous Coward · · Score: -1, Offtopic

      can you give me the devil's phone number?
      I have some souls for sale.

  9. As a profane fucking map maker by Profane+Motherfucker · · Score: -1, Troll

    Why the fuck can't people create a simple fucking graphical representation of their data? It would make things so much easier, and make for easy comparisions. Granted, one can fucking manipulate the shit out of graphs to skew the data, but good graphs are possible -- and necessary in this case.

    Right now, it's just shitty fucking data. People don't think in spreadsheets.

    1. Re:As a profane fucking map maker by Anonymous Coward · · Score: 0

      Well you should like

      http://labs.zianet.com

      then, iozone benchmarks at least

    2. Re:As a profane fucking map maker by Anonymous Coward · · Score: 0

      Well fsckface, it just so happens that images consume bandwidth. Jeesh.

    3. Re:As a profane fucking map maker by Russ+Steffen · · Score: 1

      So, did you not read the article? Or did you just fail to notice the nice bar graphs in the result section?

  10. reiserfs by term_0z · · Score: 0

    I am just sticking to reiserfs, and ext2. why?
    I really do not know!

  11. MOD PARENT UP! by Anonymous Coward · · Score: -1, Troll

    +5 insightfull

  12. Linux is for retards, as is windows! by Anonymous Coward · · Score: -1, Troll

    Linux is for retards, as is windows! Mac pre version X too, but now it uses some good code from BSD cause Linux sux ass!

    Linux tries to copy M$ too much, what a joke!

    M$ - The M$ way!

    Linux - Following the M$ way! With 15,000 fragmented non-standard distros to date.
    Not to mention, 'experimental' driver support in the production level kernels. LOL, what a joke!

    *BSD - Doing it the industry standard way!

    1. Re:Linux is for retards, as is windows! by Anonymous Coward · · Score: 0

      You forgot the part about how there are several *BSD distros, not to mention the fact that OS X's MICRO kernel is slower than the Linux Kernel.

  13. Journaled ext3 vs Reiserfs by Anonymous Coward · · Score: 3, Informative

    If you want journeled ext3 data vs, reiserfs with tails and without tails check out:

    http://labs.zianet.com

    There are some decent benchmarks there that compare the two as well as extensive NFS tests.

  14. ReiserFS loses data by Flarners · · Score: 1, Informative

    A hash collision in a ReiserFS directory (where two filenames hash out to the same value) causes the older file to BE OVERWRITTEN without so much as a warning. This is a huge design error, and I can't believe they're pushing Reiser as a production-use filesystem. The only way to ensure you never lose data to hash collisions is to use the 'slowest' hash setting; the faster the hash function, the more likely it is to create collisions and leak data. I had a large project lost to a

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:ReiserFS loses data by delta407 · · Score: 4, Interesting

      You're on crack. Hash collisions incur only a performance hit, not lost data.

    2. Re:ReiserFS loses data by Albanach · · Score: 2, Informative
      SuSE have been pushing ReiserFS for some time. I've certainly been using it for what seems like ages with no noticeable problems.

      I'm 110% sure it's saved more files when I've lost power or when something's hung requiring a hard reset than it'd deleted due to hash clashes. What's the likelihood of two files generating the same hash? You talk of increasing likeliness, but don't mention any figures. It's hard to judge without some stats.

      As an aside, why didn't you restore your large project from your backup? What do you mean you didn't have...

    3. Re:ReiserFS loses data by Anonymous Coward · · Score: 0


      This is absolutely false, please mod into oblivion.

    4. Re:ReiserFS loses data by Anonymous Coward · · Score: 0

      LOL! One of the better trolls I've seen in a while...dumbass moderators who know nothing about CS modded you up because you sound like you know what you're talking about.

    5. Re:ReiserFS loses data by Anonymous Coward · · Score: 0

      Oh bullshit. I've been using ReiserFS for years on server machines and I've never lost a single byte.

      Got any proof to back up your claim?

    6. Re:ReiserFS loses data by RustyTaco · · Score: 0, Flamebait

      > Got any proof to back up your claim?

      I do. Where shall I send the bz2'd filesystem image with inaccesable files that causes the kerenl to try to read beyond the end of the partition and causes a deadlock every few days. Yes, I've still got it, I havn't re-used that Logical volume yet, I just made a new one for an ext3 filesystem.

      Oh, and this is the SECOND time reiser has done that on this server. It didn't seem to appreciate mbox files.

      Get over it people, Reiser is NO WHERE near perfect, yet. Ext2 and even ext3 are much more mature and tested over extended time periods. Don't get me wrong, I use reiser for /home and /media at home, but I highly doubt I'll use it for /home on that co-lo'd server again. Nor at work, where the data really is worth money.

      - RustyTaco

      ...time to put in a new tape for tonights backup....

    7. Re:ReiserFS loses data by Anonymous Coward · · Score: 0

      I think you mean: ...time to go troll somewhere else

    8. Re:ReiserFS loses data by Anonymous Coward · · Score: 0

      Call me stupid, but I run ReiserFS on my production servers, one with a 75GB file system and the other with a 200GB filesystem. I also run ReiserFS on my firewalls and printservers that need to recover in case of a crash (no crashes yet).

      I choose ReiserFS because at the time over a year ago, it seemed to be the most mature journalling FS. After some initial problems with NFS, which turned out to be largely related to network issues (duplex mis-matches) it has been remarkably stable. I have NEVER lost a file due to the filesystem barfing, and these machines have been on 24/7 for over a year, with tons of data getting written.

      I will continue to use ResierFS in the future. Mind you, this is just my judgement, but it does the job for me, and that is what matters.

    9. Re:ReiserFS loses data by Anonymous Coward · · Score: 0

      You probably screwed up your partition table. ReiserFS is production-ready, many will attest to that.

    10. Re:ReiserFS loses data by g4dget · · Score: 2
      A hash collision in a ReiserFS directory (where two filenames hash out to the same value) causes the older file to BE OVERWRITTEN without so much as a warning.

      This is not necessarily a bug if the probability of that happening in real world scenarios is negligible. After all, you risk data loss from many sources.

      Unfortunately, programmers often seem a bit unreasonable about probabilities. They complain about a (say) 1:10^20 chance of losing a file, while at the same time writing the whole file system in C, which basically guarantees a several-fold increase in the probability of undetected software faults compared to alternatives. In fact, the fix for such a remote possibility may not only kill performance, it may actually increase the overall probability of a fault that causes data loss--because the extra code may have bugs.

      So, no, this doesn't bother me. I suspect that if Reiser knows about it and he isn't fixing it, he probably thought about it and decided the probability is too remote. If you disagree, I would like to see a more detailed analysis from you.

    11. Re:ReiserFS loses data by Morgaine · · Score: 3, Insightful

      Let's be scientific about this.

      Provide at least one pair of filepaths which generate a hash collision under whatever scenario you care to specify, so that others can test and verify the resulting effect, even if it's probabilistic and requires billions of reruns to trigger -- no problem.

      If the effect isn't seen by anyone else under any conditions, then the problem doesn't exist. Conversely, if it does happen under some repeatable conditions (even if only extremely rarely) then it *is* a problem, and will be fixed.

      If you want to be constructive about it, take this issue out of mythology and onto firmer ground.

      --
      "The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
  15. Speaking of losing data... by Flarners · · Score: 1

    Slashdot cut off my comment! Anyway, you get the idea; don't use ReiserFS unless you don't mind occasionally having files disappear.

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:Speaking of losing data... by Fluid+Truth · · Score: 4, Funny

      Slashdot cut off my comment!

      Awww, and here I thought you were trying to give an example of what the ReiserFS did to your data during a hash collision.

      --
      Apparently, of the rich, by the rich, for the rich.
  16. Small (Big?) Surprise. by dinotrac · · Score: 2

    One thing in these benchmarks surprised me just a bit:
    that reiser would do so well on the heavy-throughput/large file test.

    I've been laboring under the perception that reiser was good for randomly accessing small files, but paid a performance penalty when going after large ones.

    Guess I'm still waiting to prove that no one can be wrong about everything! ;0)
    Cheers.

  17. No way.. by iONiUM · · Score: -1, Flamebait

    NTFS can beat both of them!

    1. Re:No way.. by FooBarWidget · · Score: 0, Offtopic

      Actually, NTFS is slower than FAT. We all know even ext2 outperforms the ancient FAT, but NTFS is slower than FAT!

      From:
      http://www.microsoft.com/hwdev/tech/stora ge/ntfs-p reinstall.asp
      "Disk subsystem performance is a critically important factor in overall system performance, and NTFS is generally believed to be slower than FAT."

      And from:
      http://www.activewin.com/reviews/software/o peratin g-sys/win2kpro/files.shtml
      I quote: "NTFS is reliable, but it is slower than FAT 32 format."

    2. Re:No way.. by Sivar · · Score: 2

      Rather difficult to tell considering that you cannot run Qmail or Postfix under Windows. If you have any benchmarks of, say, Microsoft Exchange (ha!) outperforming Postfix, we would love to see them.

      No mindcraft, please.

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    3. Re:No way.. by iONiUM · · Score: 1

      Actually my original post was supposed to be sarcastic, but when i put in the tags "sarcasm" and "/sarcasm" it filtered them out due to my own stupidity.

      Live and learn I suppose.

    4. Re:No way.. by Graspee_Leemoor · · Score: 2

      Who gives a fuck how fast NTFS is compared to fat? Fat32 has a stupid max file length of 2^32 bytes, rendering it all but useless for video work.

      If you're stuck doing video work on an NT kernel, (and many people are, since linux is definately behind in this area), do you really want no files bigger than 4gig?

      graspee

    5. Re:No way.. by FooBarWidget · · Score: 1

      "Who gives a fuck how fast NTFS is compared to fat?"

      Didn't post said that NTFS can beat both ext3 and ReiserFS? "NTFS can beat both of them!" he said. That's why I posted some proof that NTFS is slower?
      Obviously, HE cares, and I was replying to him.

      Now, can anybody explain me how that was "offtopic"? The original poster was talking about NTFS's speed, and so was I.

  18. my decision by salmo · · Score: 5, Insightful

    My decision isn't based on performance. They both are "fast enough" for me. I used to use ReiserFS a while back and it was great. Then I installed Redhat 7.3 on a machine and used ext3 so I didn't have to mess with anything. Yes tinkering is fun... but when I feel like it. Sometimes its nice to have stuff Just Work. Haven't had any problems since and have had a few random power outages.

    Also I like the idea that I can read the drive with an ext2 driver from an older kernel or from FreeBSD just in case. In case of what? I don't know, but somehow it makes me feel better.

    1. Re:my decision by zelbinion · · Score: 1

      Also I like the idea that I can read the drive with an ext2 driver from an older kernel or from FreeBSD just in case. In case of what? I don't know, but somehow it makes me feel better.

      ...How about in case you want to make a disk image with a tool like DriveImage that supports ext2, and therefore, in a round-about way, ext3?
      Hard disk crash? no problem -- drop in a new drive and the cd with your partition image and you're up in 15 minutes.
      Note: I'm not affliated with PowerQuest -- I just buy their software when I've got money left over from buying a book of the new 37 cent US first class stamps...

    2. Re:my decision by big+tex · · Score: 2, Interesting

      "Just Works", at least in this case, is partially dependent on distro.
      I run SuSE, and installed ReiserFS (version 7.1? 7.2? Sometime around there.) and it "Just Works."
      I don't know if it is faster, I've never noticed the difference on my P2-400 home machine.
      Got to test it out the other day when the cat sat on the surge protector switch - rebooted like nothing happened. sweeeet.

      --
      I think I need a new sig here.
  19. But Remember by Verizon+Guy · · Score: -1, Troll

    Of course you forgot that you can still run into that retarded "out of inodes" problem in ext3... that's why you keep large data stores on NTFS or some large Sun volume :)

    Plus NTFS just recovers from the journal instantly and you're set. Hit the power switch? Not good, but no problem either.

    Seriously, which do you rather want?

    This: /dev/hda2 was not cleanly unmounted, check forced.
    [-------41%-------] blah, blah, blah


    Or this?

    Welcome to Windows. Press Ctrl-Alt-Del to log on.

    --

    Aw, fuck it. Let's go bowling. - The Big Lebowski

    1. Re:But Remember by Russ+Steffen · · Score: 1

      Personally I'd rather have this one:

      3:14pm up 321 days, 22:23, 124 users, load average: 0.84, 0.37, 0.56

    2. Re:But Remember by EllF · · Score: 4, Informative

      *ANY* journally filesystem can recover from an unexpected power loss. With an ext3 system, if you're seeing a check taking place (and you want to prevent such), disable them - in general, they are a holdover from ext2:

      tune2fs -c 0 -C 0

      However, you should also read this, from the tune2fs man page:

      You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.

      I cannot speak to the inode issue - I've never run into it myself.

      --
      We who were living are now dying
      With a little patience
    3. Re:But Remember by Anonymous Coward · · Score: 0

      ummm I think you are thinking of ext2. ext3 recovers just fine.

      Just the other night I was trying to program during a thunderstorm. My pc was reset by powerspikes at least ten times (no I do not learn), and ever time my pc came right back up without having to scan the entire partition.

    4. Re:But Remember by forevermore · · Score: 1
      OK, you lost me here. I work with a couple of NTFS partitions, containing a total of 2-4 million small files (about 40 gigs total, split on two 40 gig drives), and when my machine crashed the other day, it took OVER AN HOUR before it finished its mandatory file check. Not to mention the fact that it takes windows about a minute and a half to "find itself" after the bios checks and begin booting whenever I have to restart. Hell, I even tried to format one of the drives in FAT32 since it handles small files better, but the Win2k programmers decided that no one should format Fat32 partitions larger than 32 gigs (and you can't unless you use something other than Win2k)

      My linux box (not quite as many files) recovers its ext3 journal seemingly instantly after any crash (oh wait, it doesn't crash) or forced reboot (I'll admit that sometimes it's just easier to reboot the machine than try to restart X when the screensaver won't power my monitor back up)

      --
      Do you really need reason for beer? Wingman Brewers
    5. Re:But Remember by Verizon+Guy · · Score: 1

      Just the other night I was trying to program during a thunderstorm. My pc was reset by powerspikes at least ten times (no I do not learn), and ever time my pc came right back up without having to scan the entire partition.


      Next time, I suggest standing outside with a golf club outstretched to the sky.

      --

      Aw, fuck it. Let's go bowling. - The Big Lebowski

    6. Re:But Remember by robhancock · · Score: 1

      NTFS is a journaled file system (similar to ext3 writeback mode, I believe). It shouldn't even be running a chkdsk on bootup for an NTFS volume, unless perhaps it detects something really wacky with the file system..

      FAT32, on the other hand, will always run a chkdsk whenever it wasn't unmounted cleanly. For a disk with that many small files, it would likely take even longer than a full NTFS chkdsk (whatever the reason is that that's even running), not to mention the horrific slack waste..

  20. The rest of it ... by on+by · · Score: -1

    is here. It's a bit out of date though, perhaps some one could update it?

  21. Last Post by YourMissionForToday · · Score: -1
    Relying on benchmarks to gauge performance is as pointless as brushing your teeth with piss.

    You don't need to read any further. Go away.

    1. Re:Last Post by Verizon+Guy · · Score: 0, Troll

      No kidding, use pisspaste.

      --

      Aw, fuck it. Let's go bowling. - The Big Lebowski

  22. sucks! by Anonymous Coward · · Score: -1, Troll

    Linux sucks!
    Mac OS x Sucks!
    Windows sucks!
    Dos sucks!
    BSD sucks!

    1. Re:sucks! by Anonymous Coward · · Score: 0

      so what doesn't suck?

    2. Re:sucks! by diaper_tales · · Score: -1

      solaris and windows nt4.

  23. I just wrote this by gazbo · · Score: -1, Troll

    Making my way to K5
    Clicking fast
    Yes, Rusty's an ass
    But I don't mind
    Staring blankly ahead
    Trollin' the gay
    Making my way
    Through the homo crowd

    And I hate you
    And I mock you
    And now I wonder....

    If I could troll
    Yet another liberal guy
    Do you think time
    Would pass me by
    'Cause you know I'd snort
    A thousand lines
    If I could
    Just troll you
    Tonight

    1. Re:I just wrote this by on+by · · Score: -1, Informative

      Hey! That's really cool and the best part is you didn't just cut and paste it from some other site like certain other people.

  24. Ok. by JismTroll · · Score: -1

    Here's some pr0n.

    Thanks for the FP, even though you had no claim to it anyway, you fucking worthless AC.

  25. Gurulabs background picture? by PetriWessman · · Score: 1

    Offtopic, but seems to me that the picture that gurulabs is using as background for their web page is ripped from the cover artwork of the album "Rally of Love" by the Finnish band 22-Pistepirkko. Wonder if they have permission for that?

    Of course, could be that the album cover is a copy of something that is in the public domain...

    1. Re:Gurulabs background picture? by Anonymous Coward · · Score: 0

      GuruLabs has had that logo long before "Rally of Love" was released.

      Where either got it from originally, I don't know.

    2. Re:Gurulabs background picture? by Anonymous Coward · · Score: 1, Informative

      I took a class from them almost 3 years ago and they were using that graphic then.

      Offtopic, good class though.

    3. Re:Gurulabs background picture? by Anonymous Coward · · Score: 0

      Ive seen it in a wingding set at www.fontalicious.com

  26. ext3 writeback vs ext2? by ywwg · · Score: 2

    so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"? So is the _only_ gain the fsck time?

    1. Re:ext3 writeback vs ext2? by FooBarWidget · · Score: 1

      Yes.
      But for some people, that appears to be enough...

    2. Re:ext3 writeback vs ext2? by sjames · · Score: 3, Insightful

      so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"?

      Consider a large tmp volume.

      Anywhere where the consequences of finding stale data in a file are no worse than having the data simply missing after a crash. Even a src directory if you do a lot of big makes (since you're best off with make clean ; make after a crash anyway). Just be sure to sync after writing out a source file.

      However, as long as performance is adequate, probably better safe than sorry when it comes to filesystems.

    3. Re:ext3 writeback vs ext2? by Guy+Smiley · · Score: 3, Informative
      so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"? So is the _only_ gain the fsck time?

      Well, ext3 with data=writeback is equivalent to how reiserfs has always operated (i.e. if you crash you can lose data in files that were being written to). Using data=ordered is an extra benefit that doesn't have any noticable performance hit unless you are trashing the disk and RAM in a benchmark. FYI, there are now beta patches for reiserfs that implement data=ordered.

      Only the fsck time can be a big deal if you have to wait 8 hours while your 1TB storage array is fscking (8 hours is a guess, I don't have that much disk...)

    4. Re:ext3 writeback vs ext2? by Wesley+Felter · · Score: 3, Funny

      So what's the point of running ext2 if it's exactly equivalent to ext3/writeback but with very slow fsck?

    5. Re:ext3 writeback vs ext2? by sir99 · · Score: 1

      Because the ext2 code is more mature than the ext3 code. I also read that the ext2 code is currently much better suited to SMP, but ext3 hasn't been worked over to work well with multiple processes/processors.

      --
      The ocean parts and the meteors come down
      Laid out in amber, baby.
    6. Re:ext3 writeback vs ext2? by IkeTo · · Score: 1

      It's a bit better: redoing transactions in the journal will never fail if the hard disk hardware is intact. Fsck can get f*cked up, and by then all your data is, well, up to manual recovery.

  27. ICE ICE BABY by GafTheHorseInTears · · Score: -1

    Yo, VIP, Let's kick it!
    Ice Ice Baby, Ice Ice Baby

    All right stop, Collaborate and listen Ice is back with my brand new invention
    Something grabs a hold of me tightly Then I flow like a harpoon daily and nightly
    Will it ever stop? Yo -- I don't know Turn off the lights and I'll glow
    To the extreme I rock a mic like a vandal Light up a stage and wax a chump like a candle.
    Dance, Bum rush the speaker that booms I'm killing your brain like a poisonous mushroom
    Deadly, when I play a dope melody Anything less than the best is a felony
    Love it or leave it, You better gain way You better hit bull's eye, The kid don't play
    If there was a problem, Yo, I'll solve it Check out the hook while my DJ revolves it

    Ice Ice Baby Vanilla, Ice Ice Baby Vanilla Ice Ice Baby Vanilla, Ice Ice Baby Vanilla

    Now that the party is jumping With the bass kicked in, the Vegas are pumpin'
    Quick to the point, to the point no faking I'm cooking MCs like a pound of bacon
    Burning them if they're not quick and nimble I go crazy when I hear a cymbal
    And a hi hat with a souped up tempo I'm on a roll and it's time to go solo
    Rollin' in my 5.0 With my ragtop down so my hair can blow
    The girlies on standby, Waving just to say Hi Did you stop? No -- I just drove by
    Kept on pursuing to the next stop I busted a left and I'm heading to the next block
    That block was dead Yo -- so I continued to A1A Beachfront Ave.
    Girls were hot wearing less than bikinis Rockman lovers driving Lamborghinis
    Jealous 'cause I'm out geting mine Shay with a gauge and Vanilla with a nine
    Reading for the chumps on the wall The chumps acting ill because they're so full of "Eight Ball"
    Gunshots ranged out like a bell I grabbed my nine -- All I heard were shells
    Falling on the concrete real fast Jumped in my car, slammed on the gas
    Bumper to bumper the avenue's packed I'm trying to get away before the jackers jack
    Police on the scene, You know what I mean They passed me up, confronted all the dope fiends
    If there was a problem, You, I'll solve it Check out the hook while my DJ revolves it

    Ice Ice Baby Vanilla, Ice Ice Baby Vanilla Ice Ice Baby Vanilla, Ice Ice Baby Vanilla

    Take heed, 'cause I'm a lyrical poet Miami's on the scene just in case you didn't know it
    My town, that created all the bass sound Enough to shake and kick holes in the ground
    'Cause my style's like a chemical spill Feasible rhymes that you can vision and feel
    Conducted and formed, This is a hell of a concept We make it hype and you want to step with this
    Shay plays on the fade, slice like a ninja
    Cut like a razor blade so fast, Other DJs say, "damn" If my rhyme was a drug, I'd sell it by the gram
    Keep my composure when it's time to get loose Magnetized by the mic while I kick my juice
    If there was a problem, Yo -- I'll solve it! Check out the hook while Deshay revolves it.

    Ice Ice Baby Vanilla, Ice Ice Baby Vanilla Ice Ice Baby Vanilla, Ice Ice Baby Vanilla
    Yo man -- Let's get out of here! Word to your mother!
    Ice Ice Baby Too cold, Ice Ice Baby Too cold Too cold Ice Ice Baby Too cold Too cold, Ice Ice Baby Too cold Too cold

    --
    "You're just scared like a little white pussy. I'll fuck you till you love me, you faggot!"
  28. Re:Can you document that? by RockyMountain · · Score: 5, Insightful

    Can you document the claim that hash collisions cause silent data corruption? Or even that they cause a failure of any sort?

    If this is true, surely it must be documented somewhere, or have been discussed in a credible forum? I did a little searching, and didn't find anything. Please post a URL to elevate your comment from unsubstantiated rumor to informative information.

    In most hash-based indexing algorithms I know of, hash collisions incur a perfomance penalty, but not a data loss.

  29. MOD DOWN-UNTRUE: only performance hit no data loss by Anonymous Coward · · Score: 0

    Mod the parent down. Hash collide only cause performance hit. Author full of shit

  30. Re:Can you document that? by RockyMountain · · Score: 2, Funny

    to informative information.

    Informative information? I really ought to use "Preview" before "Submit".

  31. ...what I would like to see by Bandito · · Score: 2, Interesting

    I would have wanted to also see a non-journalling filesystem compared against these. Since I'm not currently using a journalled filesystem, it would be nice to see the difference between what I use now (ext2) and the journalled fs's.

    1. Re:...what I would like to see by Anonymous Coward · · Score: 0

      Do tune2fs -j /dev/ext2_hd_dev and find out...creates a journal for ext2. Just change your fstab to try it.

    2. Re:...what I would like to see by AvitarX · · Score: 1

      quote from AC:"Do tune2fs -j /dev/ext2_hd_dev and find out...creates a journal for ext2. Just change your fstab to try it."

      You might also want to make sure you compiled ext3 support into your kernel. Not trying to be a jackass, but not everyone has the latst kernel, I just upgraded from 2.2.17 for ext3 personally. Giving sloppy advice like that to somebody could be bad. Shame on you.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
  32. Eat it by Anonymous Coward · · Score: 0

    all you naysayers who continually bash Redhat for the sake of bashing..

    "Why are they using ext3??"

    Because it's stable. Because it's backwards compatible. And now, we know it can be fast.

  33. *BSD is dying by poopbot by Anonymous Coward · · Score: -1, Offtopic
    It is now official. Netcraft confirms: *BSD is dying

    One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

    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


    - poopbot: because we're all crapflooders at heart

  34. Interesting by Flarners · · Score: 1

    Tell that to my missing /usr/local tree.

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:Interesting by Anonymous Coward · · Score: 0

      You didn't happen to "rm -rf /usr/local", did you? Maybe you got r00ted.

    2. Re:Interesting by Anonymous Coward · · Score: 2, Insightful

      My car is missing. Therefore, UFOs from the center of the earth took it. Bigfoot was involved.

    3. Re:Interesting by WolfWithoutAClause · · Score: 2
      Can your /usr/local/ tree be made to go away reproducibly?

      To prove you theory you could take the hash function in reiserfs and replace it with a function that always returns '1'. You would probably have to reformat your partitions though for that test though. The filesystem should still work. If it doesn't that's a bug.

      The chances of their being a bug in reiserfs is about 100%. Same is true of ext3 though.

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
  35. Ext3 is still EXPERIMENTAL by Anonymous Coward · · Score: 0

    Ok, these benchmarks only make real world sense if EXT3 were DONE. It's not.

    Don't give me the "oh I've been using it and haven't had any problems" crap. Go into the kernel configuration and see for yourself: ReiserFS is stable, EXT3 is still marked EXPERIMENTAL. There is no way in hell I'd put EXT3 on a server, much less a desktop machine.

    Wake me up when EXT3 is done. Until then, Reiser is the only stable journalling filesystem for Linux. (And i can play the game too: I've never had a single problem with Reiserfs..makes me wonder why the hell the Debian Installer makes the false claim that Reiser is younger and less tested than EXT3.)

  36. I have to wonder about the competence... by Sivar · · Score: 1, Offtopic

    ...of these guys. They saved the benchmark graphs as JPEG images when a passing glance would make the use of PNG or GIF.

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    1. Re:I have to wonder about the competence... by Anonymous Coward · · Score: 0

      Your comment makes me wish there was a "-1 Fucking Moron" moderation option.

      Can you explain how someone's preference of graphic format is in any way an indication of their competence?

    2. Re:I have to wonder about the competence... by Sivar · · Score: 2

      The GIF Unisys patent has, IIRC, passed and is no longer an issue. Otherwise, all true. Motice, though: What image format is the Slashdot logo?

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
  37. XFS? by Jennifer+Ever · · Score: 3, Interesting

    Any benchmarks on XFS vs. ext3/ReiserFS?

    1. Re:XFS? by jeremysg · · Score: 1

      i'm running XFS on a couple or three systems here at home w/ Linux From Scratch (www.linuxfromscratch.org) installs... and its very very nice. i remember seeing an article that was linked on linuxtodaycom a while back about XFS, i bleive the only downfall they said it has was its a bit slower that others when deleting files.

      i'd personally use XFS over any of the others any day, mainly since its fsck free and is a file system that is known to work well (its been used/owned by SGI, yea know).

      --
      --sG-- www.errantventure.org
    2. Re:XFS? by Anonymous Coward · · Score: 0

      I use XFS and it rocks. I run a lot of linux servers and desktops for different uses and it is by far the best file system.

      The main problem I found with ReiserFS was it courption. Reiser just isn't designed for large high use servers, and while it doesnt crash and burn it does make a bit of a mess with your file system. For example damaged files dont go to lost and found as in ext2, they just sit around in the directory structure but will cause weird kernel behavour when you try and access them.

      ext3 didnt give the speed performance needed and wasn't as mature as xfs.

      If you want a FS, use XFS, its been around the longest, it is the fastest, and its very very reliable

  38. X-Windows article in full by Anonymous Coward · · Score: -1, Troll

    The X-Windows Disaster
    This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins. How to make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards. X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
    X: The First Fully Modular Software Disaster
    X-Windows started out as one man's project in an office on the fifth floor of MIT's Laboratory for Computer Science. A wizardly hacker, who was familiar with W, a window system written at Stanford University as part of the V project, decided to write a distributed graphical display server. The idea was to allow a program, called a client, to run on one computer and allow it to display on another computer that was running a special program called a window server. The two computers might be VAXes or Suns, or one of each, as long as the computers were networked together and each implemented the X protocol.
    [Footnote: We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relationships, the server is the remote machine that runs the application (i.e., the server provides services, such as database service or computational service). For some perverse reason that's better left to the imagination, X insists on calling the program running on the remote machine "the client." This program displays its windows on the "window server." We're going to follow X terminology when discussing graphical client/servers. So when you see "client" think "the remote machine where the application is running," and when you see "Server" think "the local machine that displays output and accepts user input."] The Nongraphical GUI
    X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?
    Ten years later, most computers running X run just four programs: xterm, xload, xclock, and a window manager. And most xterm windows run Emacs! X has to be the most expensive way ever of popping up an Emacs window. It sure would have been much cheaper and easier to put terminal handling in the kernel where it belongs, rather than forcing people to purchase expensive bitmapped terminals to run character-based applications. On the other hand, then users wouldn't get all of those ugly fonts. It's a trade-off. The Motif Self-Abuse Kit
    X gave Unix vendors something they had professed to want for years: a standard that allowed programs built for different computers to interoperate. But it didn't give them enough. X gave programmers a way to display windows and pixels, but it didn't speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards. A bunch of people who hadn't written 10 lines of code in as many years set up shop in a brick building in Cambridge, Massachusetts, that was the former home of a failed computer company and came up with a "solution:" the Open Software Foundation's Motif.
    What Motif does is make Unix slow. Real slow. A stated design goal of Motif was to give the X Window System the window management capabilities of HP's circa-1988 window manager and the visual elegance of Microsoft Windows. We kid you not.
    Recipe for disaster: start with the Microsoft Windows metaphor, which was designed and hand coded in assembler. Build something on top of three or four layers of X to look like Windows. Call it "Motif." Now put two 486 boxes side by side, one running Windows and one running Unix/Motif. Watch one crawl. Watch it wither. Watch it drop faster than the putsch in Russia. Motif can't compete with the Macintosh OS or with DOS/Windows as a delivery platform.
    Ice Cube: The Lethal Weapon
    One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
    If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
    As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
    The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
    In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.
    Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
    - Jamie Zawinski
    X Myths
    X is a colletion of myths that have become so widespread and so prolific in the computer industry that many of them are now accepted as "fact," without any thought or reflection.
    Myth: X Demonstrates the Power of Client/Server Computing
    At the mere mention of network window systems, certain propeller gheads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to fore suers to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
    The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
    The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
    The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input eents, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
    As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.

    Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interfae toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and reating a look-and-feel that is both consistent aross applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations -- and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.

    Ultimately, NeWS was not economically or politically viable because it the very problems that X was designed to create.

    Myth: X Makes Unix "Easy to Use"
    Graphical interfaces can only paper over misdesigns and kludges in the underlying operating system; they can't eliminate them.
    The "drag-and-drop" metaphor tires to cover up the Unix file system, but so little of Unix is designed for the desktop metaphor that it's just one kludge on top of another with little holes and sharp edges popping up everywhere. Maybe the "sag-and-drop" metaphor is more appropriate for such ineffective and unreliable performance.

    A shining example is Sun's Open Windows File Manager, which goes out of its way to display ore dump files as cute little red bomb icons. When you double-click on the bomb, it runs a text editor on the core dump. Harmless, but not very useful. But if you intuitively drag and drop the bomb on the DBX Debugger Tool, it does exactly what you'd expect if you were a terrorist: it ties the entire system up, as the core dump (including a huge unmapped gap of zeros) is pumped through the server and into the debugger text window, which inflates to the maximum capacity of swap space, then violently explodes, dumping an even bigger core file in place of your original one, filling up the entire file system, overwhelming the file server, and taking out the File Manager with shrapnel. (This bug has since been fixed.)

    But that's not all: the File Manager puts even more power at your fingertips if you run it as root! When you drag and drop a directory onto itself, it beeps and prints "rename: invalid argument" at the bottom of the window, then instantly deletes the entire directory trwe without bothering to update the graphical directory browser.

    The following message illustrates the X approach to "security through obscurity":

    Date: Wed, 30 Jan 91 15:35:46 -0800
    From: David Chapman
    To: UNIX-HATERS
    Subject: MIT-MAGIC-COOKIE-1

    For the first time today I tried to use X for the purpose for which it was intended, namely cross-network display. So I got a telnet window from boris, where I was logged in and running X, to akbar, where my program runs. Ran the program and it dumped core. Oh. No doubt there's some magic I have to do to turn cross-network X on. That's stupid. OK, ask the unix wizard. You say "setenv DISPLAY boris:0". Presumably this means that X is too stupid to figure out where you are coming from, or unix is too stupid to tell it. Well, that's unix for you. (Better not speculate about what the 0 is for.)
    Run the program again. Now it tells me that the server is not authorized to talk to the client. Talk to the unix wizard again. Oh, yes, you have have to run xauth, to tell it that it's OK for boris to talk to akbar. This is done on a per-user basis for some reason. I give this ten seconds of thought: what sort of security violation is this going to help with? Can't come up with any model. Oh, well, just run xauth and don't worry about it. xauth has a command processor and wants to have a long talk with you. It manipulates a .Xauthority file, apparently. OK, presumably we want to add an entry for boris. Do:

    xauth> help add
    add dpyname protoname hexkey add entry

    Well, that's not very helpful. Presumably dpy is unix for "display" and protoname must be... uh... right, protocol name. What the hell protocol am I supposed to use? Why should I have to know? Well, maybe it will default sensibly. Since we set the DISPLAY variable to "boris:0", maybe that's a dpyname.

    xauth> add boris:0
    xauth: (stdin):4 bad "add" command line

    Great. I suppose I'll need to know what a hexkey is, too. I thought that was the tool I used for locking the strings into the Floyd Rose on my guitar. Oh, well, let's look at the man page.

    I won't include the whole man page here; you might want to man xauth yourself, for a good joke. Here's the explanation of the add command:

    add displayname protocolname hexkey

    An authorization entry for the indicated display using the given protocol and key data is added to the authorization file. The data is specified as an even-lengthed string of hexadecimal digits, each pair representing one octet. The first digit gives the most significant 4 bits of the octet and the second digit gives the least significant 4 bits. A protocol name consisting of just a single period is treated as an abbreviation for MIT-MAGIC-COOKIE-1.
    This is obviously totally out of control. In order to run a program across the fucking network I'm supposed to be typing in strings of hexadecimal digits which do god knows what using a program that has a special abbreviation for MIT-MAGIC-COOKIE-1?? And what the hell kind of a name for a network protocol is THAT? Why is it so important that it's the default protocol name?

    Fuck this shit.

    Obviously it is Allah's will that I throw the unix box out the window. I submit to the will of Allah.

    Anybody who has ever used X knows that Chapman's error was trying to use xauth in the first place. he should have known better. (Blame the victim, not the program.)

    Myth: X Is "Customizable" ...And so is a molten blob of pig iron. But it's getting better; at least now you don't hasve to use your bare hands. Hewlett-Packard's Visual User Environment is so cutting-edge that it even has an icon you can click on to bring up the resource manager: it pops up a vi on your .Xdefaults file! Quite a labor-saving contraption, as long as you're omniscient enough to understand X defaults and archaic enough to use vi. The following message describes the awesome flexibility and unbounded freedom of expression that X defaults fail to provide.

    Date: Fri, 22 Feb 91 08:17:14 -0800
    From: beldar@mips.com (Gardner Cohen)

    I guess josh just sent you mail about .Xdefaults. I'm interested in the answer as well. How do x programs handle defaults? Do they all roll their own?
    If they're xt, they follow some semblance of standards, and you can walk the widget tree of an running application to find out what there is to modify. If they're not Xt, they can do any damn thing they want. They can XGetDefault, which doesn't look at any class names, and doesn't notice command line -xrm things.

    Figuring out where a particular resource value is for a running application is much fun, as resource can have come from any of the following: (there is a specified order for this, which has changed from r2 to r3 to r4) .Xdefaults (only if they didn't xrdb something)

    command line -xrm 'thing.resource: value'

    xrdb, which the user runs in .xsession or .xinitrc; this program runs cpp on the supplied filename argument, so shit can have been #included from another planet. Oh, and it #defines COLOR and a few other things as appropriate, so you better know what kind of display it's running on.

    file name, pointed to by XENVIRONMENT .Xdefaults-hostname

    file name that's the class name of the application (usually completely non-intuitively generated: XParty for xparty, Mwm for mwm, XRn for xrn, etc) in the directory /usr/lib/X11/app-defaults (or the directory pointed to by the XAPPLRESDIR environment variable). The default for this directory may have been changed by whoever built and installed the x libraries.

    Or, the truly inventive program may actively seek out and merge resource databases from other happy places. The Motifified xrn posted recently had a retarded resource editor which drops modified resources in files in the current directory as well as in the user's home. On startup, it happily looks all over the place for amusing looking file names to load, many of them starting with dots so they won't 'bother' you when you list your files.

    Or, writers of WCL based applications can load resource files that actually generate new widgets with names specified in those (or other) resource files.

    What this means is that the smarter-than-the-average-bear user who actually managed to figure out that

    snot.fucked.stupid.widget.fontList: micro

    is the resource to change the font in his snot application, could be unable to figure out where to put it. Suzie sitting in the next cubicle will tell him, "just put it in your .Xdefaults", but if he happens to have copied Fred's .xsession, he does an xrdb .xresources, so .Xdefaults never gets read. Susie either doesn't xrdb, or was told by someone once to xrdb .Xdefaults. She wonders why when she edits .Xdefaults, the changes don't happen until she 'logs out', since she never reran xrdb to reload the resources. Oh, and when she uses the NCD from home, things act `different', and she doesn't know why. "It's just different sometimes."

    Joe Smartass has figured out that XAPPLRESDIR is the way to go, as it allows him to have separate files for each application. But he doesn't know what the class name for this thing is. He knows his copy of the executable is called snot, but when he adds a file Snot or XSnot or Xsnot, nothing happens. He has a man page which forgot to mention the application class name, and always describes resources starting with '*', which is no help. He asks Gardner, who fires up emacs on the executable, and searches for (case insensitve) snot, and finds a few SNot strings, and suggests that. It works, hooray. He figures he can even use SNot*fontList: micro to change all the fonts in the application, but finds that a few widgets don't get that font for some reason. Someone points out that he has a line in his .xresources (or was it a file that was #included in .xresources) of the form *fucked*fontList: 10x22, which he copied from Steve who quit last year, and that of course that resources is 'more specific' than his, whatever the fuck that means, so it takes precedence. Sorry, guy. He can't even remember what application that resource was supposed to change anymore. Too bad.

    Sigh. It goes on and on. Try to explain to someone how to modify some behavior of the window manager, with having to re-xrdb, then select the window manager restart menu item (which most people don't have, as they copied the guy next door's .mwmrc), or logging out. Which file do I have to edit? .mwmrc? Mwm? .Xdefaults? .xrdb? .xresources? .xsession? .xinitrc? .xinitrc.ncd?

    Why doesn't all this work the way I want? How come when I try to use the workstation sitting next to mine, some of the windows come up on my workstation? Why is it when I rlogin to another machine, I get these weird X messages and core dumps when I try to run this application? How do I turn this autoraising behavior off? I don't know where it came from, I just #included Bob's color scheme file, and everything went wrong, and I can't figure out why!

    SOMEBODY SHOOT ME I'M IN HELL!!!

    Myth: X Is "Portable" ...And Iran-Contra wasn't Arms for Hostages.
    Even if you can get an X program to compile, there's no guarantee it'll work with your server. If an application requires an X extension that your server doesn't provide, then it fails. X applications can't extend the server themselves -- the extension has to be compiled and linked into the server. Most interesting extensions actually require extensive modification and recompilation of the X server itself, a decidedly nontrivial task. The next message tells how much brain-searing, eye-popping fun compiling "portable" X server extensions can be:

    Date: Wed 4 Mar 92 02:53:53 PST
    X-Windows: Boy, Is my Butt Sore
    From: Jamie Zawinski [jwz@lucid.com]
    To: UNIX-HATERS
    Subject: X: or, How I Learned to Stop Worring and Love the Bomb

    Don't ever believe the installation instructions of an X server extension. Just don't, it's an utter waste of time. You may be thinking to your self, "I'll just install this piece of code and recompile my X server and then X will be JUST a LITTLE BIT less MORONIC; it'll be EASY. I'll have worked around another STUPID MISDESIGN, and I'll be WINNING." Ha! Consider whether chewing on glass might have more of a payoff than what you're about to go through.

    After four hours of pain, including such loveliness as a dozen directories in which you have to make a symlink called "X11" pointing at wherever the real X includes are, because the automatically-generated makefiles are coming out with stuff like:

    -I../../../../../../include

    instead of

    -I../../../../include

    or, even better,

    -I../../.././../mit/./../../../include

    and then having to hand-hack these automatically-generated makefiles anyway because some random preprocessor symbols weren't defined and are causing spurious "don't know how to make" errors, and then realizing that makedepend, which you don't really care about running anyway, is getting errors because the extension's installation script made symlinks to directories instead of copies, and .. doesn't WORK with symlinks, and and and ...
    You'll finally realize that the only way to compile anything that's a basic part of X is to go to the top of the tree, five levels higher than the executable that you actually want to generate, and say "make Everything". Then come back an hour later when it's done making the MAKEFILES to see if there were any actual COMPILATION problems.

    And then you'll find yourself asking questions like, "why is it compiling that? I didn't change that, what's it DOING?"

    And don't forget that you HAVE to compile ALL of PEX, even though none of it actually gets linked in to any executables that you'll ever run. This is for your OWN GOOD!

    And then you'll realize what you did wrong, of course, you'll realize what you should have done ALL ALONG:

    all::
    $(RM) -rf $(TOP)

    But BE CAREFUL! That second line can't begin with a tab.

    On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.

    The most that can be said about the lowest-common-denominator approach that X takes to graphics is that it levels the playing field, allowing incredibly stupid companies to jump on the bandwagon and sell obsolete junk that's just as unusable as high-end brand-name workstations:

    Date: Wed 10 Apr 91 08:14:16 EDT
    From: Steve Strassmann
    To: UNIX-HATERS
    Subject: the display from hell

    I have a "window system" on my unix box. You see, in the unix world, "system" means "a bunch of unrelated programs." But that's not what I want to talk about here today. I want to talk about overlay planes.

    My HP 9000/835 console has two 19" color monitors, and some extremely expensive Turbo SRX graphics hardware to drive them. You'd think that I could simply tell X windows that it has two displays, the left one and the right one, but that would be unthinkably simple. After all, if toys like Macintoshes can do this, unix has to make it much more difficult to prove how advanced it is.

    So, what I really have is two display devices, /dev/crt0 and /dev/crt1. No, sorry, I lied about that.

    You see, the Turbo SRX display has a graphics plane (with 24 bits per pixel) and an overlay plane (with 4 bits per pixel). The overlay plane is for things like, well, window systems, which need things like cursors, and the graphics plane is to draw 3D graphics. So I really need four devices:
    No, sorry, I lied about that. /dev/ocrt0 only gives you 3 out of the 4 overlay bits. The fourth bit is reserved exclusively for the private use of federal emergency relief teams in case of a national outbreak of Pixel Rot. If you want to live dangerously and under threat of FBI investigation, you can use /dev/o4crt0 and /dev/o4crt1 in order to really draw on the overlay planes. So, all you have to do is tell X windows to use these o4 overlays, and you can draw graphics on the graphics plane.

    No, sorry, I lied about that.

    X will not run in these 4 bit overlay planes. This is because I'm using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can't hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you're using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly.

    So, thinks I to myself cleverly, I shall run X windows on the graphics plane. This means X will not use the overlay planes, which have special hardware for cursors. This also means I cannot use the super cool 3D graphics hardware either, because in order to draw a cube, I would have to "steal" the frame buffer from X, which is surly and uncooperative about that sort of thing.

    What it does give me, however, is a unique pleasure. The overlay plane is used for /dev/console, which means all console messages get printed in 10 Point Troglodyte Bold, superimposed in white over whatever else is on my screen, like for example, a demo that I may be happen to be giving at the time. Every time anyone in the lab prints to the printer attached to my machine, or NFS wets its pants with a timeout, or some file server threatens to go down in only 3 hours for scheduled maintenance, another message goes onto my screen like a court reporter with Turett's syndrome.

    The usual X commands for refreshing the screen are helpless to remove this incontinence, because X has no access to the overlay planes. I had to write a program in C to be invoked from some xterm window that does nothing but wipes up after the mess on the overlay planes.

    My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said "Why would you ever need to point to something that you've drawn in 3D?"

    Of course, HP claims X has a mode which allows you to run X in the overlay planes and "see through" to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn't actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they've only tested it on the simpler, less advanced configurations. When you've got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.

    Myth: X is "Device Independent"
    X is extremely device dependent because all X graphics are specified in piel coordinates. graphics drawn on different resulution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a ertain size. N ot all screens een have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.
    A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses enen though you scaled the rectangle corner coordinates to compensate for the aspect ratio.

    The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's "Cheese Shop" sketch, or a grail seeker in "Monty Python and the Holy Grail." Even the simplest applications must answer many difficult questions:

    The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner. NeWS has integrated extensions for input, lightweight processes, networking, and windows. It can draw and respond to input in the same arbitrary coordinate system and define window shapes with PostScript paths. The Display PostScript extension for X is intended for output only and doesn't address any window system issues, which must be dealt with through X. NEXTSTEP is a toolkit written in Objective-C, on top of NeXT's own window server. NEXTSTEP uses Display PostScript for imaging, but not for input. It has an excellent imaging model and well designed toolkit, but the Display PostScript server is not designed to be programmed with interactive code: instead all events are sent to the client for processing, and the toolkit runs in the client, so it does not have the low bandwidth, context-switching, and code-sharing advantages of NeWS. Nevertheless, it is still superior to X, which lacks the device-independent imaging model.
    On the other hand, X's spelling has remained constant over the years, while NeXT has at various times spelled their flagship product "NextStep," "NeXTstep," NeXTStep," "NeXTSTEP," "NEXTSTEP", and finally "OpenStep." A standardized, consistent spelling is certainly easier on the marketing 'droids.
    Unfortunately, NeWS an d NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude(TM).
    X: On the Road to Nowhere
    X is just so stupid, why do people use it? Beats us. Maybe it's because they don't have a choice. (See Figure 2)
    Nobody really wants to run X: what they do want is a way to run several applications at the same time using a large screen. If you want to run Unix, it's either X or a dumb character-based terminal.
    Pick your poison.

  39. Why didn't you quote the rest? by Anonymous Coward · · Score: 0

    Actually we know we should not try to mislead when one quotes from seemingly authoritative sources. The entire paragraph from whence you quoted stated:
    "Disk subsystem performance is a critically important factor in overall system performance, and NTFS is generally believed to be slower than FAT. However, with a correctly created NTFS volume, NTFS performance optimizations, and improved disk defragmentation, NTFS performance (including the extra "journaling") is equivalent to FAT on small disks and is faster than FAT on large disks."

    The rest of the article will help one understand what they mean by "correctly created NTFS volume", etc.

    -Me, not U

  40. UFS + soft updates by voisine · · Score: 1

    I'm using soft updates on my BSD system.
    It's fast, stable, no fscking after a
    dirty reboot. Anyone know of benchmarks
    comparing this to ext3 or riser?

  41. Ext3 is fine... by I.T.R.A.R.K. · · Score: 0

    ...as long as you're not using it to store anything you plan on keeping for more than a week at a time.
    When that bitch crashes, she crashes HARD(and often). Kiss everything you hold dear goodbye.

    --

    "Adequacy.org: Where congenital stupidity is not an option, but a requirement."

    1. Re:Ext3 is fine... by vstanescu · · Score: 1

      I have machines running for more than a year full on ext3 (inc. root) over a software mirroring raid (it does not really matter, but may be this increases the complexity of the actions the machine performs). The filesystems survived to a power outage when the generator failed to start before draining out the UPS and also to a hardware lock when a HDD controller broke down and somehow made the SCSI chain unusable (all the other HDDs became inaccesible). I am pretty happy with it, and althoug it is very intensive used - e-mail, syslog from a lot of cisco routers, netflow collection (this is really big - about 80G of logs/month), it created no problem, error or crash.

  42. The other quote is bogus also by Anonymous Coward · · Score: 0

    If you take the time to read the paragraph, you will notice that this reviewer contradicts himself. First he states:
    "NTFS 5 also comes in the box: it?s a brand new NT file system that adds some security enhancements (losing data is very difficult with this high secure file system) and it's more faster than the FAT32."

    A few sentences later he states:
    "NTFS is reliable, but it is slower than FAT 32 format."

    The reviewer seems very confused. Is it faster or slower than FAT32?

    There is no veracity to your claims. At least from these sources.

    -Me, not U

  43. Not a troll! by Cheshire+Cat · · Score: 1, Troll

    I don't know how accurate this is because its a bit beyond my technical knowledge. However I know that following a hash collision while using RFS, my /usr/local directory vanished. So there is some truth to the parent post.

    --

    Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
    1. Re:Not a troll! by Anonymous Coward · · Score: 0

      I agree. It's like the other morning. I went out to get the morning paper; it was still dark. But there was a mockingbird singing on my neighbor's chimney. He kept singing and singing. About 45 minutes later the sun came up. I've been thinking about that all week. Without a doubt, that mockingbird singing made the sun rise.

    2. Re:Not a troll! by Anonymous Coward · · Score: 0


      Hi, Hans! How's that medication holding up?

    3. Re:Not a troll! by Anonymous Coward · · Score: 0

      Holding up? Pretty good, thanks. I feel normal.

  44. JPEG is better than GIF you moron by Anonymous Coward · · Score: -1, Troll

    Besides, they say that they used OpenOffice for the graphs, and it saves as JPEG.

  45. Your bong had a hash collision by gregor_b_dramkin · · Score: 4, Funny

    ... that's why you lost your data. It annoys me to no end when people assume a cause for a problem and begin to state it as fact without verification or fact.

    Is it possible that there is a bug in reiserfs? Sure. I just don't trust anecdotal evidence from some dood on /.

    --
    You can never equivocate too much.
  46. Why always Linux? by evilviper · · Score: 2, Interesting

    Why doesn't anyone compare UFS/FFS w/softupdates enabled to the Linux filesystems?

    Better yet, why did EXT get to be the defacto Linux filesystem, rather than UFS? It outperforms, and supports much large files/filesystems.

    A comparison of UFS from a platform other than FreeBSD might be in order.

    --
    Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    1. Re:Why always Linux? by Anonymous Coward · · Score: 0

      Probably because it wouldn't say much. There is a big difference between the two systems, so a comparision would be affected by other subsystems.

      Ext2 and ext3 are both quite close to UFS in design, and should preform similarly.

    2. Re:Why always Linux? by RustyTaco · · Score: 1

      > why did EXT get to be the defacto Linux filesystem, rather than UFS?

      My understading of the sitation is that it was because until softupdates were implemented UFS was painful. Now, had softupdates been implemented, say, 7-10 YEARS ago when EXT became the Linux de-faco filesystem there might have been a chance.

      On the flip side, seeing a good Linux implementation of a BSDish UFS with softupdates would be very nice.

      - RustyTaco

    3. Re:Why always Linux? by kryptobiotic · · Score: 2, Interesting

      Just today I was working on getting some molecular dynamics code to work on a DEC PWS 500au. This code writes some large (3GB-500MB) files to the disk. On a fresh striped down (~400MB) install of RedHat 7.1 using ext2, bonnie showed throughputs of about 20MB/s for sequential read/writes of a 512 MB file.

      On a fresh install of FreeBSD 4.6 using UFS, bonnie reported more than 30 MB/s on the same machine.

      I know this isn't really what you were looking for but it surprised me that there was that much of a difference.

    4. Re:Why always Linux? by m.dillon · · Score: 2, Interesting

      Just for the hell of it I ran the same benchmarks on one of my test boxes (FreeBSD running -current). The performance basically comes down to how much write latency you are willing to endure... the longer the latency, the better the benchmark results for the first two tests.

      So, for example, with the (conservative) system defaults I only got around 250 trans/sec for mixed creations with the first postmark test, because the system doesn't allow more then around 18MB of dirty buffers to build up before it starts forcing the data out, and also does not allow large sequential blocks of dirty data to sit around. When I bump up the allowance to 80MB and turn off full-block write_behind the trans rate went up to 2776/sec. I got similar characteristics for the second test as well. Unfortunately I have only one 7200 rpm hard drive on this box so I couldn't repeat the third test in any meaningful way (which is a measure mostly of disk bandwidth).

      In anycase, the point is clear, and the authors even mention it by suggesting that the ext3 write-back mode should only be used with NVRAM. Still, I don't think they realize that their RedHat box likely isn't even *writing* the data to the disk/NVRAM until it absolutely has to, so arbitrarily delaying writes for what is supposed to be a mail system is not a good evaluation of performance. Postmark does not fsync() any of the operations it tests whereas any real mail system worth its salt does, and even with three drives striped together this would put a big crimp on the reported numbers unless you have a whole lot of NVRAM in the RAID controller.

      I do not believe RedHat does the write-behind optimization that FreeBSD does. This optimization exists specifically to maximize sequential performance without blowing up system caches (vs just accumulating dirty buffers). But while this optimization is good in most production situations it also typically screws up non-sequential benchmark numbers by actually doing I/O to the drive when the benchmark results depend on I/O not having been done :-).

      Last thought. Note that the FreeBSD 4.6 release has a performance issue with non-truncated file overwrites (not appends, but the 'rewrite without truncation' type of operation). This was fixed post-release in -stable.

      -Matt

    5. Re:Why always Linux? by evilviper · · Score: 2

      EVEN IF ext2 is considerably faster than UFS (which I doubt...) that wouldn't change the fact that it is much more stable (I've lost several ext2 fs's). That's besides the fact that UFS supports much large files and filesystems.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    6. Re:Why always Linux? by Anonymous Coward · · Score: 0

      UFS and ext2 are very closely related in how they work, you're only basing youre ext2 assumptions on previous bad (and outdated) experiences.

    7. Re:Why always Linux? by Anonymous Coward · · Score: 0

      The only reason why people perceive ext2 to be faster than straight ufs is because it usually gets mounted asyncronously. Async is useless though because it comes at too high a cost.

    8. Re:Why always Linux? by Anonymous Coward · · Score: 0

      [UF]FS were designed for quite another world and were severely hacked on during last ten years or so to make 'em live with stuff that suddenly appeared.

      Later -- just dumped in front of better ones in normal Unices. To base from-scratch OS on legacy crap would be definitely unworthy approach, even if EXT wouldn't really kick arse.

      And -- do you trust the whole idea behind soft updates? I don't (and BSD admins around tend to support this feeling), it's mess highly prone to design and implementation faults.

      So you statement about benefits of ancient FSes is largely inverted. Peace :)

  47. Danger, Will Robinson by Anonymous Coward · · Score: 2, Informative
    If you are using soft updates and not running fsck after a dirty reboot, then you don't understand soft updates. You are also flirting with loss of data.

    Here is what you are missing. Soft updates is a method of ensuring that disk metadata is recoverably consistent without the normal speed penalty imposed by synchronous mounting. The only guarantee that softupdates makes is that your file system can be recovered to a consistent state by running fsck. Soft updates is designed to aid the running of fsck, but does not eliminate the need.

    Better get out your Palm add running fsck to your "to-do" list.

  48. As always, it depends on what is on the filesystem by SwellJoe · · Score: 5, Informative
    Yes, folks, some filesystems are faster than others for some type of file.

    We benchmark ReiserFS versus all other Linux filesystems about once every 6 months or so, and the last one from about 3 months ago still places Reiser in the "significantly faster" category for our workloads, specifically web caching with Squid.

    ext3 is a nice filesystem, and I use it on my home machine and my laptop. But for some high performance environments, ReiserFS is still superior by a large margin. It is also worth mentioning that I could crash a machine running ext3 at will the last time we ran some Squid benchmarks (this was on 2.4.9-31 kernel RPM from Red Hat, so things have probably been fixed by now).

    All that said, I'll be giving ext3 vs. ReiserFS another run real soon now, since there does seem to be some serious performance and stability work going into ext3.

  49. Journaling by Anonymous Coward · · Score: 0
    Softupdates is not the same as a journaled file system. Do your homework. Apples and oranges. Your assignment: write a 1800 word essay summarizing soft updates and journaling file systems. Discuss differences, strengths, and weaknesses of each.

    Methinks that you need to crack the books.

    1. Re:Journaling by Anonymous Coward · · Score: 0

      Do your own fscking homework. They're not the same, but they purportedly address exactly the same problem and thus *are* comparable.

    2. Re:Journaling by Anonymous Coward · · Score: 0
      Please, point us to any quote written by any well known developer which supports your assertion that the two file systems "address exactly the same problem" (as you put it). Perhaps you would like to tell us what that problem is. Honestly, you don't have a clue.

      Journaling and soft updates are completely orthognal. Indeed, one could imagine a journaling file system which incorporated soft updates.

    3. Re:Journaling by Salamander · · Score: 2

      OK, asshole. How about we start with Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems presented at USENIX 2000? The first three authors should need no introduction, so I think it satisfies the "well known" requirement; in fact, one could hardly find a group of six people more qualified to comment on the matter. Even in the abstract, the authors clearly state the similarity between goals of journaling and soft updates:

      In this paper, we explore the two most commonly used approaches for improving the performance of meta-data operations and recovery

      The similarity is mentioned repeatedly elsewhere in the paper, all the way to the conclusion, but I'll let you do your homework this time.

      Anybody who knows anything about filesytems - and I've been working on them for over a decade - recognizes the similarity in goals between journaling, soft updates, and phase trees. Usually it's considered too obvious even to require comment, unless an ignorant troll like you comes along demanding that the obvious be spelled out.

      --
      Slashdot - News for Herds. Stuff that Splatters.
    4. Re:Journaling by Anonymous Coward · · Score: 0
      Well Salamandar, you are another clueless loser who throws around buzzwords but can't explain them. Soft updates have absolutely nothing to do with a journaled file systems. Nada.

      Maybe your local community college offers some CS courses which will teach you the basics. There is nothing wrong with being ignorant that a little learning can't cure. Avail yourself to it.

    5. Re:Journaling by Anonymous Coward · · Score: 0

      Give it up, Junior. Only one person in this discussion has provided a cite to back up their assertions...and it wasn't you. Only one person has expressed an opinion better than "is not, neener neener neener"...and it wasn't you. You've just had your head handed to you, and you're too freaking stupid even to realize it. Maybe getting bashed to a pulp by real professionals is the only way you get to interact with them at all, but even watching you spew ad hominems as you get knocked around gets boring after about the third iteration.

    6. Re:Journaling by Anonymous Coward · · Score: 0
      You're slicing your baloney too thick. You losers and 1337 hacker wanna-be types love tossing around big words but when your bluff is called you sputter and stall. You don't have a clue.

      Here is a hint from the cluemobile: Softupdates does not equal journaling. That is a fact. When school starts again in September, you can ask the TA to explain it to you. Now mow the lawn before your mama takes away your GTA3.

    7. Re:Journaling by Anonymous Coward · · Score: 0

      "you can ask the TA to explain it to you"

      They don't have TA's in elementary school.

    8. Re:Journaling by Anonymous Coward · · Score: 0

      Nobody ever said soft updates are *the same as* journaling, shithead. They just address the same problem, as demonstrated by the cite provided. You haven't provided *one bit* of evidence to support a contrary position, just an endless stream of content-free insults that anyone could make up. You're the one who's bluffing. Put up or shut up, microdick.

    9. Re:Journaling by Anonymous Coward · · Score: 0
      You tried to bullshit us, Salamander. You tried but we called you on it. You didn't know what you were talking about and you were caught with your pants down and wrapped around your ankles.

      What part of "not equivalent" do you not understand? Soft updates does not equal journaling. Period. Full stop. End of story.

      Time for you to go to library or take a course in operating systems. You seem to have an interest in this stuff. Wouldn't it be better to learn what the words mean first, before you use them?

    10. Re:Journaling by Anonymous Coward · · Score: 0

      Wow. You don't even know the difference between "equal" and "equivalent", or between evidence and simple restatement, and you're still using tired old "take a course" insults? What a total idiot. You've still provided *zero* evidence to support your absurd POV, despite repeated prodding to do so. You're not even worth kicking around any more; wouldn't want to get any on my shoes.

    11. Re:Journaling by Anonymous Coward · · Score: 0

      Your record so far: six posts, zero proof, zero information, zero humor, zero class. What a zero.

  50. Why I like reiserfs by HipPriest · · Score: 1, Insightful

    I like reiserfs because I can trust it to perform well on any file system load. I can put it on a server and know it will be fast and efficient regardless of what the users do. Ext3 gives ext2 journaling, but does not add efficient large directories or small files, two features that reiserfs has.

    Sure ext3 may benchmark slightly faster in certain scenarios. But unless you know ahead of time that those are the only scenarios you are going to put on the file system, I recommend reiserfs.

  51. Testimony by alanwj · · Score: 1

    I can't say much about ReiserFS. We use it on a server in one of the computer labs I admin at school, but that's the extent of my experience.

    But ext3.. I've been using it since the day RH7.3 was released, during which time I'll bet power to my machine has been cut at least 150 times (we had a bad circuit breaker that would randomly flip. I replaced it a few days ago). Often power was repeatedly lost many times in a short period of time (if that would matter), and in the middle of big disk write operations.

    Every single time I have been able to immediately reboot without any apparent data loss (except for the data being written at that very second) or filesystem corruption (a couple of times I forced a check just to make sure nothing was wrong, and nothing ever was).

    I can't testify to the relative quality of ext3 compared to ReiserFS, but I can certainly say I have been quite pleased with the stability of ext3.

    -Alan

  52. Picture history by Anonymous Coward · · Score: 0

    I saw that back in 1995 or earlier.
    It was a common X background image.
    I think I remember it from 1994 even.

  53. Re:Can you document that? by Anonymous Coward · · Score: 0

    blah then you'd waste all of that energy previewing a post intended for a troll or idiot

  54. Re:As always, it depends on what is on the filesys by Anonymous Coward · · Score: 0

    When you benchmarked, what mode (ordered, writeback, journalled) did you use ext3 in?

  55. EXT3 is to EXT2 as VFAT is to FAT by Diesel+Dave · · Score: 1

    Hell you can get blazing speed out of FAT, but do you want to use it? EXT3 turned me off the second I founoutit it's journeling was a 'bolt on' addition. (Metadata is kept is a private file...very ugly)

    ReiserFS has eaten more megabytes then I would have liked...but that was 2 years ago. Comparing Resier which is a mature, next generation FS to EXT3, a revamp which isn't even done yet, is a bad idea.

    1. Re:EXT3 is to EXT2 as VFAT is to FAT by HiThere · · Score: 2

      I understand your point. But their point was (paraphrased):
      "We need to choose a file system. Let's try to experimentally determine which of out two prime contenders is best."

      You may feel that their selection of contenders is incorrect, but to select between them based on experiment is called "the experimental method" (sometimes mistakenly "the scientific method". This is the basis of science, engineering, and technology. I.e.: Don't assume ahead of time that you know the right answer, check.

      If they didn't find the problems that you expected, then perhaps you need to examine why. But a hand-waving "explanation" doesn't explain very much, so I don't even really know what problems you think they should have found. FWIW, I haven't noticed any instability problems with ext3.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  56. For multimedia playback? by Jeremi · · Score: 3, Informative

    Does anyone have info on which of these file systems might be the better one for glitch-free playback of multitrack uncompressed audio? (I'm thinking of up to 16 simultaneous streams, so effiicent throughput would be the priority -- BeOS's BFS was optimized for this sort of thing, but I don't know who in Linux-land has been focused on that aspect of performance)

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.
    1. Re:For multimedia playback? by Anonymous Coward · · Score: 0

      Take a look at XFS.

    2. Re:For multimedia playback? by guile*fr · · Score: 1

      XFS have realtime zones... never tried though... and XFS can badly thrash files opened in write mode during a crash :-(

  57. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  58. I use both by JebusIsLord · · Score: 3, Insightful

    I use ext3 in ordered mode for my "/" and "/usr" partitions for its data journaling, and reiserfs with -notail for my /tmp and /pub partitions (pub is an FTP/SMB fileserver, lots of activity). I think this is a good compromise between performance and non-corrupability (sp?)

    --
    Jeremy
    1. Re:I use both by joss · · Score: 2

      Very clever. Except that ext3 is less stable than ReiserFS.

      --
      http://rareformnewmedia.com/
    2. Re:I use both by JebusIsLord · · Score: 1

      um any explaination, or is that a troll? ext3 does metadata AND data journalling and is forwards/backwards compatible with ext2 - what makes it unstable?

      --
      Jeremy
    3. Re:I use both by HiThere · · Score: 2

      I haven't experienced any problems with ext3, and I've used it (light loads only) ever since it was a Red Hat standard file system.

      OTOH, a year (I think) earlier, when Mandrake released a Reiser file system option, I tried it, had disk corruption, and couldn't find any tools that helped recovery.

      Now these are single data points, so you shouldn't take them too seriously. Also, around the same time that I had file corruption under Reasser, I also had an ext2 file system become corrupt. I even know that the problem was caused by fsck. (I was running from a secondary hard disk. I think that this may have been a kernel problem.) The point is, I was able to recover from the ext2 file system corruption, but was unable to recover from the Reisser file system corruption.

      So I didn't find either system to be more reliable than the other. But ext2 was recoverable, and I was unable to recover the Reiser file system.

      Again, let me stress, this was under light use. The system was one that I was using for development and experimentation, not one that I did serving from or kept serious data on. So usage patterns wouldn't match a production machine.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  59. Rebooting is easier than killing X ? by Anonymous Coward · · Score: 0

    Ctrl-Alt-Backspace will kill and restart X.
    Or you could just hit Ctrl-Alt-F1 to toggle to tty1 and wake up the monitor, then Ctrl-Alt-F7 to go back to X.

    Reboots are only for kernel and hardware upgrades.

    1. Re:Rebooting is easier than killing X ? by Treeluvinhippy · · Score: 1

      I'm a linux newb and I didn't know those shotcuts, thanx

      --
      >
    2. Re:Rebooting is easier than killing X ? by Anonymous Coward · · Score: 0

      FYI, reboots are also needed if you don't have the "magic keystrokes" enabled such that if an X problem locks out your keyboard (...so that ctrl-alt-backspace doesn't work...), the SysRq keypresses may be your only hope of avoiding the R button.

      See http://www.linuxhq.com/kernel/v2.4/doc/sysrq.txt.h tml for details.

    3. Re:Rebooting is easier than killing X ? by forevermore · · Score: 1

      exactly. In my case, no keystroke works (that includes control-alt-delete). And honestly, sometimes it's just easier to reboot the machine than try to manually kill/respawn bad processes. This is a desktop machine, not a server. A little downtime won't hurt anything.

      --
      Do you really need reason for beer? Wingman Brewers
  60. I just have one question... by Rantastic · · Score: 1

    ...what do all those angry spacemen have to do with any of this?

    --
    Ask Slashdot: Where bad ideas meet poor googling skills.
  61. vs other things by Anonymous Coward · · Score: 0

    Can we see results against ufs+softdeps? Or are the linnex kiddies scared?

  62. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  63. Why not ext2?? by d2002xx · · Score: 0

    Why not just use ext2?? I'm wondering why the ext3 and reiserfs exist? since they aren't faster.

    1. Re:Why not ext2?? by Tsugumi · · Score: 1

      You obviously haven't had to fsck a huge filesystem. Telling your customers that the outage would have been 15 minutes rather than >1hr if only you'd used a journaling filesystem would not be fun.

  64. The graphs? by Anonymous Coward · · Score: 0

    Isn't the MB/S graph from page 1 and page 2 switched?

  65. Slashdot fight agains standards. by Nicopa · · Score: 3, Informative
    Also: Slashdot (the founders/owners/editors) is notorious for saying one thing and doing another. Witness the virulent anti-DMCA stance, yet, notice also how they support the very companies who forced it upon us (aka Sony). Witness their yammering about IE/MS not following standards when in fact their own HTML on thier own site is grossly out of established standards.

    Completely true. I've filed a bug to the slashdot bug report page in sourceforge to add some semantic tags to the ones we are allowed to use. I'd like to use , , etc. The bug was deleted as quick as it was posible, with no explanation.

    Besides, not only the HTML code doesn't validate. but also Slashdot has blocked the W3C validator!. That's very stupid, as anyone can just download and validate the page uploading it to the validator. Here is the validation result.

  66. I'm curious... by green+pizza · · Score: 2

    I'm curious, how can a script (software) reboot a a server that has already halted?

    1. Re:I'm curious... by doorbot.com · · Score: 2

      How can a script (software) reboot a a server that has already halted?

      The system wasn't halted. The UPS kicked in and ran on batteries for a couple minutes then switched back to mains. The server remained up and running. The apcupsd daemon was set to run a script when hen the utility power returned, and the script was configured to be "shutdown -r now"

      At no point during the process was the system halted.

  67. With Red Hat, at least, journaling is a pain. by emil · · Score: 1, Flamebait

    I don't like the fact that ext3 is now included as a module. The default filesystem driver should be compiled as part of the kernel.

    SGI's version of Red Hat is far preferable to Red Hat's own release for this reason.

    Now, I must create and maintain an initrd on my IDE system (which was never required before), and I've also been in a crazy situation where attempting to mount an installed filesystem under ext3 caused and Oops, but changing fstab to ext2 was fine.

    Down with Red Hat's use of ext3 as a module! Red Hat has never handled journaling in a reasonable manner.

    1. Re:With Red Hat, at least, journaling is a pain. by Anonymous Coward · · Score: 0

      Compile your own kernel, then!

  68. SCSI? How about IDE by Anonymous Coward · · Score: 0

    I noticed these guys have some dandy SCSI drives in their system. Anybody know how these benchmarks would go for IDE systems? Would they show more or less differences?

    Just curious. Reiserfs seems to work fine for me, although I did lose almost a gigabyte of mp3s using in the early days of Reiserfs.

  69. Re: Exchange alternative by Anonymous Coward · · Score: 0

    Try Bynari as an Exchange alternative...

  70. bad bad block handling in reiserfs by kluro · · Score: 0

    I regret using reiserfs on my box due to the ugly hack for bad block handling, see here.

    1. Re: bad bad block handling in reiserfs by Anonymous Coward · · Score: 0

      You have hit on the biggest weakness in the reiserfs. That is where ext3 has the edge. There is no graceful way to mark a bad block on reiserfs after the fact. I still use reiserfs, out of pure inertia. The bad block handling is not a show stopper, but when it bites you, oh do you miss it. When it comes to mature fs debugging tools ext2 (and thus ext3?) has a mighty impressive array. I don't think I've seen any OS other than Irix which had such good tools as the ext2 debugging facilities.

  71. oh dear God man! by Ender+Ryan · · Score: 2
    "Welcome to Windows. Press Ctrl-Alt-Del to log on."

    Oh dear God man, I would never want that! Is it really possible for that to happen to my Linux box with ext3? I'm switching to ReiserFS right away!

    Thanks for the warning!

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
  72. OT: 22 spotted ladybug by jovlinger · · Score: 2

    I love that band!

    Bare bone nest is one of 5 records that keeps the LP player hooked up to the stereo.

  73. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  74. Hardware Failures Happen by electricmonk · · Score: 1

    If your UPS fails, it helps a lot. Besides, a lot of machines run software that isn't a transaction-capable database (for example, Slashdot's servers). It just makes more sense to have this kind of transaction-like functionality at a lower level so it is available to all applications, instead of stuffing it into all your user-level applications seperately.

    --
    Friends don't let friends use multiple inheritance.