all 84 comments

sorted by: hot top controversial new old
[–] 50 points 6 months ago (5 children)

The equivalent would be either zfs or btrfs compression. Transparent to applications, you don’t have to do anything special other than enable it.

  • source
  • hideshow 5 child comments
  • [+] [S] 9 points 6 months ago (5 children)
  • [–] 10 points 6 months ago*

    How small are these devices? I think the other problem is that neither BTRFS nor zfs really are suitable for removable devices, and definitely not for ones smaller than probably 8Gb at the very least.

    Unlike NTFS which is just a file system, both BTRFS and ZFS do volume management too, so it’s not just a single partition thing; they prefer to take over an entire volume and manage everything.

    So while they’re the closest filesystem with NTFS-like transparent compression…..they don’t match exactly.

    I also hazard to guess if the devices you’re using are too small to accept a BTRFS formatted volume, no amount of compression is going to be enough to fit what you need.

    If you just want to play with a bunch of small old devices…..maybe play with LVM and small RAID arrays and configurations instead. You can the build a bigger volume out of a bunch of those disks together and then put a BTRFS or zfs volume on them. Can be fun to experiment and learn with anyway.

  • source
  • parent
  • [–] 7 points 6 months ago*

    How small is your smallest device? BTRFS doesn't have a minimum size, but practically probably 50-100mb is just about doable before even just setting things up get complex. Having said that though, it's copy-on-write and has overhead as a result, so may not function well below 1gb.

    ZFS meanwhile really won't work well below probably 8gb. It's also copy-on-write but with a lot more overhead due to how it works. It really works best on big drives and filesystems.

    If your old storage is in the mb range, then really neither will help you achieve what you want.

    BTRFS and ZFS do offer the same benefits as NTFS with regard to compression and speeding up some slower devices (due to lowering the actual read/writes needed to achieve the same result as the data is compressed into a smaller space and decompressed rapidly by the PC in memory), but NTFS can go be used on much smaller disk sizes due to how it works. BTRFS and ZFS are designed and optimised with other benefits in mind. And NTFS compression isn't well supported in Linux.

  • source
  • parent
  • [–] 6 points 6 months ago (1 child)
  • [+] [S] 2 points 6 months ago (1 child)
  • [–] 7 points 6 months ago*

    You'll need to read the documentation to understand its concepts first. You don't use mkfs but zpool to create a pool then use zfs to create the fs on it. ZFS is usually used with some sort of raid configuration so most doc will show this but you can create a pool with no replication using a single drive.

  • source
  • parent
  • load more comments (-1 replies)
  • load more comments (-1 replies)
    [–] 19 points 6 months ago

    You could a filesystem that supports compression like ZFS or BTRFS.

  • source
  • [–] 12 points 6 months ago (16 children)

    This is at file system level... Checkout btrfs and zfs, I am quite positive both can compress like you want.

    Never used this feature myself, so cannot be more specific.

    Also, there are some read-only compressed filesystems for Linux that you can also use, they offer best compression but data is read only.

  • source
  • hideshow 16 child comments
  • [+] [S] 3 points 6 months ago (16 children)
  • [–] 8 points 6 months ago (14 children)

    How small is that device??? Didn't even knew btrfs has a minimum size.

    After for zfs, you probably have to install some software or kernel patches

  • source
  • parent
  • hideshow 14 child comments
  • [+] [S] 4 points 6 months ago (14 children)
  • [–] 6 points 6 months ago (6 children)

    Huh. My computer allows me to format a 128MB image file with brtfs. It won't do it at 64MB though.

  • source
  • parent
  • hideshow 6 child comments
  • [+] [S] 2 points 6 months ago (5 children)
  • [–] 3 points 6 months ago* (last edited 6 months ago) (4 children)
    truncate -s 128M fs.img  
    parted fs.img  
      mklabel gpt  
      mkpart primary btrfs 1MiB 100%  
      quit  
    sudo losetup --find --partscan --show fs.img  
    sudo mkfs.btrfs /dev/loop0p1  
    

    You should be able to skip the loop device stuff and work on an actual device instead. Seems to me the limit is somewhere between 64M and 128M.

    Edit: But as edinbruh said, maybe try f2fs if it's a flash device, that's probably a bit more lightweight?! And since I don't know what you're doing... If it's embedded stuff and you're alright with read-only, you might want to use squashfs.

  • source
  • parent
  • hideshow 4 child comments
  • [+] [S] 3 points 6 months ago (4 children)
  • [–] 2 points 6 months ago* (3 children)

    Remember to enable compression. Usually the Arch Wiki is a great resource to learn stuff: https://wiki.archlinux.org/title/F2FS

    And don't forget to back up your data if you're messing around with your computer. One typo with the device names is enough to accidentally delete your harddrive.

  • source
  • parent
  • hideshow 3 child comments
  • [+] [S] 1 point 6 months ago (3 children)
  • [–] 1 point 6 months ago (2 children)

    I haven't tried it. But looks to me you need to add "compression" when formatting it. And then later when mounting, you'd add options like compress_algorithm=zstd,compress_extension=*

  • source
  • parent
  • hideshow 2 child comments
  • [+] [S] 2 points 6 months ago* (2 children)
  • [–] 2 points 6 months ago* (last edited 6 months ago) (1 child)

    Did you read the Wiki? You need to either pass the compress_extension option when mounting it. The Arch Wiki lists how to enable compression on all text files. And I gave you the version with a '*', which enables compression for all files. Or you do a chattr -R +c ... on specific files or directories to compress them. Maybe you missed that and that's why it doesn't compress?!

    There's probably also a way to debug it and somehow figure out what it does and how many files/sectors got compressed on the filesystem. Linux usually buries that kind of information somewhere in /sys or /proc, or there's special commands to figure it out. But I'm not really an expert on it.

    And there's also files which just can not be compressed any further because they're already compressed. Most images, for example. Or music or ZIP archives. If you try to compress those, they'll usually stay the same size.

  • source
  • parent
  • hideshow 1 child comment
  • [+] [S] 1 point 6 months ago (1 child)
  • [–] 2 points 6 months ago

    Sounds reasonable. Yeah, good luck. I'm sure you'll figure it out. Unfortunately it's always a bit difficult to diagnose problems over the internet, without typing in the commands and seeing the exact output. But there should be a way to make it work, F2FS is designed for something like this.

  • source
  • parent
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • load more comments (-2 replies)
  • [–] 5 points 6 months ago (4 children)

    If it's a flash memory (sd card, usb stick, ssd, etc), you could try f2fs, it's very light, and it supports compression and is meant specifically for that kind of devices (well, more for ssds).

    But judging your experience from your comments, I suggest you don't delve into niche filesystems until you have more experience with Linux, especially for something like 128MB. I especially suggest you avoid zfs for now.

  • source
  • parent
  • hideshow 4 child comments
  • [+] [S] 2 points 6 months ago (3 children)
  • [–] 3 points 6 months ago* (2 children)

    So, first of all, there is no gui for this, that I'm aware of, so you will have to do it from terminal. Second, on f2fs, compression works that you don't enable compression for a folder, instead you mount the drive with compression enabled, and new files will be compressed automatically.

    So what you need is to set up your disk to be mounted with compression. There are many paths you can follow here. If you want your drive to be (almost) permanently connected, the easiest way is to use "/etc/fstab". If you want to use it as a regular SD card, mounting and ejecting it from your file explorer etcetera, then you should go here and learn how to have udisks2 mount your device with compression, which should be what your desktop environment uses to mount drives. I suggest you set that up for your specific device, and not for all f2fs devices. Good luck.

    You can look up other useful f2fs options on the arch wiki. I suggest you add all those options that reduces writes to your disk and improve durability (like lazytime).

    You should use zstd as compression algorithm, and because this is a slow and small drive, you can crank up the level of compression.

    If you manage to pull this off, the next time you install a (bigger and faster) drive on your pc, you can try to look into zfs.

  • source
  • parent
  • hideshow 2 child comments
  • [+] [S] 1 point 6 months ago (2 children)
  • [–] 4 points 6 months ago* (last edited 6 months ago) (1 child)

    That is not a good method for testing. Maybe the filesystem still requires new files to be smaller than free space. Or maybe the file could be not really compressible, for example, you won't be able to compress random data. You also won't compress already compressed data, like videos.

    You could write a real text file of some kB and then check the compression ratio with something like "compsize".

    The mount command mounts the disk with the options you give to it but only once. Now, because you don't want to manually run mount everytime you use your disk, you must set it up so it is always mounted with the options you want. Udisks2 is one of the tools for that.

    P.s. apparently compsize is btrfs only. You can use "du" with and without --apparent-size and check the differenze

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • [–] 1 point 6 months ago

    Damn, where did you even find such a small drive? The last time I used such a small device was the USB stick I brought to highschool in 2009. Even the free giveaway USB drives I have are at least 2GB. You probably have more RAM than storage?

  • source
  • parent
  • load more comments (-1 replies)
  • load more comments (-1 replies)
    [–] 5 points 6 months ago (2 children)

    There's an interesting project called DwarFS. I have it on my todolist to check it out but as I understand it you basically create a compressed read-only archive that is mountable and readable just like any other disk - https://github.com/mhx/dwarfs . Maybe this is something for your use case?

  • source
  • hideshow 2 child comments
  • [+] [S] 1 point 6 months ago (2 children)
  • [–] 1 point 6 months ago

    Unfortunately I haven't tested it so I cannot fully advise on that but I have seen some "repacks" on the high seas where a whole wine prefix with a game already installed was compressed to a single dwar which you can mount and play with configs and saves in your ~.

  • source
  • parent
  • load more comments (-1 replies)
    [–] 5 points 6 months ago (2 children)
  • [+] [S] 2 points 6 months ago (2 children)
  • [–] 2 points 6 months ago (1 child)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
    [–] 5 points 6 months ago* (4 children)

    Not sure that’s relevant, but I’m playing around with Linux on some obsolete Windows tablets with cheap eMMC disks (one of which is broken, so I replaced it with a no name microSD card, plus USB drive), and I format my disks to f2fs, which theoretically should help with both keeping the disks for longer, and accessing the data faster.

  • source
  • hideshow 4 child comments
  • [+] [S] 4 points 6 months ago (4 children)
  • [–] 5 points 6 months ago* (3 children)

    Make sure you're actually filling the volume, and also keep in mind reporting may be different (with or without filesystem index metadata, etc)

    Also, you can simply use regular file systems and compressed files, and then use a RAM drive (assuming you have enough RAM free) and access the files that way instead

  • source
  • parent
  • hideshow 3 child comments
  • [+] [S] 1 point 6 months ago (3 children)
  • [–] 1 point 6 months ago (2 children)

    RAM drive is when you hold the entire file system in RAM, it's used for stuff like Linux Live CD boot with no writable storage but you can use it for anything.

  • source
  • parent
  • hideshow 2 child comments
  • [+] [S] 1 point 6 months ago (2 children)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
    [–] 5 points 6 months ago

    Just download more RAM.

  • source
  • [–] 4 points 6 months ago (1 child)

    Sounds like you're looking for something like archivemount.

  • source
  • hideshow 1 child comment
  • [+] [S] 3 points 6 months ago (1 child)
  • [–] 1 point 6 months ago

    Could that be due to a failing SD card or flash memory? The uncompressed data might be getting corrupted too, it just wouldn't return you an error depending on the file type (text documents for example would never error, they would just end up with garbled text).

    Based on your other comments, if you're using an old 128mb SD card, this seems kind of likely. I've had many SD cards and USB sticks go bad after files have been copied on and off of them too many times.

  • source
  • parent
  • load more comments (-1 replies)
    [–] 4 points 6 months ago

    What are you saving on that drive? Many data file formats already have compression of their own and don't benefit much from file system compression. So if this is for media files, for example, it's likely to add CPU overhead without a big benefit in transfer speed.

    ZFS is not installed by default with most Linux distributions due to its license. It's something you install after the os. Btrfs should work, but I see some discussion online of 128 or 256MB minimum volume size.

  • source
  • [–] 3 points 6 months ago

    The Compress attribute has been in even ext3 since day 1. I've never tried it, though.

  • source
  • [–] 2 points 6 months ago (1 child)

    sudo nano /etc/fstab

    Then replace "defaults" with "compress=zstd" on your desired partitions.

    IMO stick with btrfs. Also, the storage space between file systems is exactly the same, given the same hardware.

  • source
  • hideshow 1 child comment
  • [+] [S] 1 point 6 months ago (1 child)
  • [–] 1 point 6 months ago

    The fstab file is used to define how disk partitions or remote file systems are mounted into your computer. Removable drives such as USB drives or SD cards are not shown there, because if they were, your system would complain at boot that it can't find the requested USB drive.

    About F2FS having double the storage space of btrfs. In all honesty, it doesn't make sense to me. Do you mean it shows you potentially being able to store 80 megabytes if you can get compression working or does it just show 80 megabytes instead of 40, after formatting the file system?

  • source
  • parent
  • load more comments (-1 replies)
    [–] 4 points 6 months ago

    What do you mean, btrfs "takes too much space"? That's not a sentence that belongs to file system stuff in any way.
    The disk is the space. You make it usable with a fs, for which you can partition portions of it.

    And also, i've had bad experiences with f2fs long-term stability.

  • source
  • [–] 2 points 6 months ago

    F2FS seems to do what you want, it'll reserve the original size of your file but compress what's actually written. Performance numbers might be massively inflated if your writes don't saturate the cache in RAM.

    I've used BTRFS on SD cards before and it's mostly fine, but it will struggle massively if over 90% full, or if you have a < 1 GB volume and are, say, frequently updating a handful of files that together take up more than half its capacity. Mostly due to the CoW mechanism, it needs some headroom to make a copy of whatever files are being modified.

  • source
  • [–] 1 point 6 months ago (1 child)

    It's not clear here if you mean block compression, file compression, or stream compression.

  • source
  • hideshow 1 child comment
  • [+] [S] 1 point 6 months ago (1 child)
  • [–] 1 point 6 months ago

    BTRFS and ZFS both use block compression, ZFS by default. It's meant to increase both storage efficiency and access speed and has nearly zero impact on performance. The files aren't compressed from the filesystem point of view, which would satisfy your requirement not to need any other tools.

    I'm confused about your statement that you don't want to save space with compression, but you indicated that you want to "make the most of your storage". Are you looking for long-term archiving?

  • source
  • parent
  • load more comments (-1 replies)
    [–] 1 point 6 months ago

    My “I don’t need to save space, I want it for a different purpose” tee shirt is raising a lot of questions answered by my “I don’t need to save space, I want it for a different purpose” tee shirt.

  • source
  • [–] 1 point 6 months ago (3 children)

    Never really had the need. My linux install already takes up way less space than my old windows one so I have much more space.

  • source
  • hideshow 3 child comments
  • [+] [S] 1 point 6 months ago (3 children)
  • [–] 0 points 6 months ago (1 child)

    running games on old storage devices that hold less than 32 GB and have terrible read and write speeds.

    I'm confused. How about copying that to newer storage devices?

    Also typically game assets are VERY well compressed so I would suggest doing a comparison with/without compression before a full on migration. Compression tools help but aren't magical. If your assets are e.g. .jpg or .mp4 or .mp3 or a combination of that (as typically game assets are, including 3D models with their textures) then you can test yourself to .zip them (or bzip2 or whatever you prefer) and you will seem some gains but they'll be nearly negligible, e.g. < 10% reduction.

  • source
  • parent
  • hideshow 1 child comment
  • [+] [S] 1 point 6 months ago* (last edited 6 months ago) (1 child)
  • [–] 1 point 6 months ago

    You don't have to share your personal situation and I'm sorry to read that you are struggling. My point isn't to argue that you must do like everyone else or that consumerism is good, rather than in the typical case (not a lot of time, hardware getting cheaper of the year, game assets being compressed already) switching to newer hardware is a much much more convenient solution. That's why I warned about it.

  • source
  • parent
  • load more comments (-1 replies)
  • load more comments (-1 replies)
    [–] -1 points 6 months ago*

    I just want to say that if you are going to either resort to belittling me

    That's like a red rag to a bull

    you haven't fully read the post before commenting

    You could've just tldr'd it. You used 4 paras to ask 'how do I compress files/my fs'

    I'm not going to respond to your comment

    Well that was a big fat lie, wasn't it.

  • source
  • [+] -8 points 6 months ago (6 children)
  • [+] [S] 5 points 6 months ago (6 children)
  • [+] -5 points 6 months ago* (last edited 6 months ago) (5 children)
  • [–] 1 point 6 months ago (4 children)

    the device I'm testing first is too small for btrfs

  • source
  • parent
  • hideshow 4 child comments
  • [+] 0 points 6 months ago (3 children)
  • [–] 1 point 6 months ago (2 children)

    that you write things i'm trying to understand the relevance of, like "This information wasn’t provided in the post." and "the first comment points to btrfs". The Reddit link you gave also points towards btrfs as well as very undetailed mentions of zfs. ze says "i've tried btrfs and it doesn't work so i'm looking into zfs", and you reply "use btrfs use btrfs or look into zfs", a message whose helpfulness I struggle to understand.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (-1 replies)