RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login

    Feature request BtrFS install images.

    Scheduled Pinned Locked Moved Ideas and Development
    feature requestimageinstallbtrfsfile system
    3 Posts 2 Posters 895 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • TeathiefT
      Teathief
      last edited by Teathief

      I hope this is the right place for this, not a support request just a feature idea.
      It would make my year to see these from Pi system vendors, especially with how hard it is to torture a existing image into one.
      Running through seeing the hit or miss support for different compression formats across the spectrum of emulators supported. The idea hit me that I wish I could just use the same filesystem I use on my desktop and enable full drive compression, using one of the mounting options BtrFS suports like.

      [code]
      compress=(lzo or zlib) or compress-force=(lzo or zlib)
      [/code]

      The side effect of nailing a ton of other parts (all) of the system that wouldn't normally see compression would make it a lot more effective then all the work to support different compression formats in the emulators themselves.
      It seems to work well enough too playing around with another system that uses it.
      I wasn't able to tell a speed difference and on many systems its a speed up but with higher CPU utilization during file transfers.

      There are other benefits but the drive compression is the main one I'd like to use.

      1 Reply Last reply Reply Quote 0
      • Z
        zerojay
        last edited by

        BtrFS is a horrifically bad choice on an SD card. BtrFS with compression is unstable in general even on hard drives, BtrFS is extremely prone to fragmentation and shouldn't be used anywhere that you might have at higher than 90% disk space used. Defragging will heavily hit your number of writes to an SD card extremely quickly.

        TeathiefT 1 Reply Last reply Reply Quote 0
        • TeathiefT
          Teathief @zerojay
          last edited by Teathief

          @zerojay I've been using compression for years now admittedly on arch though which means I may have
          had a newer version of btrfs then is in debian currently this whole time.

          Quite a few power outages during that time its been as a whole 100x more stable then my experience with XFS ever was and that gets recommended for extremely large data deployments (don't know why XFS eats data on any system I've used it on).

          My raspberry has the same disk size as my main desktop SSD, 128GB is a little cramped by modern standards but I don't think I'll be riding 90% the whole life of my Pi.

          Might be harder on microsd's but frankly isn't ext4 itself known to be extremely rough on microsd storage as well?
          Its complained about when it comes to android phones but they just don't expect the phone to be around long enough for it to be a problem.

          Fragmentation might be a valid argument but I've never noticed a issue with it, still seems as snappy as when I first put the filesystem on my system.

          Just did a fragmentation scan on my drive besides a couple files with 19 and 54 extents 99% of them are sitting at 1 extent.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post

          Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

          Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.