Submitted 9 months ago by Trincapinones@lemmy.world to selfhosted@lemmy.world
A year ago I set up Ubuntu server with 3 ZFS pools on my server, normally I don’t make copies of very large files but today I was making a copy of a ~30GB directory and I saw in rsync that the transfer doesn’t exceed 3mb/s (cp is also very slow).
What is the best file system that “just works”? I’m thinking of migrating everything to ext4
Ext4 does not have snapshots, COW or similar features. I am very happy with BTRFS. It just “works” out of the box.
I use BTRFS on everything too nowadays. The thing that made me switch everything to BTRFS was filesystem compression.
Yes compression is cool. Zstd level 3 to 6 is very quick too 😋
Yes and BTRFS, unlike Ext4, will not go corrupt on the first power outage of slight hardware failure.
Wut? Ext4 is quite reliable.
I’ve run btrfs for years and never had a issue. They one time my system wouldn’t boot it was due to a bad drive. I just swapped the drive and rebalanced and I was back up and running in less than a half an hour.
Corruption on power only regularly happened to me on xfs a few years ago. That made me swear to never use that fs ever again. Never seen it on my ext4fs systems which are all I have for years in multiple computers.
This will also happen to Ext4. You just wouldn’t know it.
FWIW lvm can give you snapshots and other features. And mdadm can be used for a raid. All very robust tools.
Yes but BTRFS can this out of the box without extra tools. Both ways have their own advantage, but I would still prefer BTRFS
ZFS will perform better on a NAS
3mb/s sounds more like there is something else going on.
Yeah, but I don’t know how to diagnose it…
You could try to redo the copy and monitor the system in htop, for example. Maybe there’s a memory or CPU bottleneck. Maybe one of your drives is failing, maybe you’ve got a directory with tons of very small files, which causes a lot of overhead.
Most filesystems should “just work” these days.
Why are you blaming the filesystem here when you haven’t ruled out other issues yet? If you have a drive failing a new FS won’t help. Check out “smartctl” to see if it reports errors in your drives.
they may be using really slow hard drives or an SSD without DRAM.
or maybe a shitty network switch?
maybe the bandwidth is used up by a torrent box?
there’s a lot of possible causes.
That ive learnt the hard way it dosent 😅 have a Ubuntu server with unifi network in it, thats now full in inodes 😅 the positive thing, im forced to learn a lot in Linux 😂
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| NAS | Network-Attached Storage |
| SSD | Solid State Drive mass storage |
| ZFS | Solaris/Linux filesystem focusing on data integrity |
[Thread #486 for this sub, first seen 5th Feb 2024, 15:05] [FAQ] [Full list] [Contact] [Source code]
How full is your ZFS? ZFS doesn’t handle disk filling and fragmentation well.
Around 70% full with 10% fragmentation
At around 70%, fragmentation issues start becoming apparent with ZFS IIRC. Though they shouldn’t be this apparent.
XFS has “just worked” for me for a very long time now on a variety of servers and desktop systems.
Careful as it is obscure enough that you could blow off your leg.
I don’t see how the default filesystem of the enterprise Linux distro could be considered obscure.
ZFS should have better performance if you set it up correctly.
I host my array of HDD drives with btrfs, works well and is Linux native.
MergerFS + Snapraid is a really nice way to turn ext4 mounts into a single entry point NAS. OpenMediaVault has some plugins for setting this up. Performance maxes out the drives and you can use cheap mismatched drives.
ZFS is by far the best just use TrueNAS, Ubuntu is crap at supporting ZFS, also only set your pool’s VDEV 6-8 wide.
I was thinking about switching to debian (all that I host is in docker so that’s why), but the weird thing is that it was working perfectly 1 month ago
Maybe your HBA is having issues? or a Drive is Failing? have you done a memtest? you may need to do system wide tests, it can even be a PSU failing or a software Bug.
also TrueNAS is built with Docker they use it heavily something like 106 apps, Debian has good ZFS support, but you will end up doing a lot of unneeded work using Debian unless you keep it simple.
Make sure you don’t have SMR drives, if they are spinning drives. CMR drives are the I ly ones that should be used in a NAS, especially with ZFS. vermaden.wordpress.com/2022/…/zfs-on-smr-drives/
From the article it looks like zfs is the perfect file system for smr drives as it would try to cache random writes
Possibly, with tuning. Op would just have to be careful about reslivering. In my experience SMR drives really slow down when the CMR buffer is full.
It’s an SSD, that’s what worries me the most
Where are you copying to / from?
Duplicating a folder on the same NAS on the same filesystem? Or copying over the network?
For example, some devices have a really fast file transfer until a buffer files up and then it crawls.
Rsync might not be the correct tool either if you’re duplicating everything to an empty destination…?
Same NAS, same filesystem on an SSD without redundancy
Still the same, or has it solved itself?
If it’s lots of small files, rather than a few large ones? That’ll be the file allocation table and / or journal…
A few large files? Not sure… something’s getting in the way.
Use zfs sync instead of rsync. If it’s still slow, it’s probably SMR drives.
New Lemmy Post: Best Filesystem for NAS? (https://lemmy.world/post/11585657)
Tagging: #SelfHosted
(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md
Kata1yst@kbin.social 9 months ago
ZFS is a very robust choice for a NAS. Meant 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?
Trincapinones@lemmy.world 9 months ago
I don’t even know what a zpool scrub is lol, do you have some resources to learn more about ZFS?
Kata1yst@kbin.social 9 months ago
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.