Announcement

Collapse
No announcement yet.

Hot Relocation HDD To SSD Support For Btrfs

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

  • #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.

        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:
            http://phoronix.com/forums/showthrea...Bug-Gets-Fixed

            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


            • #21
              Originally posted by ultimA View Post
              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.


              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.
              You're right, Btrfs has HAD issues. HOWEVER all known corruption bugs, all failed recovery bugs and the likes have been sorted out. Btrfs biggest "issue" right now is the lack of an fsck.btrfs which is only an issue for automatically running fsck on boot, for manually running fsck there is btrfsck. Unfortunately there wont be an fsck.btrfs until the fsck developers do the API changes that the btrfs devs have requested so that all of btrfs fsck-related features can be used.

              And yes, I have had ONE failure of btrfs and that was due to a power outage mid-update. It is very possible (though unfortunately impossible to prove or disprove) that if there was an fsck.btrfs in the initrd that it would have detected a dirty-shutdown and automatically run fsck and recovered the filesystem no problem. I could have also tried running btfsck from the live environment, but as I said...it was a brand new install, I didnt really care enough to bother trying to fix it, i just did a reinstall.

              I agree that btrfs needs time to mature and grow before being fully marked as "Work environment stable." That being said, btrfs (on recent kernels) I do believe is "Home environment stable." So whether or not btrfs is "stable" really comes down to the environment at hand and your general guidelines for what is "stable."

              Comment

              Working...
              X