HisEvilness88

To be technically superior: rsync

I know but apparently smr drive need some time "to take a breath" when a lot of data is written to them. I did notice higher write speeds (+/- 18MB/s) just after such a pause. It helps a little. New server, new config, new disks. Data is moving from old to new so the old one can retire

I have done some reading into smr drives and i had an idea. I have sheduled mover every two hours (even hours) to start moving. I made another script stopping the mover every odd hour. Hoping this will give the drives time to sort stuff out which it would do in expected down time which should bump up overall writing speeds. Might need some timing tweeks but this might be a good starting point.

That's the plan but copying a lot of data at the moment because a replacement so I'll be copying for a while then 😛

It says smr in the description, so basically i'm screwed. Now i know why i got the drives for free 😛 Are there solutions to speed these drives up?

I have an Array with 10 disks, 8 identical 2.5" SATA-drives for data and 2 (almost) identical 3.5" SAS-drives for parity. All 2TB My parity was built at speeds ranging from 8MB/s to 65MB/s. Now i'm copying large files from a cache disk (ssd) to my array using mover but i'm getting max write speed of 2MB/s which is pretty slow compared to the 65MB/s i was getting at parity build. I don't know where to look to figure out what is causing my writes to be slow. Any methodology i can follow. Outside of the array, each disks works fine with max speeds up to 140MB/s (tested with table dock hooked via usb3 to my desktop pc) I know the write speed in an unraid array is slower because of the read-write checks happening but as explained i was getting 65MB/s at parity build. After reboot, speeds are the same (turning it off and on again didn't help ) All dockers and VM's turned off, speed are the same (appdata and system are on seperate cache pool so should have non to little impact) All suggestions are welcome