40MB/s is very very low even for a HDD. I would eventually debug why it's that low.
Yes it's possible. FS like zfs btrfs etc. support that.
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
40MB/s is very very low even for a HDD. I would eventually debug why it's that low.
Yes it's possible. FS like zfs btrfs etc. support that.
It's probably a 5400rpm drive, and/or SMR. Both are going to make it slower.
5.4k + smr would explain it at write but not at read.
agreed, I think there is something else going on here. test the write speed with another application, I doubt the drive actually maxes out at 40MB/s unless it's severely fragmented or failing.
incidentally what OP wants is how most people set up Unraid servers. SSD cache takes incoming files for write speed, then at a later time the OS moves the files to the spinning disk array.
Its the cheapest drive I could find (refurbished seagate from amazon), I thought thats the reason for being slow, but wasnt aware its that low. Im also getting 25-40 MB/s (200-320 Mbps) when copying files from this drive over network. Streaming works great so its not too slow at all. Is there better way of debugging this? What speeds can I expect from good drive or best drive?
Ill research more about BTRFS and ZFS, thx
can you copy files to it from another local disk?
Yeah, but need to figure out how to see transfer speed using ssh. Sorry noob here :)
If you use scp (cp over ssh) you should see the transfer speed.
I have managed to copy with rsync and getting 180 MB/s. I guess my initial assumption was wrong, HDD is obviously not bottleneck here, it can get close to ISP speed. Thank you for pointing this out, Ill do more testing these days. Im kinda shocked because I never knew HDD can be that fast. Gonna reread all the comments as well
The limitation of HDDs was never sequential Read/Write when it comes to day to day use on a PC.
The huge difference to an SSD is when data is written or read not sequentially, often referred to random I/O.
Unraid has this with their cache pools. ZFS can also be configured to have a cache drive for writes.
You can also DIY with something like mergerfs and separate file systems.
Ive heard about all of these before, gonna do more research. Thank you
Njxbxbxb
Are you also talking about incomplete directory in qbit? Doesnt make it faster afaik, but I might be wrong. I havent tried anything yet, wanted to check is it something usual or not worth at all. Got zero experience with using SSD as catch drive, it just made sense to me
Xbbxnxjxd
Yeah it will be faster, but its extra step before the files get available on HDD.
Even if my HDD is super fast and healthy it would still be a bottleneck for 2Gbps fiber? Ill deffo play with HDD more to find max speeds, wasnt paying attention before because it felt normal to me
Znnznndnz
Yeah feels like that lol. Thx anyway, have a nice day dude
what OP wants is to download the file to a SSD, be able to use it on the SSD for a time, and then have the file moved to spinning disk later when they don't need to wait for it.
this is just adding an extra step to the process before the file can be available to use. you're just saving the copying to the HDD until the very end of the torrent.
Yeah, I use the incomplete folder location as a cache drive for my downloads as well. works quite nicely. It also keeps the incomplete ISOs out of jellyfin until they're actually ready to watch, so, bonus.
If it's not going faster for you there's probably something else that's broke.
It will download faster to SSD, but then I have to wait the files to be moved to HDD before getting them imported in media server. Im not after big numbers in qbit, I just want to start watching faster if possible. Sorry Im probably not explaining well and Im not sure if Im asking for something that even make sense
qbittorrent moves the completed files to the assigned literally as soon as it is done.
but if the disk is actually bottlenecking at 40MB/s it will still take time to copy from the SSD. That plus the initial download to SSD will just end up being more time than downloading to the spinning disk at 40MB/s in the first place.
That's not how hard drives work, and doesn't take into account that OP might want to download more than one thing at a time.
Hard drives are fastest when they are moving large single files. SSDs are way better than hard drives at lots of small random reads/writes.Setting qbittorrent up so that all the random writes inherent to downloading a torrent go to a small ssd, and then moving that file over to the big hard drive with a single long writer operation is how you make both devices perform to their best.
I doubt the disk will bottleneck at 40mb/s when doing sequential write. Torrent downloads are usually heavy random writes, which is the worst you can do to a HDD.
You can and Qbittorrent has this functionality built in. You set your in progress download folder to be the SSD then set the move when completed to your HDD.
As for the size, that would depend on how much you are downloading.
But that would first download to SSD, then move to HDD and then become available (arr import) on jellyfin server, making it slower than not using SSD. Am I missing something?
The biggest thing is you have changed a random write to a linear write, something HDDs are significantly better at. The torrent is downloading little pieces from all over the place, requiring the HDD to move it's head all over the place to write them. But when simply copying off the ssd, it keeps the head in roughly one place and just writes lineally, utilizing it's maximum write speed.
I would say try it out, see if it helps.
Also, if the HDD is having to do other tasks at the same time, that will slow it down as the head can only ever be in one place.
I might try that, thx
qBittorrent has exactly the option you’re looking for, I believe it’s called “incomplete download path” in the settings, letting you store incomplete downloads at a temporary path and moving them to their regular location when the download finishes. Aside from the download speed improvement, this will also lead to less fragmentation on your HDD (which might be part of the reason why it is so slow when downloading directly to it). Pre-allocating space could have the same effect, but I would recommend only using one of these two solutions at once (pre-allocating space on your SSD would only waste space)
But that would first download to SSD, then move to HDD and then become available (arr import) on jellyfin server, making it slower than not using SSD. Am I missing something?
Bdnndndd
Well yes, but I was hoping files can be available (imported to media server) before they are moved to HDD. Import is not possible from incomplete directory if I understood that correctly (*arr stack)
I do this with mergerfs.
I then periodically use their prewritten scripts to move things off the cache and to the backing drives.
I should say it’s not really caching but effectively works to take care of this issue. Bonus since all that storage isn’t just used for cache but also long term storage. For me, that’s a better value proposition.
Thanks, Ill check mergefs
<3 mergerfs and <3 my setup, but just a warning: make sure you read the documentation and ensure you've got all the proper options set in your fstab entry for the mergerfs mount.
There's a lot of stuff in there that can interact weirdly with various pieces of software and lead to the most insane debug sessions because, well, why would a drive mount break other software (in my case it was qbittorrent in docker when an upgrade required me to change the mount options to not include direct_io).
bcachefs will fill this role someday.
For now there is ZFS which as a cache drive option. Keep in mind it will absolutely destroy the cache drive by wearing out the flash
You also could look into ZFS special disks. However, if you are going that way already you might as well get a bunch of disks.
Depends on the file system, I know for a fact that ZFS supports ssd caches (in the form of l2arc and slog) and I believe that lvm does something similar (although I've never used it).
As for the size, it really depends how big the downloads are if you're not downloading the biggest 4k movies in existence then you should be fine with something reasonably small like a 250 or 500gb ssd (although I'd always recommend higher because of durability and speed)
Thx. I use ext4 right now. I might consider reformating, but so many new words to reasearch before deciding that. I heard about ZFS, but not sure is that right for me since I only have 16 GB of RAM.
Downloads are 100-200 GB max, but less than 40 GB most of the time. I have 512 GB in use and 2TB SSD not in use, can swap them if needed
I used lvm with SSD cache few years, but time to time I have problems with loads after reboot. If forgot about reboots all work great with LVM raid + LVM cache. Cache can be configured without raid. And you can add or remove cache in any time. Docs: https://man.archlinux.org/man/lvmcache.7
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters | More Letters |
---|---|
LVM | (Linux) Logical Volume Manager for filesystem mapping |
RAID | Redundant Array of Independent Disks for mass storage |
SSD | Solid State Drive mass storage |
ZFS | Solaris/Linux filesystem focusing on data integrity |
[Thread #938 for this sub, first seen 27th Aug 2024, 13:05] [FAQ] [Full list] [Contact] [Source code]