Solved ZFS read spead a few dozen Times slower than write

Dear forum,

I'm using a ZFS device with USB 3.
Along other settings, the dataset is compressed with lz4, copies is 2, atime is on, sync is set to standard and relatime is off.

Just the day before yesterday I copied a 27GB .tar.gz file to the device.
Now trying to copy it back, the speed is horrible. A few kilobytes and up to 4 or 5 MB/s...

Could this be the result of bad tuning?
Should in I change something in the settings above?

If there is any more data you need, please tell me.

Thanks in advance!

Hakaishi
 
Has the USB3 device got a name? Post zpool get all
I do not know the exact name, but it is an ADATA device with 2TB.

I've attached the output of "zpool get all bigbackup" and the output of "zfs get all bigbackup/data".
 

Attachments

  • dataset.txt
    4.9 KB · Views: 132
  • pool.txt
    4.2 KB · Views: 132
Looks good.


If you were copying from a slower device to a fast device you see a fast processing.

Now when copying back from a fast device to a slower device, the writing there will be much slower.
Exactly, but it's the opposite, no?
I copied from SSD to USB3 HDD device (write). In less than an hour.
Now I am copying from USB3 to SSD. (Slow device to fast device)... It will take over 4 hours and much more. Can't calculate the time as the speed is changing. It's already running for two hours...

Oh. I need to mention that the SSD is ext4. Only the USB3 HDD is ZFS.
 
I do not have a relatime ZFS dataset property... Do you use the new sysutils/openzfs-kmod? Since this is brand new stuff, you should be prepared that it's not well tuned yet.

Keeping track of access times unnecessarily reduces throughput. Thus I have set zfs set atime=off zroot & zfs inherit -r atime zroot, and only zfs set atime=on zroot/var/mail
 
I do not have a relatime ZFS dataset property... Do you use the new sysutils/openzfs-kmod? Since this is brand new stuff, you should be prepared that it's not well tuned yet.

Keeping track of access times unnecessarily reduces throughput. Thus I have set zfs set atime=off zroot & zfs inherit -r atime zroot, and only zfs set atime=on zroot/var/mail
Thank you for your reply!
Well, I didn't update the pool recently or anything. But yes, I use the default openzfs packages from Ubuntu 20.04.

Thanks for your proposal for the pool/dataset settings. I knew that it might not be ideal, but I wasn't too sure about it.
 
Very nice that you finally come out with this. How is this related to FreeBSD?
Well... Sorry about that.
Originally I was using FreeBSD and I also created the FS from there.
Also, I thought that if it's about ZFS settings I might get qualified answers over here rather than elsewhere. Again, sorry about that.
 
Even if it is not related to FreeBSD, ZFS quite similar on Linux as it is on FreeBSD:

I'm using a ZFS device with USB 3.
A USB-3 disk is probably just about as fast as a regular disk these days; the interface is good enough.

My only worry is: Some external USB-3 disks are special models intended for use as backup devices only. They use shingled or SMR drives (which makes perfect sense for backup, you get more capacity, good sequential write speed, good read speed, but bad random write speed); but since in this test you are reading, that should make no difference.

Along other settings, the dataset is compressed with lz4, copies is 2, atime is on, sync is set to standard and relatime is off.
Most of those setting should do terrible things to write speed. Compressing takes a lots of CPU time when writing, less when reading. Copies=2 means that every thing you write is written twice, which as a side effect turns sequential writes into random writes (since ZFS has to hop back and forth between two write locations). Then, turning atime on means that reads update the atime, which means they also cause writes.

Just the day before yesterday I copied a 27GB .tar.gz file to the device.
If you are mostly storing already compressed data (like this ...gz file) on the file system, then turning on lz4 compression in ZFS makes no sense, and just makes writing slow. But slow writes are not your current problem, slow reads are.

Now trying to copy it back, the speed is horrible. A few kilobytes and up to 4 or 5 MB/s...
On a normal machine, with reasonable CPU power, 4-5 MB/s for reading with compression is way too slow. If this is a slow CPU machine (Raspberry Pi, old Atom) it might make sense.

