Speed dropping off at 34% of the file during scatter

[couzin2000]

trafficstars

I have a 8TB Seagate drive. The drive was recently reconstructed from parity. I ran long form SMART tests, 0 issues or errors. I am moving all my files from this drive (almost 8TB of 5-to-20GB files) to 3 other 4TB Seagate drives (also 0 errors, unused up to now).

I ran a dry run before, all was finished without a hitch, but for some reason the actual move has so far been going for 23h41m and I am left with 179h47m remaining - which is completely unacceptable.

During copying, the files reach around 33-34% copied, and the speed immediately drops from 82MB/s to 0. After 3-4 minutes, the speed gets back up to 67-72MB/s. This wastes all the time and doesn't feel like it should be doing this.

I dare not stop the move procedure, I am afraid of losing files.

Please advise as to what I should be doing. This doesn't feel like a user error.

[jbrodriguez]

I ran a dry run before, all was finished without a hitch, but for some reason the actual move has so far been going for 23h41m and I am left with 179h47m remaining - which is completely unacceptable.

wow ! that's a lot of data you're transferring, almost 8Tb 😮, it doesn't look like 179h is unreasonable (just doing some mental math)

During copying, the files reach around 33-34% copied, and the speed immediately drops from 82MB/s to 0. After 3-4 minutes, the speed gets back up to 67-72MB/s. This wastes all the time and doesn't feel like it should be doing this.

the speed in the ui is the average of the last 60 samples as reported by rsync, which has control at this point in time, it's the one doing the file transfer, it would seem to indicate that the specific file/folder where the speed drop happens may have some issues

you can stop the operation, the status after that will be

• all commands marked with a green circle have been completed: the file/folders were copied to the destination and deleted from the source (if you chose to do a MOVE operation)
• the command that was stopped will partially exist in the destination disk, the original source files will still be available on the source
• the rest of the source files/folders have not been touched

you can check this in the history tab

hopefully this gives you some insight into how to move forward.

something i would try is run the "problematic" rsync command directly from the command line, see how it behaves

[couzin2000]

Thank you very kindly for the prompt response. I find 179h to be completely crazy; if I were to read files from within Windows and transfer them over Gigabit ethernet to my array directly it would take less than 30 hrs - i've done that. 179 hours is more than a week!!!

What I'm trying to accomplish is to move the files off that one drive, REformat the drive from XFS to ZFS, then re-write the files. I'm inclined to think that if I were to completely remove the drive from the array, format it to ZFS, then add it back to the array so that unraid reconstructs the contents from parity. This operation may take less time!

I'll appreciate any advice you can give me on this. For the moment I'll leave unbalanced to run and i'll see.

Thanks again

Sent from my iPhone

On Wed, Apr 10, 2024 at 11:28 Juan B. Rodriguez @.***> wrote:

I ran a dry run before, all was finished without a hitch, but for some reason the actual move has so far been going for 23h41m and I am left with 179h47m remaining - which is completely unacceptable.

wow ! that's a lot of data you're transferring, almost 8Tb 😮, it doesn't look like 179h is unreasonable (just doing some mental math)

During copying, the files reach around 33-34% copied, and the speed immediately drops from 82MB/s to 0. After 3-4 minutes, the speed gets back up to 67-72MB/s. This wastes all the time and doesn't feel like it should be doing this.

the speed in the ui is the average of the last 60 samples as reported by rsync, which has control at this point in time, it's the one doing the file transfer, it would seem to indicate that the specific file/folder where the speed drop happens may have some issues

you can stop the operation, the status after that will be

• all commands marked with a green circle have been completed: the file/folders were copied to the destination and deleted from the source (if you chose to do a MOVE operation)
• the command that was stopped will partially exist in the destination disk, the original source files will still be available on the source
• the rest of the source files/folders have not been touched

you can check this in the history tab

hopefully this gives you some insight into how to move forward.

something i would try is run the "problematic" rsync command directly from the command line, see how it behaves

— Reply to this email directly, view it on GitHub https://github.com/jbrodriguez/unbalance/issues/87#issuecomment-2047860787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCKNUZ6V4UJEMVQSQUEUATY4VLC3AVCNFSM6AAAAABGAUF6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXHA3DANZYG4 . You are receiving this because you authored the thread.Message ID: @.***>

