Announcement

Collapse
No announcement yet.

Benchmarking ZFS On FreeBSD vs. EXT4 & Btrfs On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by LightningCrash View Post
    So you're saying an SGI supercomputer with 1024 CPUs is not a big box?
    more like 'abomination'. Since they use the Fermi-equivalent of CPUs - Itanics - 'inferno' would be correct to.

    Comment


    • I can add that CERN did a test on their Linux hardware raid, and data was corrupted. (CERN now migrates to ZFS machines)
      http://storagemojo.com/2007/09/19/ce...tion-research/
      Interesting, as far as I know CERN is running all their storage on Red Hat using their in-house developed storage manager CASTOR2 (you can see in the pdf that you linked that they actually discuss how to change Castor to handle the errors they found).

      You seam to be the only source regarding their migration to ZFS so could you please elaborate on this? Also how zfs would achieve end to end protection in a distributed setup like the one CERN has to use (they have thousands of storage nodes and also have storage nodes distributed all over the world).

      Comment


      • So first, you obviously don't know that the btrfs guy was actually a zfs developer before he left sun.
        No he wasn't. Chris Mason worked on ReiserFS not ZFS!

        ZFS was not even on his horizon when he constructed BTRFS, it was a presentation on how to implement Copy on Write compatible B-trees that made Chris develop BTRFS.

        Comment


        • Originally posted by F.Ultra View Post
          No he wasn't. Chris Mason worked on ReiserFS not ZFS!
          You are absolutely correct! Sorry. I think I got confused by reading that LWN article on btrfs, where the author was a former ZFS developer. That wasn't written by Chris Mason, though.

          Comment


          • Kraftman.
            In this PhD thesis, the researcher writes:

            "The challenge in building such a [safe] file system is that one has to use the limited resources available on a typical desktop to implement the various techniques and not to overly reduce the performance which could make the system less attractive."

            He says: a safe filesystem is slow. That is the reason ZFS is slow and the other filesystems are faster - they are unsafe. Again: what is most important to you: speed or data safety? As I told you, I dont care about ZFS speed. I care about data safety.

            But of course, I can reach extreme speed with ZFS if I need to. Several GB/sec and 100.000s of IOPS is possible, just look at the ZFS server I linked to. That is much higher performance than BTRFS ever can deliver today. That ZFS server is basically a PC with OpenSolaris and ZFS and lots of discs and some SSD drives. I can basically build it at home. Again: I dont care about speed.

            Maybe in the future when BTRFS is done, it can deliver as high performance as ZFS servers can. But not now, as BTRFS is under development. Again: I care about data safety. Not speed.




            Originally posted by kraftman View Post
            It is obsolete since some time thus you were FUDing.
            If I FUD, then prove that I lie or write false negative things. I do not lie or make up things like you Linux fans confessed you do. When I write something, I have read it from researchers, Linux developers, Linus T, etc. I can always post links to my claims, they are credible. I never make up things.




            Regarding the discussion about data corruption in XFS, JFS, ext3, in a research paper I linked to. You showed me some quotes and I asked if you have links?
            Originally posted by kraftman View Post
            Of course:
            Please, dont say "Of course". Almost very time I have asked you to show links, you have never showed any credible links. You have said many bold things, and never(?) shown a credible link. Where are the posts where I lie and FUD? Show me them! You have never showed such posts where I lie or FUD, I have asked you many times.




            This is weird. The Linux dev says that they have only implemented (IRON FS) journal checksumming, and nothing else from the PhD thesis have been implemented. Does journal checksumming make ext4 safe, to you? Are you serious?

            The PhD researcher also develops something called IRON ext3 to make it more data safe. This IRON is what went into Linux filesystems. But the key is "more data safe". Not completely data safe.



            page 70 - he wants to catch as many errors as he can, with the given CPU resources he has. BUT he can only catch single errors, not double errors!
            "We now describe our implementation and evaluation of IRON ext3 (ixt3). Our design goal is to detect and recover from most errors with an affordable time and space cost
            ...
            we use a simple parity-based redundancy scheme for data blocks that can only recover from a single block error per file."


            page 79 - he builds data safety around his model, but his model is flawed he says. Therefore the data safety is also flawed. It can only handle single errors, not double errors.
            "To handle block failures within the file system, one must have a model of how such block failures occur.
            ...
            In this section, we propose a probabilistic disk failure model that characterizes disk block errors with spatial locality and use this model to layout blocks such that the probability of two or more errors affecting related blocks is low."



            This is not good! He uses a probabilistic approach! It is not deterministic! Kraftman, no, this does not do at all. There is always a small chance of introducing more errors, as he uses a probability based data safety mechanism. Most of the time he corrects the error, but some times he fails. This is not safe. Kraftman, you should read the paper. Have you? No? Ok.

            And he is using an Exponential Distribution which is not really good. The advantage of Exponential Distribution is that the analysis is much simpler mathematically, but not really realistic. Se here for drawbacks of the Exponential Distribution:


            No Kraftman, this researcher only shows there are lots of problems in ext3, XFS, JFS, etc and he makes these filesystems slightly safer with his IRON approach. But he admits IRON is flawed and not completely safe. Just read the pages above and you will see why it is not safe.

            And besides, do you really expect one researcher to be able to make those filesystems safe during a 3 year period when he is a research student? He may be bright, but it takes many years of experience from Storage Enterprise server halls to know much about data corruption. For instance, do you expect a bright research student to rewrite Linux kernel, but much better, in just 3 years? No? But why do you assume he is better than the whole ZFS team (who has lots of new and innovative patents) in just 3 years? And the research student admits his IRON FS has flaws and is not safe. Ergo, IRON is not safe. He found problems in Linux filesystems, yes. Then he tries to make them better, but does not make them completely safe.

            On the other hand, the whole team of computer sci researchers did not found any problems with ZFS. I am not claiming that ZFS gives complete data safety, that would be impossible(?) to prove - but I am saying that ZFS gives much better data safety. No data safety problems where found in ZFS. Just look at the research paper I posted. Most probably, ZFS gives among the best data safety on the market, if not the best data safety on the market.




            Originally posted by kraftman View Post
            I don't see papers out there. Can you give links directly to the papers not to some blogs?

            Again, where are the papers backing up your claims? As far I can see only one paper, but which is obsolete when comes to some Linux file systems.
            Ok, so now you admit you can see ONE paper on data corruption? You said earlier I did not post any papers at all on this, and I lied and FUDed about this. I told you many times that I did post research papers. I told you to read this post to see more papers on data corruption, but you deny there are papers. Great.
            Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.


            This proves again, that you lie about me. First you said "you lie, there are no papers" and now you confess there is at least ONE paper. So, I did not lie. Actually, it was you who lied about me. You owe me an apology for lying about me. Earlier you confessed you also FUD. So when I say that Kraftman is a FUDer and Liar - I speak true. I can prove that Kraftman lies and he FUDs. And all the time, you accuse me of FUDing and lying? That is hilarious. You have no proof I do that. Never ever have you quoted me lying or FUDing. Cartman, you are too much. Show me a quote where I lie or FUD. Go ahead. I have asked you this, many many times.

            You see Cartman, which difficulties I have with you? I say: "I have posted several research papers on data corruption here":
            Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.

            And you say "no, you lie, there are no research papers there".
            Actually, I dont know what to say. I mean, there are research papers there, but you deny that. What can I say? It is like
            -Look the sun is shining!
            -No it isnt
            -Yes it is! look at the sun!
            -No, the sun is not shining.
            ...

            I mean, there are research papers there. But you deny that and say I lie. This is so blatantly obvious so everone who reads that link can indeed see that you do lie about me. This is an obvious lie from you. The other things you claim, can not be so easily controlled. But maybe they are lies, too?

            How can I get you to admit that there are research papers in my post? How can I get you to admit that when Linux kernel devs say the code is buggy and bad quality, they mean it? I mean, ordinary logic does not work on you. Nor does normal reasoning. Nor does posting of links. I mean, I can copy and paste post those research papers here, but that does not help. Why would it? You would just deny them, even when you see them.

            Kraftman, again. I have proved that you lie and FUD, you have never proved or quoted I do the same as you do. I am not interested in debating with people that have not finished fourth grade or Liars and FUDers. I work with very talented and bright people and I do not see why I must put up with your FUD about me. I can not even make you admit there are research papers which is obviously true. I can not make you admit something that is obviously true. How can I make you admit anything about Linux? That would be impossible! Again. If you have something sane to say, I will listen. But when you repeatedly FUD and lie about me and about Solaris - and never ever provide credible links, I dont have to accept your Trollism. Ok? Come back when you change and have something sane to say, and when you stop all the foul language and bad mouthing. Then I gladly debate with you again.

            (Seriously, I feel sad for you. Life must be have been very hard on you. I can not understand how hard school must have been for you. Your teacher say something, and you dont understand anything. And get bad grades. And people think you are difficult to discuss with, or unpleasant. Kraftman, you dont think like normal people, you will never get a job if you dont change behaviour. Imagine if you start a discussion like this with your boss or a collegue??? Catastrophy. They would consider you mad, you will get a bad reputation. Try to do something about it instead. Try to eat Omega-3 fish oil, that makes a human brain much better. Studies show that people with ADHD and other psychical conditions, gets much better with Omega-3 fish oil. I encourage you to try it. I eat it myself, it is very good for the brain! It is the best advice I can give you.)






            For the rest of you, who does not have the nick Kraftman, you can read my link I and see the research papers. Or, here I copy and paste them just for you, so you see that filesystems and raid5&6 has lots of problem with data safety. Here is my original post:
            Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.

            Here is an excerpt from the post with research papers.
            "http://www.cs.wisc.edu/adsl/Publicat...ion-fast08.pdf
            "Detecting and recovering from data corruption requires protection techniques beyond those provided by the disk drive. In fact, basic protection schemes such as RAID [13] may also be unable to detect these problems.
            ..
            As we discuss later, checksums do not protect against all forms of corruption"

            From above, you can not just add some checksums all over the place into BTRFS and expect to get data integrity. Ok? Not even mature techniques as Raid are safe (which many falsely believe). Do you finally understand now why I doubt BTRFS to be safe? Why must I educate all these Linux people all the time? *sigh*




            "Recent work has shown that even with sophisticated RAID protection strategies, the “right” combination of a single fault and certain repair activities (e.g., a parity scrub) can still lead to data loss [19]."



            I can add that CERN did a test on their Linux hardware raid, and data was corrupted. (CERN now migrates to ZFS machines)




            A whole site with lots of articles dedicated to explain all the flaws in raid-5




            Regarding raid-6:

            "The paper explains that the best RAID-6 can do is use probabilistic methods to distinguish between single and dual-disk corruption, eg. "there are 95% chances it is single-disk corruption so I am going to fix it assuming that, but there are 5% chances I am going to actually corrupt more data, I just can't tell". I wouldn't want to rely on a RAID controller that takes gambles :-)"



            Let me tell you, I have PLENTY of material on Silent corruption. Including many research papers. Just tell me if you want more information on silent corruption. Actually, it is very interesting read, to see how bad the situation is with current storage situation. (Please, someone ask me, to post all this material! )"



            I will post more, later. Stay tuned.

            Comment


            • Originally posted by kebabbert View Post
              Kraftman.
              In this PhD thesis, the researcher writes:

              "The challenge in building such a [safe] file system is that one has to use the limited resources available on a typical desktop to implement the various techniques and not to overly reduce the performance which could make the system less attractive."

              He says: a safe filesystem is slow. That is the reason ZFS is slow and the other filesystems are faster - they are unsafe. Again: what is most important to you: speed or data safety? As I told you, I dont care about ZFS speed. I care about data safety.
              ZFS can be slow because of its stupid design. While Linux devs read those papers and made changes, when even people from this paper made changes to Ext3 and made it safe and while Ext3 is faster and while Ext4 with 'safety patches' from the paper is faster and while we can be nearly sure 'btfrs' is designed to be safe and all of this file systems are faster then zfs - a safe file system doesn't have to be slow.

              But of course, I can reach extreme speed with ZFS if I need to. Several GB/sec and 100.000s of IOPS is possible, just look at the ZFS server I linked to. That is much higher performance than BTRFS ever can deliver today. That ZFS server is basically a PC with OpenSolaris and ZFS and lots of discs and some SSD drives. I can basically build it at home. Again: I dont care about speed.
              FUD. Show me this is much higher performance than BTRFS ever can deliver today.

              Maybe in the future when BTRFS is done, it can deliver as high performance as ZFS servers can. But not now, as BTRFS is under development. Again: I care about data safety. Not speed.
              FUD. Prove me it can't deliver as high performance as zfs.

              If I FUD, then prove that I lie or write false negative things. I do not lie or make up things like you Linux fans confessed you do. When I write something, I have read it from researchers, Linux developers, Linus T, etc. I can always post links to my claims, they are credible. I never make up things.
              In my opinion you're lying nearly all the time. While you can't proof what you're claiming is right, why should I bother proving you things? Those links you're giving are usually not credible. Prove me I lie.

              Regarding the discussion about data corruption in XFS, JFS, ext3, in a research paper I linked to. You showed me some quotes and I asked if you have links?

              Please, dont say "Of course". Almost very time I have asked you to show links, you have never showed any credible links. You have said many bold things, and never(?) shown a credible link. Where are the posts where I lie and FUD? Show me them! You have never showed such posts where I lie or FUD, I have asked you many times.
              No, you almost never (or never) showed a credible link. While you're FUDing or lying nearly all the time in your posts.

              This is weird. The Linux dev says that they have only implemented (IRON FS) journal checksumming, and nothing else from the PhD thesis have been implemented. Does journal checksumming make ext4 safe, to you? Are you serious?
              Where is it stated "only" journal checksumming is implemented?

              The PhD researcher also develops something called IRON ext3 to make it more data safe. This IRON is what went into Linux filesystems. But the key is "more data safe". Not completely data safe.



              page 70 - he wants to catch as many errors as he can, with the given CPU resources he has. BUT he can only catch single errors, not double errors!
              "We now describe our implementation and evaluation of IRON ext3 (ixt3). Our design goal is to detect and recover from most errors with an affordable time and space cost
              ...
              we use a simple parity-based redundancy scheme for data blocks that can only recover from a single block error per file."


              page 79 - he builds data safety around his model, but his model is flawed he says. Therefore the data safety is also flawed. It can only handle single errors, not double errors.
              "To handle block failures within the file system, one must have a model of how such block failures occur.
              ...
              In this section, we propose a probabilistic disk failure model that characterizes disk block errors with spatial locality and use this model to layout blocks such that the probability of two or more errors affecting related blocks is low."



              This is not good! He uses a probabilistic approach! It is not deterministic! Kraftman, no, this does not do at all. There is always a small chance of introducing more errors, as he uses a probability based data safety mechanism. Most of the time he corrects the error, but some times he fails. This is not safe. Kraftman, you should read the paper. Have you? No? Ok.

              And he is using an Exponential Distribution which is not really good. The advantage of Exponential Distribution is that the analysis is much simpler mathematically, but not really realistic. Se here for drawbacks of the Exponential Distribution:
              http://www.reliasoft.com/newsletter/...xponential.htm
              Show me it's different in zfs.

              No Kraftman, this researcher only shows there are lots of problems in ext3, XFS, JFS, etc and he makes these filesystems slightly safer with his IRON approach. But he admits IRON is flawed and not completely safe. Just read the pages above and you will see why it is not safe.
              This is paper from 2006 and Linux devs could use something more then "IRON". Where's about zfs being safe? In which paper?

              And besides, do you really expect one researcher to be able to make those filesystems safe during a 3 year period when he is a research student? He may be bright, but it takes many years of experience from Storage Enterprise server halls to know much about data corruption. For instance, do you expect a bright research student to rewrite Linux kernel, but much better, in just 3 years? No? But why do you assume he is better than the whole ZFS team (who has lots of new and innovative patents) in just 3 years? And the research student admits his IRON FS has flaws and is not safe. Ergo, IRON is not safe. He found problems in Linux filesystems, yes. Then he tries to make them better, but does not make them completely safe.
              I assume Linux devs team is better then ex-sun team. Is zfs completely safe? No.

              On the other hand, the whole team of computer sci researchers did not found any problems with ZFS. I am not claiming that ZFS gives complete data safety, that would be impossible(?) to prove - but I am saying that ZFS gives much better data safety. No data safety problems where found in ZFS. Just look at the research paper I posted. Most probably, ZFS gives among the best data safety on the market, if not the best data safety on the market.
              I doubt it gives the best data safety on the market:



              this bug probably caused a lot of mess:



              Ok, so now you admit you can see ONE paper on data corruption? You said earlier I did not post any papers at all on this, and I lied and FUDed about this. I told you many times that I did post research papers. I told you to read this post to see more papers on data corruption, but you deny there are papers. Great.
              Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.
              I think you're lying usually. To not FUD you've got to post research papers backing up your claims not so random junk.

              This proves again, that you lie about me. First you said "you lie, there are no papers" and now you confess there is at least ONE paper. So, I did not lie. Actually, it was you who lied about me. You owe me an apology for lying about me. Earlier you confessed you also FUD. So when I say that Kraftman is a FUDer and Liar - I speak true. I can prove that Kraftman lies and he FUDs. And all the time, you accuse me of FUDing and lying? That is hilarious. You have no proof I do that. Never ever have you quoted me lying or FUDing. Cartman, you are too much. Show me a quote where I lie or FUD. Go ahead. I have asked you this, many many times.
              I didn't lie. Read the definition. You're FUDing and I'm nearly sure you're lying also, nearly all the time. You didn't give papers which would backup many things you were claiming, so you're FUDing. While you're FUDing you're lying saying you're not FUDing (or you're just too stupid to realize you're FUDing). In example, you're FUDing when you're saying Linux doesn't scale trollman. Go ahead, show the papers.

              "Linux is really bad as a Large Enterprise server. It is not because of the bad filesystems, but because of limitations in the Linux kernel"

              Show the papers.

              You see Cartman, which difficulties I have with you? I say: "I have posted several research papers on data corruption here":
              Discussion of *BSD operating systems and software, including but not limited to FreeBSD, DragonflyBSD, OpenBSD, and NetBSD. Mac OS X, GNU Hurd, and other alternative operating systems can also be discussed.

              And you say "no, you lie, there are no research papers there".
              Actually, I dont know what to say. I mean, there are research papers there, but you deny that. What can I say? It is like
              -Look the sun is shining!
              -No it isnt
              -Yes it is! look at the sun!
              -No, the sun is not shining.
              ...
              I mean, there are research papers there. But you deny that and say I lie. This is so blatantly obvious so everone who reads that link can indeed see that you do lie about me. This is an obvious lie from you. The other things you claim, can not be so easily controlled. But maybe they are lies, too?
              I mean, I deny there are research papers backing up your claims. Prove I'm lying trollman.

              How can I get you to admit that there are research papers in my post? How can I get you to admit that when Linux kernel devs say the code is buggy and bad quality, they mean it? I mean, ordinary logic does not work on you. Nor does normal reasoning. Nor does posting of links. I mean, I can copy and paste post those research papers here, but that does not help. Why would it? You would just deny them, even when you see them.
              I've failed to find research papers backing up all your claims. Where are they? I don't care too much about personal opinions in this case.

              Kraftman, again. I have proved that you lie and FUD, you have never proved or quoted I do the same as you do. I am not interested in debating with people that have not finished fourth grade or Liars and FUDers. I work with very talented and bright people and I do not see why I must put up with your FUD about me. I can not even make you admit there are research papers which is obviously true. I can not make you admit something that is obviously true. How can I make you admit anything about Linux? That would be impossible! Again. If you have something sane to say, I will listen. But when you repeatedly FUD and lie about me and about Solaris - and never ever provide credible links, I dont have to accept your Trollism. Ok? Come back when you change and have something sane to say, and when you stop all the foul language and bad mouthing. Then I gladly debate with you again.
              You didn't prove this. As far you're FUDing and trolling, so come back with papers backing up your claims. Prove me you're not FUDing, show me the papers. I bet you're working with dumb people, because it seems you're very dumb too.

              (Seriously, I feel sad for you. Life must be have been very hard on you. I can not understand how hard school must have been for you. Your teacher say something, and you dont understand anything. And get bad grades. And people think you are difficult to discuss with, or unpleasant. Kraftman, you dont think like normal people, you will never get a job if you dont change behaviour. Imagine if you start a discussion like this with your boss or a collegue??? Catastrophy. They would consider you mad, you will get a bad reputation. Try to do something about it instead. Try to eat Omega-3 fish oil, that makes a human brain much better. Studies show that people with ADHD and other psychical conditions, gets much better with Omega-3 fish oil. I encourage you to try it. I eat it myself, it is very good for the brain! It is the best advice I can give you.)
              The best advise for you is to get back to your cave. I don't feel sad about you, but I've got a little fun cause I know the trolls name etc.

              Comment


              • @Trollman

                You like quoting Linus a lot, so here you go:



                about sun

                They don't like competition on that
                level. They'd *much* rather take our drivers and _not_ give anythign
                back, or give back the stuff that doesn't matter (like core Solaris:
                who are you kidding - Linux code is _better_).
                So, Linus says Linux code is better FUDer.

                Comment


                • Kebabbert is as usual viciously defending everything Sun/Solaris.
                  Same story in the Swedish forums where he also hangs out, always claiming that he is not posting any FUD and always backing up his claims with links to "research papers", some which are of questionable value (biased) or too old.

                  For Christmas 2008 he was even invited to the the Sun Sweden Christmas party for being such a good henchman, run this link through the translator if you want:
                  Computer Sweden är Sveriges främsta nyhetskälla inom it. Vi publicerar dagligen nyheter och fördjupning för it-beslutsfattare och it-proffs, på vår sajt och i våra nyhetsbrev.


                  Translation of the heading if you don?t bother to read the rest: Standing ovations when Kebabbert showed up at the Sun Christmas party.

                  Although he also defends open source in general (which I also advocate), I find it hard to trust someone that is so completely biased to a vendor that he automaticly assumes that any competing products are inferior without really testing them, or reading up on them, like in the beginning of this thread when he didn?t even know Btrfs was fully checksumming all data & metadata, one of the basic design goals.

                  I also have to comment on the "Btrfs has only one full time developer" issue, for once we don?t know how many part time developers there are, if it was 50 people working 50% I think that would be worth more than 1 full timer ? So even if it is just one full time developer, it doesn?t necessarily mean it is low on resources.
                  Also if you look at recent kernel changelogs since a while back you will see that there are people committing more code than the supposed only full timer Chris Mason. In the latest 2.6.35 kernel there were 13 submitted patches, none of them were authored by Mason.
                  See http://kernelnewbies.org/LinuxChanges

                  I can agree though that it would be really interesting to see a ZFS/Btrfs comparison on some real heavy workloads with a lot of drives, but I can?t really find anything useful on the web.
                  Since Btrfs is from what I know not really even near a v1.0 there will probably be a lot of room for various optimizations still, but I?m pretty confident that it will be a very safe filesystem once it reaches production, probably in a year or two, and if it combines that with good performance ZFS will have a tough competitor.


                  I?ll keep tracking this thread, I guess there is more FUD to come

                  Comment


                  • Originally posted by LasseKongo View Post
                    Kebabbert is as usual viciously defending everything Sun/Solaris.
                    Same story in the Swedish forums where he also hangs out, always claiming that he is not posting any FUD and always backing up his claims with links to "research papers", some which are of questionable value (biased) or too old.

                    For Christmas 2008 he was even invited to the the Sun Sweden Christmas party for being such a good henchman, run this link through the translator if you want:
                    Computer Sweden är Sveriges främsta nyhetskälla inom it. Vi publicerar dagligen nyheter och fördjupning för it-beslutsfattare och it-proffs, på vår sajt och i våra nyhetsbrev.


                    Translation of the heading if you don?t bother to read the rest: Standing ovations when Kebabbert showed up at the Sun Christmas party.
                    Like a dog setting on sun competitors (IBM and Linux especially). It seems sun had a lot of such dogs - Bonwick, some "doctor" etc.

                    Although he also defends open source in general (which I also advocate), I find it hard to trust someone that is so completely biased to a vendor that he automaticly assumes that any competing products are inferior without really testing them, or reading up on them, like in the beginning of this thread when he didn?t even know Btrfs was fully checksumming all data & metadata, one of the basic design goals.
                    I find this hard to realize, because trollman attacks the essence of Open Source and defends anti Open Source company. It's enough to read some comments here or at some mailing lists, osnews to realize the guy isn't emotionally stable. It's like sun crap makes him to feel good.

                    Comment


                    • Posting papers from 2008, 2006... is misleading in computer world. The information is basically not valid anymore.

                      Well, returning to thread main question. About performance, there is a guy on btrfs mailing list that tried btrfs on high-end server with 16 multiple solid state disks. First he do the test with 2.6.32

                      ZFS BtrFS
                      1 SSD 256 MiByte/s 256 MiByte/s
                      2 SSDs 505 MiByte/s 504 MiByte/s
                      3 SSDs 736 MiByte/s 756 MiByte/s
                      4 SSDs 952 MiByte/s 916 MiByte/s
                      5 SSDs 1226 MiByte/s 986 MiByte/s
                      6 SSDs 1450 MiByte/s 978 MiByte/s
                      8 SSDs 1653 MiByte/s 932 MiByte/s
                      16 SSDs 2750 MiByte/s 919 MiByte/s

                      Then he switch to 2.6.35 , which has better optimizations, mainly direct I/O and hardware checksum check.

                      Reference figures:
                      16* single disk (theoretical limit): 4092 MiByte/s
                      fio data layer tests (achievable limit): 3250 MiByte/s
                      ZFS performance: 2505 MiByte/s

                      BtrFS figures:
                      IOzone on 2.6.32: 919 MiByte/s
                      fio btrfs tests on 2.6.35: 1460 MiByte/s
                      IOzone on 2.6.35 with crc32c: 1250 MiByte/s
                      IOzone on 2.6.35 with crc32c_intel: 1629 MiByte/s
                      IOzone on 2.6.35, using -o nodatasum: 1955 MiByte/s

                      The thread:

                      Comment

                      Working...
                      X