Announcement

Collapse
No announcement yet.

Hot Relocation HDD To SSD Support For Btrfs

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

  • #11
    Originally posted by uid313 View Post
    Just map ~/.steam/ or whatever to /media/hdd/Steam/ with symlink (symbolic link) using the 'ln -s' command.
    Why not have the filesystem do it automatically for you?

    Comment


    • #12
      Originally posted by GreatEmerald View Post
      Why not have the filesystem do it automatically for you?
      Meaning...what, exactly? o.O Whats more 'filesystem-y' than a symbolic link?
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #13
        Originally posted by GreatEmerald View Post
        Why not have the filesystem do it automatically for you?
        Probably because it has overhead, and it has to guess it, and do its magical thing in strange unpredictable ways.

        Better just do it myself.

        Comment


        • #14
          Originally posted by Ericg View Post
          Meaning...what, exactly? o.O Whats more 'filesystem-y' than a symbolic link?
          "Automatically".

          Originally posted by uid313 View Post
          Probably because it has overhead, and it has to guess it, and do its magical thing in strange unpredictable ways.

          Better just do it myself.
          Yea, well, that's what people said when code compilers were invented.

          Comment


          • #15
            Originally posted by uid313 View Post
            Just map ~/.steam/ or whatever to /media/hdd/Steam/ with symlink (symbolic link) using the 'ln -s' command.
            You don't understand... I want the games assets I'm using most to be on the ssd to reduce loading times. I want the ssd to be filed with them while graciously putting what doesn't fit on the hdd, I want these files to be swapped when I start playing a new game and stop playing another for some time. Good luck doing that with symlinks...

            But steam is only one example. I want that for all my programs and games, and also my raws and big jpegs. Should I ask the kernel the list of files listed by access temperature, and move them around manually each week? Maybe I could automate it then, with a script? oh wait, that would be exactly what is done here, except it's properly done by the filesystem.

            Comment


            • #16
              Originally posted by erendorn View Post
              You don't understand... I want the games assets I'm using most to be on the ssd to reduce loading times. I want the ssd to be filed with them while graciously putting what doesn't fit on the hdd, I want these files to be swapped when I start playing a new game and stop playing another for some time. Good luck doing that with symlinks...

              But steam is only one example. I want that for all my programs and games, and also my raws and big jpegs. Should I ask the kernel the list of files listed by access temperature, and move them around manually each week? Maybe I could automate it then, with a script? oh wait, that would be exactly what is done here, except it's properly done by the filesystem.
              Actually, a script could do a better job than what is being done here. Although it may eventually improve.

              File temperature is very dependent on what applications are running. Ideally it would note the loading of, say, a video editing app and immediately begin loading your video assets from the last session to the SSD. When you load your video game it should begin caching the map and texture files that you will be using.

              Otherwise because you had to restart your video encode several times to get just the right options, those video files are going to be stuck in cache for a long time before the game files get a chance.

              Comment


              • #17
                Aren't the folks at Btrfs getting a bit distracted? I mean, Btrfs doesn't even perform well on typical hardware and classic workloads performance-wise, hell it's not even stable right now... and yet people put their efforts into HDD-to-SSD hot relocation?!

                Feature creep in an early development phase has been the death of many software projects...

                Comment


                • #18
                  Originally posted by ultimA View Post
                  Aren't the folks at Btrfs getting a bit distracted? I mean, Btrfs doesn't even perform well on typical hardware and classic workloads performance-wise, hell it's not even stable right now... and yet people put their efforts into HDD-to-SSD hot relocation?!

                  Feature creep in an early development phase has been the death of many software projects...
                  What are you talking about ultima? Btrfs never had the goal, nor the idea to beat Ext4 on pure performance. It was the filesystem to handle everything else-- the ZFS of the linux world since ZFS can never ever be mainlined. It performs perfectly well in real world usage, theres no perceivable difference between btrfs and ext4 (I type this from a laptop I JUST switched from ext4 to btrfs, no difference at all).

                  As far as it being stable.... See my post on the first page where another user asked if it was stable.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #19
                    Okay, I admit that a "good" performance is relative to the intended use and limited by the many features it has to support, so I'll drop that point.

                    Originally posted by Ericg View Post
                    As far as it being stable.... See my post on the first page where another user asked if it was stable.
                    However, as far as stability goes, I have read multiple reports on the internet about having lost data with Btrfs within the past year. Reports that I saw none of for some other filesystems. I read your post you mentioned, even you had data loss with Btrfs once! Just because you had no data corruption in the past few/who-knows-how-many months does not mean that Btrfs is currently in a state where it provides similar data protection to more established systems. A filesystem must be able to preserve data over crashes, across power-outages and over many years, and nobody has been able to demonstrate that with Btrfs, unfortunately quite the opposite. The situation might be better with newer kernel as you said, but a filesystem is a component that has to earn the users' trust, and Btrfs, even if it is promising, has not yet done so. Especially if the've only ironed out the more common bugs in recent kernels as you said, I assure you there are still more than plenty lurking around waiting to be triggered in less common cases. But that is fine: A filesystem, especially one like btrfs, is highly complex and like every similar software it needs time to mature. But please nobody tell me that Btrfs is stable and can be used on production systems yet, unless you have years of experience and half a million users to prove it.

                    Comment


                    • #20
                      Originally posted by ultimA View Post
                      However, as far as stability goes, I have read multiple reports on the internet about having lost data with Btrfs within the past year. Reports that I saw none of for some other filesystems.
                      saw at least one:


                      But yes, Btrfs is too young and not sufficiently deployed to be thoroughly tested in any case, and yes, as it is under heavy development, there will be bugs and corruptions for the next few years.
                      But it's hard to concentrate on bugs that haven't been reported or encountered yet...
                      Btrfs is in a state were there are no known issues, so it's quite acceptable to develop new features already.

                      Comment

                      Working...
                      X