Hacker News Reader

> whether or not the filesystem attempts deduplication

Unless I'm just parroting truisms here, dedupe is almost never a good idea and compression is a much more common case-by-case.

> So personally I'd encourage messing around (on something non-prod, of course). Measure measure measure! Does it actually make any difference.

100%. So much depends on the particular workload and resources.

> And making backups, even for ZFS backed filesystems. Sacrilege, I know.

Logical backups, specifically. We have seen more than once corruption and data-loss in replicated encrypted snapshots due to bugs in ZFS.

Deduplication requires an absolutely enormous amount of memory, unless you have a dataset that has a huge amount of duplication for some reason (maybe a company or school where a lot of people have their own network storage and put the same large files in?) it is usually never the right choice to enable dedup.

It is cheaper to buy more disk than the memory to enable dedup (somebody could run the numbers). ZFS ARC also likes lots of memory and you get good performance gains with more memory allocated to it.

In other words, turn on LZ4 compression everywhere and don’t think about it otherwise.

Deduplication in ZFS can be pushed onto dedicated flash storage now instead of requiring gobs of RAM.

How to do this?

Great channel for side attacks btw.

Doesn't even need SSD's to open a side-channel: https://lore.kernel.org/linux-btrfs/CAKDzk=-HZardsLFH5c9HYre...

Without having physical access to my hardware, where every disk is FDE anyway?

Physical access not required. Dedupe side attack required timing measurement.

Oh got some hate there.. pissed off the zfs kids with a dose of reality.

Dedupe can be used to infer secret data. .. more news at 11

This is my understanding as well. These days we default to zstd, though.

Oh good, I have it off. I was pondering that feature years ago when I set it up. Couldn't remember where I landed.

Data loss bugs in ZFS?? Wow.

My personal approach to filesystem evaluation is pretty much "How long has it been since I've seen someone talk about a data loss bug". This is my first time hearing one for ZFS. BTRFS seems to have at least one post a year. Ext4 has almost none, but maybe that's because people trust it and blame hardware when unsure what the issue is.

Comparing zfs/btrfs with ext4 is not entirely fair. They're in different domains when it comes to scope and features. To some extent, silent corruption in ext4 is expected but in zfs it's a bug.

Also, compression. CPUs are more than capable of handling it on the fly, and the reduced dataset size helps IO.

This [0] is a brief post on MySQL, but most of it applies equally to Postgres.

[0]: https://www.percona.com/blog/mysql-zfs-performance-update/

I'd be curious if the addition of zstd compression has any effect on the results. Could be a fun follow-up follow-up :-)

For Postgres just follow the original doc:

https://openzfs.github.io/openzfs-docs/Performance%20and%20T...

compression=lz4 recordsize=32K

In postgres -> full_page_writes=off

But also experiment with recordsizes of 8k and 16k. The larger the recordsize, the more potential compression you get, which may be offset by additional delay caused by read/modify/write of the larger record (i.e. reading/writing 32k instead of 8k or 16k).

True, with platter storage i tend more to 32k with nvme more toward 16k. But yes testing is a good thing, but some settings should be just untouched if one is not absolutely sure it's a good thing, aka logbias=throughput.

> disabling the writing of 'last accessed' timestamps

atime is the most useless filesystem feature I’ve heard of. But on most Unix-like systems it’s enabled by default and the main thing it does is turn reads into writes, degrading performance. All the while ctime isn’t a standard Unix filesystem feature. And ctime to me always seemed infinitely more useful (and cheaper!) than atime.

</rant>

relatime has been the Linux default since 2009. It makes that be one write per 24 hours.

while it is unfortunate it requires a write, it is useful in some cases. for example, finding old objects in a cache, or today i used it to find out what firmware my kernel is loading by checking atime of /lib/firmware.

So it's useful as a debugging feature that you might want to briefly turn on once every decade.

Finding old objects in a cache is an issue specific to caches and should be implemented there.

For the latter you could enable it, reboot and get the same information right away, then disable it?

i did not see a clear list of all firmware files read by the kernel in dmesg, so the find/atime trick worked well.

> changing the page size to be the same size as Postgresql uses (8kb)

Mind, you shouldn't really change the record size without knowing your use-case. Make a PostgreSQL file system, set it's recordsize to 8k. That's a good idea.

Not so much a good idea doing that to all your filesystems. Stick to the defaults without a good justification to deviate.