Tips on prolonging life on ssd with btrfs?

[Pinochet]

I bought a samsung consumer grade qvo 2tb ssd for vm/lxc storage. I went with btrfs for the filesystem for snapshot speed and bit protection. I've seen people posting that you should only use enterprise ssd/s with zfs/btrfs and others saying that's not entirely true. While I've been using btrfs on my desktop on a similar drive for years and it's still in great shape I've not used it in a virtualized setup. Everything is working great but today I was playing in the UI and noticed it has a wear out of 1% and it's only been in there for about 6/7 weeks running about 3 vm/s and some docker containers. Some of the docker containers have web apps that run a db like postgres and mongo. This is just a small intel nuc hosting some things for the family and a serving as a lab. I want to add a few more vm/s and containers and am concerned about wearing it out within a year or two. I found in the forums it mentioned to turn off the following services if not needed since the write to the disk often. I've also verified the trim service is running and from what I read it's suppose to trim every fs mounted that supports it and btrfs does. Is there a way to verify the last time a mount was trimmed so I can be sure the service is doing it? Additionally, I was curious of users here running btrfs and their experience and if there's anymore I can do to make to help prolong the drive. So far all my vm/s are linux and they are all using .raw disk files. I plan on one windows vm and will turn the page file off. I've also seen it recommend that in the vm/s guest that you run trim there to...is that correct?

pve-ha-lrm
pve-ha-crm

 

[LnxBil]

I've seen people posting that you should only use enterprise ssd/s with zfs/btrfs and others saying that's not entirely true.

Who is saying the latter? It's not that it cannot be used, it will wear very fast and it will not be fast.

Is there a way to verify the last time a mount was trimmed so I can be sure the service is doing it?

Not that I know of. Normally you only see if ZFS has trimmed itself, not if any other application has trimmed. With copy-on-write, things are really different. Imagine you have snapshots and write changes to disk, nothing can be trimmed on the data side of thing, you need both the old and the new block.

So far all my vm/s are linux and they are all using .raw disk files.

You're using raw files on top of btrfs/zfs or do you mean zvol and their btrfs counterpart?

 

[Pinochet]

Who is saying the latter? It's not that it cannot be used, it will wear very fast and it will not be fast.


Not that I know of. Normally you only see if ZFS has trimmed itself, not if any other application has trimmed. With copy-on-write, things are really different. Imagine you have snapshots and write changes to disk, nothing can be trimmed on the data side of thing, you need both the old and the new block.


You're using raw files on top of btrfs/zfs or do you mean zvol and their btrfs counterpart?

Here on this forum ...I've seen people say this. Not that you can't but you shouldn't. It's on me, I never bought a enterprise ssd before but also never used one in virt and only used them on my laptop. I've been using a samsung ssd on my suse laptop for about four years now with btrfs and it's doing fine...but it's also a laptop and not hosting a bunch of vm/s writing to it all the time. I didn't think about write endurance until after the fact, live and learn. On proxmox and esx I've always used traditional rotational drives but upgraded for speed and overlooked endurance. What I mean by raw is I'm using raw.disk/s for the vm/s as opposed to qcow. As it was mentioned to me that would be a cow on cow and really wear out the drive.

 

[breakaway9000]

Wearout will go up fast, QVO is Samsung's most bottom tier drive money can buy. It's really designed for cold storage type situations, ie the kind where a user puts some games on their drive and they only really get read, very rarely get fully overwritten.

Just keep an eye on it and you'll be fine.

The wearout isn't even the biggest problem with these SSDs, its the speed. Most consumer grade SSDs have only a small amount of actual fast flash (50-100GB) and the rest of it is much slower for writes. The idea is the average user is not likely to write more than 50GB in one sitting. When the writing is done, the disk's onboard controller transparently moves this data onto the slower flash (flushes the cache if you will). So if you try running write-heavy workloads what you'll find is once this "cache" space fills up, the disk speed will drop to absolute rubbish and the IOWAIT will go through the roof.

Perhaps next time, see if you can scour eBay and find an Intel or Samsung "Datacenter" grade SSDs that can handle many TBs of write without problem.

 

[spirit]

The main difference between consumer vs datacenter ssd/nvme , is that datacenter grade ssd/nvme have a supercapcitor. (something like a battery).

then main problem with flash devices, is that you when your write a memory cell, you need to write all the cell, even for 1byte.

zfs/brtfs/ceph use synchronous write for their journal, so any write (even buffered in the vm), will be flushed on the journal, then for 1byte a full flash cell will be erased and rewrite.

with the supercapacitor, the sync writes are buffered in a small memory (like a writeback cache on a raid controller), then the memory cell is fully written when buffer is big enough.

that's why you have : - fast sync write (10k-20k write vs 400-1000 iops), and longer endurance. (less memory cell rewrite)