TL;DR: Is Btrfs on an (NVMe) SSD a good idea or should I just re-install with Ext4?
I’ve recently bought myself a fancy new NVMe SSD and put Manjaro on it. Without really thinking twice, I used Btrfs since that’s been my go-to FS (there is no real reason for this, it just kind of happened).
About a day after installing the OS, I had the idea that a CoW FS like Btrfs may not be too great for my drive’s lifetime since it puts a lot of write-cycles on the drive. After doing a bit of research I’m not really any wiser: some users are saying it’s fine to run it, especially since (apparently) Fedora uses it as its default FS, while others say it’s generally still a bad idea and I would be better off with Ext4.
I’ve also had similar thoughts regarding swap. I’ve decided to be safe and just leave swap out entirely but I’m not sure if I am just being paranoid here.
My first question is this: will Btrfs noticeable decrease my drive’s lifetime and should I just re-install with Ext4? (Right now I am still at a point where I can reinstall without spending too much time on it). Second question: should I even bother with swap or will it dramatically decrease my SSD’s life? (I have only really found conflicting infos here as well)
If you don’t have enough memory, you need swap. And you don’t want to run your swap on a HDD, so there is no option other than getting sufficient memory in the first place. And you can’t hibernate without swap.
depends entirely on how much you write. And if your SSD dies, it won’t be because of BTRFS. Ext4 drive will probably die and slow down earlier because you can’t use in-line compression.
How so? What does it write over and above some other FS like ext4?
More metadata?
If anything a CoW will write LESS data.
Consider a copy operation:
A normal FS will copy that data 100% of the time.
A CoW FS will merely copy some metadata and will only create a copy of the data if one of the references is written to - and then only the part that is changed. This will certainly happen less than 100% of the time.
It seems to me, if anything, CoW is BETTER for your SSD than other FSes. Also btrfs has transparent compression (which will further reduce data written to the drive) and special features related to SSDs (including, but not limited to async TRIM support)
P.S. Swap - it’s application specific. Personally I’d put like 8 to 16 gigs of swap on top of anything lower than 32G of physical RAM. Depending on your applications you could still put some swap on a system with more RAM as a sort of “about to run out of memory” warning when you notice the computer slowing down (obviously this last bit doesn’t apply to an unattended server).
I should really stop posting while tired, my bad. What I was concerned about was not CoW itself but rather the snapshots for which btrfs uses CoW. But after doing some more reading and based on what you said, those snapshots probably won’t much of a difference either (unless I’m missing something here of course).
As for swap, I really haven’t been doing anything memory intensive lately, to the point where I never used my swap partition on the HDD (and if I do change that, I may just buy more RAM anyway since DDR4 is pretty cheap right now). Also, I don’rt hibernate.
Now if I do decide to retroactively enable swap, is there anything I need to consider regarding this SSD? E.g. could there be advantages to making a swap file in this specific case (advantages that would outweight the overhead)?
I’d say from my experience BTRFS has more write amplification for small random writes than ext4. Not to an extent that you would care in a desktop. But in return you get these cool features such as snapshots but also data integrity verification (which ext4 cannot do).
BTRFS has been used in the enterprise space by a decade now. Unless you enable some of its less good features it’s a fine FS.
This is because ext4 doesn’t use checksums. If you disable checksums in BTRFS, it’s about the same… Not writing checksums saves writes, surprise surprise.
And you can’t use compression on ext4, making you write more data in general. This contributes way more to overall writes than some metadata and checksums.
It’s mostly about the enabled features BTRFS has as a default as a CoW filesystem. There is no such thing as free lunch. Features always have a price. If you mount BTRFS with nodatacow you disable all that, including compression. Profit? probably not.
BTRFS and Swap are fundamentally incompatible, or rather, COW is incompatible with swap. You have to do some extra work to use a swap file on BTRFS, and looking at what that looks like, I feel like it’s probably better to just have a swap partition on the drive instead.
IMO, mirroring your system memory capacity for swap is a safer bet than using quarter or half, but ymmv. It depends on the workload. I’ve had, for instance, Krita take my total memory used from ~50GB to over 100GB just to change the color space on a bunch of layers. (from RGB to grayscale, at that) Similar things happen when changing layer size or the like.
Swap will, of course, hurt your SSD life, whenever it’s used, just like writing anything to the SSD will hurt it’s life. I can’t think of a reason it would be much worse than writing that data normally, though. Do you worry about your SSD life when downloading a steam game or copying a DVD? Swap isn’t really that different.
This is how you do it and basically everyone else too.
You can use swap in ZFS by creating a zvol for your swap, but this is very janky , slow and probably is just asking for trouble. But we use it for VMs like that and its fine. In the end we’re talking CoW with snapshots and shit after all. Probably fine if you need some pool with high fragmentation for benchmarks, but that’s really the only use case.
Normal people put a swap partition on their boot drive and call it a day. A Swap file on the filesystem went out of fashion for good reasons, even before CoW was a thing.
if you use snapshots on your /, then create a subvol without snapshots and add that to your fstab
btrfs filesystem mkswapfile --size 2G swapfile
add to fstab and swapon
Sure. But on long running servers you can often see how these pages on your swap just aren’t touched for hours. And then you have freed up memory that can be used for inode caching. Windows users don’t mind paging either now do they.
I think a database application (like your browser hehehe) may do more TBW.
Btw a neat thing to do in case you are using a swap partition is to add the fstab option discard=once. This will send a TRIM/DISCARD command to the SSD everytime the Swap is mounted. If you use LUKS then dm-crypt may ignore discards by default tho.