[couzin2000]

Duration has GROWN to 185 hrs since I wrote. It's been 6 hrs and I added 6. That can't be right?

Sent from my iPhone

On Wed, Apr 10, 2024 at 14:17 Sébastien Ferland @.***> wrote:

Thank you very kindly for the prompt response. I find 179h to be completely crazy; if I were to read files from within Windows and transfer them over Gigabit ethernet to my array directly it would take less than 30 hrs - i've done that. 179 hours is more than a week!!!

What I'm trying to accomplish is to move the files off that one drive, REformat the drive from XFS to ZFS, then re-write the files. I'm inclined to think that if I were to completely remove the drive from the array, format it to ZFS, then add it back to the array so that unraid reconstructs the contents from parity. This operation may take less time!

I'll appreciate any advice you can give me on this. For the moment I'll leave unbalanced to run and i'll see.

Thanks again

Sent from my iPhone

On Wed, Apr 10, 2024 at 11:28 Juan B. Rodriguez @.***> wrote:

I ran a dry run before, all was finished without a hitch, but for some reason the actual move has so far been going for 23h41m and I am left with 179h47m remaining - which is completely unacceptable.

wow ! that's a lot of data you're transferring, almost 8Tb 😮, it doesn't look like 179h is unreasonable (just doing some mental math)

During copying, the files reach around 33-34% copied, and the speed immediately drops from 82MB/s to 0. After 3-4 minutes, the speed gets back up to 67-72MB/s. This wastes all the time and doesn't feel like it should be doing this.

the speed in the ui is the average of the last 60 samples as reported by rsync, which has control at this point in time, it's the one doing the file transfer, it would seem to indicate that the specific file/folder where the speed drop happens may have some issues

you can stop the operation, the status after that will be

• all commands marked with a green circle have been completed: the file/folders were copied to the destination and deleted from the source (if you chose to do a MOVE operation)
• the command that was stopped will partially exist in the destination disk, the original source files will still be available on the source
• the rest of the source files/folders have not been touched

you can check this in the history tab

hopefully this gives you some insight into how to move forward.

something i would try is run the "problematic" rsync command directly from the command line, see how it behaves

— Reply to this email directly, view it on GitHub https://github.com/jbrodriguez/unbalance/issues/87#issuecomment-2047860787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCKNUZ6V4UJEMVQSQUEUATY4VLC3AVCNFSM6AAAAABGAUF6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXHA3DANZYG4 . You are receiving this because you authored the thread.Message ID: @.***>

[jbrodriguez]

if I were to read files from within Windows and transfer them over Gigabit ethernet to my array directly it would take less than 30 hrs - i've done that

thta's writing to a cache disk ? if writing to a parity protected drive, that would seem unusually fast 🤷‍♂️ edit: or maybe not, i haven't closely checked how much it takes to transfer data to my array :)

remove the drive from the array, format it to ZFS, then add it back to the array so that unraid reconstructs the contents from parity. This operation may take less time!

yes, that might be a good way to go

bottom line it seems that rsync is finding some issue

you could run tail -f /var/log/unbalanced.log to check for anything "unusual"

[couzin2000]

Unless I am not doing this right and I should be using Gather instead of Scatter?

Sent from my iPhone

On Wed, Apr 10, 2024 at 15:45 Juan B. Rodriguez @.***> wrote:

if I were to read files from within Windows and transfer them over Gigabit ethernet to my array directly it would take less than 30 hrs - i've done that

thta's writing to a cache disk ? if writing to a parity protected drive, that would seem unusually fast 🤷‍♂️

remove the drive from the array, format it to ZFS, then add it back to the array so that unraid reconstructs the contents from parity. This operation may take less time!

yes, that might be a good way to go

bottom line it seems that rsync is finding some issue

you could run tail -f /var/log/unbalanced.log to check for anything "unusual"

— Reply to this email directly, view it on GitHub https://github.com/jbrodriguez/unbalance/issues/87#issuecomment-2048312462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCKNU6UXF7YJXBR2NBG62TY4WJEFAVCNFSM6AAAAABGAUF6COVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBYGMYTENBWGI . You are receiving this because you authored the thread.Message ID: @.***>

[jbrodriguez]

pls open a new issue if this happens again