Could this be the result of bad tuning?
Should in I change something in the settings above?
Why do you need atime? Most people have no use for it.
Does compressing in ZFS make sense for you? It gets you more capacity, if the data is compressible (which pre-compressed data is not), but at a serious cost in performance.
Why are you using copies=2? Sure it gives you some protection against disk errors, but not against whole disk failure, and the performance impact when writing is terrible. In general, multiple copies on the same disk is a bad tradeoff, compared to having multiple disks in a RAID configuration, but if you have only one disk, that's not a useful suggestion.
 
Even if it is not related to FreeBSD, ZFS quite similar on Linux as it is on FreeBSD
Thank you for your understanding!
Well, most of the data is uncompressed.
I see that atime is not a good setting here.
I'll deactivate it later on.
My concern is that I'm reading a single file. atime shouldn't have that much impact in that case, or am I wrong?

I have an 8 core processor with enough strength, I presume...
8GB of memory while only about 500 MB is in use by the system...

Write speed is quite high, so this really puzzles me :(
 
I guess it's something with the current packages, since I'm not using freebsd...
I'll try to ask around on the Ubuntu forum and maybe directly on GitHub.

Everyone, thank you very much for your thoughts and suggestions!
I really appreciate it.

I'll mark this thread as solved for now. If I solve the problem or can get hold in any info, I'll report it here.

Best regards,
Hakaishi
 
Oh! Wait! What about the recordsize?
I've got very many photos, so maybe 512 would be better than 128.
What do you think? - I guess that the same goes for writing speed... Maybe not much a difference in read?
 
I really hope you mean a record size of 512KiB (instead of the default 128KiB), not a record size of 512 bytes. Because 512 bytes would be insanely small.

If your photos are large, typically, much larger than 512K, then a large record size might make sense, to save some space, but in practice I think it will make little difference in write speed. Actually, with copies=2, it might make a larger difference, you might want to test this; I don't know how making multiple copies interacts with write scheduling.
 
I really hope you mean a record size of 512KiB (instead of the default 128KiB), not a record size of 512 bytes. Because 512 bytes would be insanely small.

If your photos are large, typically, much larger than 512K, then a large record size might make sense, to save some space, but in practice I think it will make little difference in write speed. Actually, with copies=2, it might make a larger difference, you might want to test this; I don't know how making multiple copies interacts with write scheduling.
Yes, I indeed mean kilo bytes.
My problem isn't the writing speed, but the reading speed. Usually the reads should be much faster than the writes...
 
Update:
Copying the same 27 GB file today gives me around 60 to 70MB/s.
I would have guessed that this is a memory thing, but the reads keep this level up to the end. Used memory was up to 4 GB and CPU load up to 40%.
The file finished copying while writing this text...
What the heck was the problem yesterday? Copying that file took me 6 or more hours yesterday...

Best regards,
Hakaishi
 
  • You can safely leave LZ4 compression=on on the root dataset & inherit that setting, since it aborts very quickly on non-compressible data.
  • This night, you were hacked by a friendly white hat cracker, who kindly tuned your system ;)
 
  • You can safely leave LZ4 compression=on on the root dataset & inherit that setting, since it aborts very quickly on non-compressible data.
  • This night, you were hacked by a friendly white hat cracker, who kindly tuned your system ;)
ROFL!!!
Well, maybe there was something wrong with the cable?
Since this is a single device, I want copy=2, but that would mean that I will have half the disk space... That's why compression is on. :)
I'm not sure if it will help much though, since most files are photos, compressed files or even old backups (images) created by dd... 😅
 
On some other forums, I read about problems reading the file for the first time. Should be about ARC... I do not use a separate device or anything, so it shouldn't be concerned to caches, I suppose.

A very big thank you to you all for your concern, tips and thoughts and support!
 
One last update:
Just now I suffered from slow read speed again. I tried reconnecting the HDD a few times, but always with the same result.
I can't be 100% sure, but I think that as soon as the used memory reached about 3.5GB, the speed dropped... (a few hundred KB/s up to 4MB/s)
I tried switching off atime and did another export and import. Afterwards everything was constantly copied with around 70MB/s. It could be a coincidence, but worth noting.

Best regards,
Hakaishi.
 
Back
Top