• 0 Posts
  • 52 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2023

help-circle





  • Never ask a man his pay, a woman her weight, or a data horder the contents of their stash.

    Jk. Mostly.

    I have a similar-ish set up to @Davel23 , I have a couple of cool use cases.

    • I seed the last 5 arch and opensuse (a few different flavors) ISOs at all times

    • I run an ArchiveBot for archive.org

    • I scan nontrivial mail (the paper kind) and store it in docspell for later OCR searches, tax purposes etc.

    • I help keep Sci-Hub healthy

    • I host several services for de-googling, including Nextcloud, Blocky, Immich, and Searxng

    • I run Navidrome, that has mostly (and hopefully will soon completely) replace Spotify for my family.

    • I run Plex (hoping to move to Jellyfin sometime, but there’s inertial resistance to that) that has completely replaced Disney streaming, Netflix streaming, etc for me and my extended family.

    • I host backups for my family and close friends with an S3 and WebDAV backup target

    I run 4x14TB, 2x8TB, 2x4TB, all from serverpartsdeals, in a ZFS RAID10 with two 1TB cache dives, so half of the spinning rust usable at ~35TB, and right now I’m at 62% utilization. I usually expand at about 85%









  • Yeah, you should be scrubbing weekly or monthly, depending on how often you are using the data. Scrub basically touches each file and checks the checksums and fixes any errors it finds proactively. Basically preventative maintenance.
    https://manpages.ubuntu.com/manpages/jammy/man8/zpool-scrub.8.html

    Set that up in a cron job and check zpool status periodically.

    No dedup is good. LZ4 compression is good. RAM to disk ratio is generous.

    Check your disk’s sector size and vdev ashift. On modern multi-TB HDDs you generally have a block size of 4k and want ashift=12. This being set improperly can lead to massive write amplification which will hurt throughput.
    https://www.high-availability.com/docs/ZFS-Tuning-Guide/

    How about snapshots? Do you have a bunch of old ones? I highly recommend setting up a snapshot manager to prune snapshots to just a working set (monthly keep 1-2, weekly keep 4, daily keep 6 etc) https://github.com/jimsalterjrs/sanoid

    And to parrot another insightful comment, I also recommend checking the disk health with SMART tests. In ZFS as a drive begins to fail the pool will get much slower as it constantly repairs the errors.


  • ZFS is a very robust choice for a NAS. Many people, myself included, as well as hundreds of businesses across the globe, have used ZFS at scale for over a decade.

    Attack the problem. Check your system logs, htop, zpool status.

    When was the last time you ran a zpool scrub? Is there a scrub, or other zfs operation in progress? How many snapshots do you have? How much RAM vs disk space? Are you using ZFS deduplication? Compression?





  • Development is happening in the dev’s branches. Branches are generally kept local until submitted for a PR. You can easily see this in the origin branches and open PRs.

    Honestly I’m not sure if you’re trolling, don’t understand git development, or if you really think that a project needs to iterate main multiple times per month to be your definition of “healthy open source”, but I’m tired of shooting down such lazy attacks and won’t be responding further.

    Have a nice day.