If it's cache-only, all share data, assuming it can fit, will remain permanently on the cache. If it's cache-yes, share data is written to cache and will remain there until mover's run at which point it's transferred to the (parity-protected) array. If new files are then written they'll be written to the cache and go through the same process. Finder just does not get the data while the unraid appliance goes nuts just by visiting the folder with photos probably finder generating the thumbnailsĬache will function differently depending on the share's setting. And yes i have disabled the previews genration in finder and the. Anyway using SSD cache or no SSD cache does not make a difference on a Timemachine backup performance.Īnyway using an unraid SMB share for accessing photos is a real PITA as the photos being 1.5 MB in size are basically not browsable as it takes minutes just to list the directory where the photos are and previewing them with finder takes many seconds too. Will keep you posted but there are tons of people complaining about SMB performance on Macs but most of them are treatable on the server side.Īnyway could someone please explain me the meaning of SSD cache drive existance if the parity drive is HDD?Is the parity being written when i write to the cache or not? Coz when i run timemachine i can hear the parity drive going nuts so i wonder if it is the reading due to the time machine or some uncontrolled writing. I am curious to see if i upgrade the hardware for some SATA3 mainboard and better CPU if i get better results with unraid or if i boot xpenology if i get the same results on the same hardware. It has performance trouble even when copying between internal drives.Īlso the stats showing throughputs on the network side seem to show big BS while it is copying over files. Encryption does not seem to have much effect here. I was running windows server on it for years but never had such issues with SMB shares like i have with Unraid. the server is a HP Microserver Turion N40L. Note: I don't think it's possible to convert existing HFS+ images to APFS so you have to start fresh. And I may be imagining it but my backups seem smaller. The new APFS formatting for Time Machine images in Big Sur (previous versions used HFS+) also seems to help. If you're backing up to an array share that uses BTRFS cache (I run a dedicated cache-only pool in beta35) setting Copy-on-write to No seems to help. That's good because it bypasses the cache/disk abstraction layer and every bit helps. ![]() I think? the spaceinvader tutorial sets an unassigned device as the time machine share. Have you done that? It may require a reboot to take effect: One of the recommended SMB tweaks is disabling signing. ![]() My initial ~150GB backup over wireless took about half a day. Still you're getting relatively terrible performance. I'm using Big Sur and it's still worse than the old AFP method. SMB random read/write performance in MacOS stinks.
0 Comments
Leave a Reply. |