Announcement

Collapse
No announcement yet.

Btrfs & Counter-Strike: Global Offensive

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

  • #11
    As for Fractal Trees. I found out about those and send a mail to phoronix since those things really seem to be scaling very well! The downside of those things is CPU bound. And they will certainly use your CPU. Perhaps even too much and that might be a potential issue.

    As for Fractal Trees being a drop in replacement for B-Trees.. Perhaps, don't know. Yet again, remember very carefullt that TukoDB (that uses Fractal trees) is a drop in replacement for InnoDB! That last part is very important, InnoDB!

    simply "replace" a current dataset build with B-Tree with a Fractal Tree is probably not very likely to happen since they likely store data different.

    Comment


    • #12
      Originally posted by Armurier View Post
      a wide range of configurations to support, each having intrinsic differences...
      I don't understand that argument. Just create a distribution agnostic tarball with the binaries that is tested and runs on Ubuntu. Packagers will do the rest.

      Take for example the Archlinux package for google chrome dev. It earlier used the .deb package, now uses the .rpm package. It works. It doesn't need to be their job.

      Comment


      • #13
        Yes! It's the next source engine-based game that will carry linux support. Then the other. Then the one after that. Then HL 2 Episode 4096. Then HLv20...

        Comment


        • #14
          I think Gabe Newell put that empty "linux32" directory in the distribution just to get a rouse out of Michael and his readers.

          Seriously, they're teasing and mocking us. But would they ever do it for real? Nope.

          Comment


          • #15
            Maybe fractal trees can be made to work with btrfs if the trees are copy on write friendly. Everything in btrfs is copy on write, so that's an important quality in whatever data structure they use.

            Comment


            • #16
              Originally posted by allquixotic View Post
              I think Gabe Newell put that empty "linux32" directory in the distribution just to get a rouse out of Michael and his readers.
              Yeah, because its not like there is a valid reason for the source engine to use a linux32 directory.

              Oh wait...

              Seriously, they're teasing and mocking us. But would they ever do it for real? Nope.
              The only trolling going on from Valve is the Half Life 3 trolling.

              Comment


              • #17
                Originally posted by ChrisXY View Post
                I don't understand that argument. Just create a distribution agnostic tarball with the binaries that is tested and runs on Ubuntu. Packagers will do the rest.

                Take for example the Archlinux package for google chrome dev. It earlier used the .deb package, now uses the .rpm package. It works. It doesn't need to be their job.

                They just don't believe that an O.S. officially ranked at something like 1% of market share could ever bring them a single additionnal penny of operating result.
                They just do see additionnal developping costs, additionnal testing, some code redesigning as they probably have designed the entire game to run for DirectX.

                Eventhough it would take them a minute it still would be too much for them.

                The linux32 directory is 99,9999% chances being some server stuff related.
                Michael has been teasing for years now that some CS-native-linux will ever see day light one of that day, but nothing has been seeing yet.
                With Unreal Tournament 3, the other game that were awaited by all and never came, Icculus did show two screenshots. It's worst finally, as it shows that the game was ready to play but they didn't even wanted to sell it. Only lawyer department can lead to such stupid decisions. I'm 100% sure that UT3 has never been released for some lawyer related stupidity.

                Those are the two arguments to prevent games being ported to linux : 1% official market share and lawyers.

                Comment


                • #18
                  Originally posted by markg85 View Post
                  As for Fractal Trees. I found out about those and send a mail to phoronix since those things really seem to be scaling very well! The downside of those things is CPU bound. And they will certainly use your CPU. Perhaps even too much and that might be a potential issue.

                  As for Fractal Trees being a drop in replacement for B-Trees.. Perhaps, don't know. Yet again, remember very carefullt that TukoDB (that uses Fractal trees) is a drop in replacement for InnoDB! That last part is very important, InnoDB!

                  simply "replace" a current dataset build with B-Tree with a Fractal Tree is probably not very likely to happen since they likely store data different.
                  Table engines are designed to be drop-in, but features will vary, however I don't know how it would be possible for one tree to be a drop-in for another tree. It is simply too low level. By definition it would seem as if they couldn't be drop-in since their format is different.
                  While making a frac tree fs might be interesting, it would need to be written from scratch, unless I am mistaken.

                  Comment


                  • #19
                    Originally posted by Fry-kun View Post
                    If f-trees are a drop-in replacement for b-trees then btrfs shouldn't have too much trouble adapting them...
                    They're a "drop-in replacement" in that they support the same operations. They are a fundamentally different data structure that wouldn't be compatible with the existing on-disc format.

                    So, if you want to use f-trees, you need to create a new filesystem. But you shouldn't. Why?

                    Because F-Trees were created with databases in mind. They're optimized for operations that either don't exist in a regular filesystem, or aren't performance critical. They're trying to avoid fragmentation when inserting huge amounts of data in the middle of a B-Tree - an operation that's common in databases, uncommon in directory nodes and nonexistant in files.
                    Current filesystems already have other methods in place to avoid seek times, which work quite well on the operations common in filesystems.


                    I wonder why noone bothered to read the PDF linked in the news. Neither the reader who suggested it, nor Michael who considered it newsworthy, nor anyone in the forums who's been asking about it...

                    Comment


                    • #20
                      Originally posted by Flyser View Post
                      Linux dedicated server *yawn*
                      Quote.

                      (stupid character limit)
                      ## VGA ##
                      AMD: X1950XTX, HD3870, HD5870
                      Intel: GMA45, HD3000 (Core i5 2500K)

                      Comment

                      Working...
                      X