Announcement

Collapse
No announcement yet.

F2FS File-System Gets Even Better With Linux 3.18

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

  • #11
    Originally posted by stiiixy View Post
    If I may chime in with a question; when configuring a drive for a BTRFS compression type, when, where and how do you actually set that option? I know the fstab option, but I was under the impression you need to set the drive 'somehow' before loading data on to it (kind of hard with most distro's loading thier install right after creating partitions so you would have to do 'fancy' partitioningg prior), or anything after the data compression was enabled wouldn't get the new option. My information is probably outdated and I've been holding out on BTRFS for to long now, so go easy =D
    Alternatively (to the above) you can just keep applying updates and eventually it will get compressed after you set compress=lzo. This is because Btrfs doesn't check the old data's mount options before writing its new data. So if you have /etc/fstab on the filesystem, then apply compress=lzo and reboot (so it takes effect), the next time /etc/fstab gets updated it will be rewritten as compressed. This applies to all other files on the filesystem too, the next time they get updated they'll be compressed.

    Alternatively to THAT, if you want to KNOW that everything is being compressed...

    Code:
    sudo btrfs filesystem balance / (or /home or whatever else you have as a btrfs FS)
    is what i THINK the command is. A balance operation has Btrfs rewrite all data on the filesystem and re-allocate it. Its typically used after you add / take away a drive from a RAID setup or something similar, but it works equally well for forcing btrfs to compress (or decompress if you were to remove compress=lzo) all data on the filesystem. This command takes awhile so i'd say let it go overnight.
    Last edited by Ericg; 08 October 2014, 11:00 PM.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #12
      Originally posted by zanny View Post
      Whenever you mount it just do mount -o compress=lzo. fstab options are just mount -o options. If your installer is automounting the drive, remount it before installing with the lzo compress option like mount -o remount,compress=lzo.
      Yeah right, thanks for that. So you do have to pop in to a terminal and sort it there. Never really bothered to ask or investigate that aspect before. Seems a small inconvenience. Or can you specify the mount options prior somewhere in the GUI installer? Distro dependant option? I'm about to nerf my main rig's Mintstall in favour of Arch and seriously considering some buttery goodness on my SSD (Samsung 830).

      I could search it obviously, but saves a lot more time asking from people's who knows sometimes =D So thanks anyone!
      Hi

      Comment


      • #13
        Originally posted by Ericg View Post
        Alternatively (to the above) you can just keep applying updates and eventually it will get compressed after you set compress=lzo. This is because Btrfs doesn't check the old data's mount options before writing its new data. So if you have /etc/fstab on the filesystem, then apply compress=lzo and reboot (so it takes effect), the next time /etc/fstab gets updated it will be rewritten as compressed. This applies to all other files on the filesystem too, the next time they get updated they'll be compressed.

        Alternatively to THAT, if you want to KNOW that everything is being compressed...

        Code:
        sudo btrfs filesystem balance / (or /home or whatever else you have as a btrfs FS)
        is what i THINK the command is. A balance operation has Btrfs rewrite all data on the filesystem and re-allocate it. Its typically used after you add / take away a drive from a RAID setup or something similar, but it works equally well for forcing btrfs to compress (or decompress if you were to remove compress=lzo) all data on the filesystem. This command takes awhile so i'd say let it go overnight.
        Oops, didn't read to the end of the post. My email link just took me to the first guy who replied. Anyway, I was actually initially thinking I would just image off the BTRFS partition, remount, then copy back. But I think the install-interrupt way mentioned above might be a little more clean and quicker. Interesting to note that the file being updated gets compressed. Didn't think of that. And the 'balance' command. Another thing to look in to. Probably not something I'd ideally want to do on my SSD however.
        Hi

        Comment


        • #14
          Originally posted by stiiixy View Post
          Oops, didn't read to the end of the post. My email link just took me to the first guy who replied. Anyway, I was actually initially thinking I would just image off the BTRFS partition, remount, then copy back. But I think the install-interrupt way mentioned above might be a little more clean and quicker. Interesting to note that the file being updated gets compressed. Didn't think of that. And the 'balance' command. Another thing to look in to. Probably not something I'd ideally want to do on my SSD however.
          If its a relatively new SSD... you'll be fine. The general rule of thumb for newer SSD's is "TEN gigabytes of data EVERY DAY for TEN years." Your SSD controller will fail before you wear out the flash-- assuming you got a decent SSD. One balance when you install shouldnt be a problem for your SSD's life.
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #15
            Originally posted by Ericg View Post
            If its a relatively new SSD... you'll be fine. The general rule of thumb for newer SSD's is "TEN gigabytes of data EVERY DAY for TEN years."
            That’s quite an improvement compared to my 4 year old 64GB OCZ ONYX (Indilinx Barefoot controller) that only has 20% remaining life even though I’m writing no more than around 100 MB/day on it!
            (The SMART data says I have written 1.1 GB/day though… I suppose that takes into account write amplification.)

            If I am to believe this 20% value, writing 10 GB of data per day on my OCZ would have killed it after 18 days.

            I’m a bit concerned about your "assuming you got a decent SSD". What does it mean concretely?

            Edit: removed extraneous * caused by phoronix not understanding unicode characters…
            Last edited by stqn; 09 October 2014, 11:09 AM.

            Comment


            • #16
              Originally posted by stqn View Post
              That?s quite an improvement compared to my 4 year old 64GB OCZ ONYX (Indilinx Barefoot controller) that only has 20% remaining life even though I?m writing no more than around 100 MB/day on it!
              (The SMART data says I have written 1.1 GB/day though? I suppose that takes into account write amplification.)

              If I am to believe this 20% value, writing 10 GB of data per day on my OCZ would have killed it after 18 days.
              Quick google fu to get a reference, this is a couple examples but similar can be found across hardware sites.


              An SSD drive is a worthwhile investment , but like any storage device, it can fail. In fact, failing isn't that uncommon . As with your spinning dri

              http://www.anandtech.com/show/7173/s...odels-tested/3 (the one is buried in the article but they actually say 100Gb a day.)

              Originally posted by stqn View Post
              I?m a bit concerned about your "assuming you got a decent SSD". What does it mean concretely?
              "by a decent SSD' pretty much means "From a respectable manufacturer." Same as with hard drives, you buy Seagate's and Western Digital's... not Toshiba's or one of the lesser known manufacturers. For SSD's the GoTo's tend to be Intel and Samsung for the best quality flash. Personally, since I was on a tight budget, I recently picked up a SanDisk for my desktop. We'll see how long it lasts.

              But yes, Stqn, SSD's were in a time of "leaps and bounds" of improvement over the last couple years. I don't know if OCZ is a reputable company as far as SSD's go, or if they were at the time. As always with SSD's.. make sure TRIM is enabled unless you have some VERY specific reason not to enable it.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #17
                I've had a Crucial 256 GB SSD in my ThinkPad T520 for over almost three years now; sees daily use about 12 hours per day. No problems at all.

                Originally posted by Ericg View Post
                As always with SSD's.. make sure TRIM is enabled unless you have some VERY specific reason not to enable it.
                The consensus seems to be not to do this in fstab -- that is, don't use the discard option. It can significantly slow down file deletions. Instead, use a cron job to run fstrim on a weekly basis or so.


                Comment


                • #18
                  Originally posted by steveriley View Post
                  I've had a Crucial 256 GB SSD in my ThinkPad T520 for over almost three years now; sees daily use about 12 hours per day. No problems at all.


                  The consensus seems to be not to do this in fstab -- that is, don't use the discard option. It can significantly slow down file deletions. Instead, use a cron job to run fstrim on a weekly basis or so.


                  http://blog.neutrino.es/2013/howto-p...m-and-dmcrypt/
                  Depends on the drive. SATA 3.1 added queue'd TRIM which fixes the hole in the specification that made TRIM cause bad performance while it ran. SATA 3.1 was published 3yrs ago so hopefully it will start showing up in drives soon.. my personal SSD is marketted as only supporting Sata 3.0, but maybe a firmware update will allow 3.1, dont know yet.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #19
                    Originally posted by Drago View Post
                    Chromium web browser used to write small patches of data on disk, even if it is not touched. This bothers me.
                    Then store Chromium's data on a ram drive, and sync it at shutdown time.
                    That will minimize this.

                    I use profile-sync-daemon that does that for me (although I use the ramdrive for other reasons)

                    Comment


                    • #20
                      Originally posted by Ericg View Post
                      Depends on the drive. SATA 3.1 added queue'd TRIM which fixes the hole in the specification that made TRIM cause bad performance while it ran. SATA 3.1 was published 3yrs ago so hopefully it will start showing up in drives soon.. my personal SSD is marketted as only supporting Sata 3.0, but maybe a firmware update will allow 3.1, dont know yet.
                      True. But do you think we'll ever see any drives supporting it? I typed "sata 3.1" into NewEgg's search bar and no drives showed up...

                      Comment

                      Working...
                      X