I know the article is just using the noise thing as an excuse to deep dive into zfs and proxmox, which is cool, but if what you really care about is reducing noise I thought I'd leave some practical advice here:
1. Most hard drive noise is caused by mechanical vibrations being transmitted to the chassis the drive is mounted on.
2. Consequently the most effective way to reduce noise is to reduce the mechanical coupling in the drive mounting mechanism. Having the drives in a noise-isolating case is helpful too, but only as a secondary improvement. Optimizing the drive mounting should really be the first priority.
3. If space isn't a concern the optimal thing is to have a large case (like an ATX or larger) with a large number of HDD bays. The mounting should use soft rubber or silicon grommets. Some mounting systems can work with just the grommets, but systems that use screws are ok too as long as the screw couples to the grommet not the chassis. In a good case like this any number of hard drives can be made essentially inaudible.
4. If space is a concern, a special purpose "NAS like" case (example: the Jonsbo N line of cases) can approach the size of consumer NAS boxes. The lack of space makes optimal accoustics difficult, but it will still be a 10x improvement over typical consumers NASes.
5. Lastly what you shouldn't ever do is get one of those consumers NAS boxes. They are made with no concern for noise at all, and manufacturing cheapness constraints tend to make them literally pessimal at it. I had a QNAP I got rid of that couldn't have been more effective at amplifying drive noise if it had been designed for that on purpose.
To add to this, I mounted an HDD to a case using motherboard standoffs in a place that was obviously intended for SSDs. Not only was it very loud, the resonance between the disk and the case also broke the disk after six months.
Yeah, the article title seemed kind of weird to me. I have a ZFS NAS, it's just a bunch of drives in an ATX case with (what I'd considered to nowadays be) the standard rubber grommets.
I mean, you can hear it, but it's mostly just the fans and drives spinning, it's not loud at all.
The recommendations seem reasonable but for noise? If it's noisy probably something is wrong I think.
I totally understand the article title, I have a ZFS NAS that makes the same kind of noise as described there. Roughly every five seconds the drives make sound that is different from the background hum of a running computer. In a calm environment this is very distracting. I even had a guest sleeping in an adjacent room complain about it once.
Is there an online calculator to help you find the optimal combination of # of drives, raid level, and block size?
For example, I'm interested in setting up a new RAID-Z2 pool of disks and would like to minimize noise and number of writes. Should I use 4 drives or 6? Also, what would be the optimal block size(es) in this scenario?
I don't know if this exists or not, but I'd like to try something like a fuse filesystem which can transparently copy a file to a fast scratch SSD when it is first accessed.
I have a somewhat large zfs array and it makes consistent noise as I stream videos from it. The streaming is basically a steady trickle compared to what the array is capable of. I'd rather incur all the noise up front, as fast as possible, then continue the stream from a silent SSD.
It may not be 100% what you're looking for and will probably not make your drives silent while streaming but putting L2ARC on that SSD and tweaking prefetch might get you a good way there.
Another much simpler filesystem-agnostic alternative would be to copy it over to the SSD with a script and commence streaming from there. You'll have to wait for the entire file to copy for the stream to start, though. I think some streaming servers may actually support this natively if you mount /var and/or /var/tmp on the faster drive and configure it to utilize it as a "cache".
Just to test whether your OS setup etc is already up to par, try reading the whole file, eg by calculating the hash with something like `md5` (yes md5 is not secure I know.). This should put the file mostly in the os cache. But with video files being able to hit more than 50GiB in size these days, you need quite a lot of RAM to keep it all in cache.
Maybe you can setting the SSD as a scratch disk for swap? I’m not sure how/if you can tweak what it is used for.
As a sibling says, ZFS should support this pretty transparently.
If you've got enough ram, you might be able to tune prefetching to prefetch the whole file? Although, I'm not sure how tunable that actually is.
Yes, I think nowadays you do this with
blockdev --setra <num_sectors> /dev/sdX
But I feel like there was a sysctl for this too in the past. I used it back in the day to make the HDD in my laptop spin down immediately after a new song started playing in rhythmbox by setting it to 16MB.
mpv has --cache-size (or something) that you can set at a few GB. If you run out of ram it should swap to your ssd.
Edit: demuxer-max-bytes=2147483647
Not aware of anything that directly matches your description, however all major operating systems do cache filesystem object in RAM. So if you pre-read the file, then it should be read back from cache when you come to stream it.
Additionally, ZFS supports using SSDs to supplement the cache.
Depending on the file-size I wonder if it'd be better to just prefetch the entire file into RAM.
good idea, but that's not his problem. he needs a media player that will sprint through to the end of the file when he first opens it. They don't do that cuz they figure they might be streaming from the net so why tax that part of the sytem.
i mean you can do that with a simple wrapper
have a ssd ie mounted in /tmp/movies
and create a script in .bin/ (or whatever)
#!/bin/sh
tmp_m="/tmp/movies/$(mktemp -d)"
cp "$@" $tmp_m
mpv $tmp_m
rm $tmp_m
please note i have not tried the script but it probably works
I expected a way to find out what the heck the system is sending to those disks.
Like per process and what the the Kernel/ZFS is adding.
It can be done with CONFIG_DM_LOG_WRITES and another set of drives, but AFAIK, it needs to be set up before (or more exactly under) zfs.