29 minutes ago, trurl said:

I always recommend NOT sharing disks on the network.

I copy my Blu-ray rips directly to the drive instead of to the shares. I guess I only need one drive at a time to be reachable from the network

Why do you not recommend that?

Do you also allow network access to user shares?

5 hours ago, gnollo said:

I copy my Blu-ray rips directly to the drive instead of to the shares.

Of course, the rip will ultimately go to a single drive even if you copy it to a user share.

16hrs done, 30% copied across on a 10TB drive. So just under 5 and half hours per TB so far. The terminal window shows each file that has been copied across so that is quite useful to see.

62%. Out of curiosity, is rsync -rcvpx faster than the full copy of files? I expect that the first direct copy will be completed some time tomorrow.

9TB direct copy finished after 54hours, no error messages. Started the rsync -rcvpx now, let's see how long it takes.

On 1/25/2026 at 12:26 PM, gnollo said:

Why do you not recommend that?

On 1/25/2026 at 5:55 PM, trurl said:

Do you also allow network access to user shares?

You must never mix disks and user shares when moving or copying data. That's the main reason I don't recommend sharing disks on the network. Also, it's not necessary. You can manage files directly on the server with the built-in File Manager in the webUI, and it won't allow you to make the mistake of mixing disks and user shares.

22 hours ago, gnollo said:

9TB direct copy finished after 54hours, no error messages. Started the rsync -rcvpx now, let's see how long it takes.

Just took a look at the PC, no terminal window open, it's gone.

Does it mean that the process completed succesfully? How can I check?

When it was running CPU usage was high, now it is about 5%.

Does the rsync command create a log and where can I find it? I searched in the syslog for rsync and if found nothing.

The command I run was

rsync -rcvpx /mnt/disk4/ /mnt/disk12/

I opened the terminal window through the unraid web interface, and it disappeared overnight, possibly this is what is supposed to happen if no extra files are found? I cannot be sure, can somebody please confirm?

Alternatively is there a way that I can create a script that would provide a log file when completed?

Cannot format the rfs drive until I am sure it has been double checked that it worked perfectly...

Edited January 29Jan 29 by gnollo
extra questions

AFAIK, when the terminal window closes, the rsync program is killed. Not to worry just start rsync again with the same parameters and it will pick up right where it left off. Rsync was designed to be bulletproof on unreliable connections even between continents. It is designed to be able to recover gracefully from this type of situation with a minimum of hassle!

That is, if you were not using some program like screen or tmux. If you have all of the components of the Unassigned Devices plugin installed, you have tmux. Google tmux cheat sheet pdf for instructions on using it. These programs run permanently once started and you just connect to them when you want to. (Think of it like the Unraid GUI...)

For more info on rsync, see here:

https://en.wikipedia.org/wiki/Rsync

Edited January 29Jan 29 by Frank1940

2 hours ago, Frank1940 said:

AFAIK, when the terminal window closes, the rsync program is killed. Not to worry just start rsync again with the same parameters and it will pick up right where it left off. Rsync was designed to be bulletproof on unreliable connections even between continents. It is designed to be able to recover gracefully from this type of situation with a minimum of hassle!

That is, if you were not using some program like screen or tmux. If you have all of the components of the Unassigned Devices plugin installed, you have tmux. Google tmux cheat sheet pdf for instructions on using it. These programs run permanently once started and you just connect to them when you want to. (Think of it like the Unraid GUI...)

For more info on rsync, see here:

https://en.wikipedia.org/wiki/Rsync

thank you I think you posted two pdfs, one with the wiki and one with the cheat sheet, I downloaded both ages ago.
So I typed tmux and then the command, closed the terminal window, and reopened it.
Tmux attached (Enter) brought it back so thank you for that, let's see if it ends with a message this time. I guess if it all goes OK it will go back to displaying the green root@Tower:

3 hours ago, Frank1940 said:

If you have all of the components of the Unassigned Devices plugin installed, you have tmux.

I think it is Unassigned Devices Preclear specifically that installs tmux.

There is also a separate plugin for tmux Tmux Terminal Manager:

Thank you very helpful now at least I will see when it has completed the run.

13 minutes ago, gnollo said:

Thank you very helpful now at least I will see when it has completed the run.

I use these switches -avhPX (From years ago when I first used rsync to convert my two systems— Those were the switches that the author of the guide that I used suggested.) The -v makes it verbose and the -h improves the readability of that output. You do get a lot of display on the screen but you can see where and what is going on. (The old Unix/Linux guys never wanted things to be verbose because they were often using teletype machines as terminals and the printing noise drove everyone within a fifty yards crazy!)

9 hours ago, gnollo said:

Does the rsync command create a log and where can I find it?

You can make it create a log.

Maybe more useful than that wikipedia article itself is the External Links at the bottom of that article. This one in particular:

LinuxConfig

Rsync examples in Linux

Learn rsync command usage in Linux for file synchronization. Secure, efficient, and versatile for administrators.

14 hours ago, Frank1940 said:

I use these switches -avhPX (From years ago when I first used rsync to convert my two systems— Those were the switches that the author of the guide that I used suggested.) The -v makes it verbose and the -h improves the readability of that output. You do get a lot of display on the screen but you can see where and what is going on. (The old Unix/Linux guys never wanted things to be verbose because they were often using teletype machines as terminals and the printing noise drove everyone within a fifty yards crazy!)

so instead of the following command I used

rsync -rcvPX /mnt/disk4/ /mnt/disk12/

you suggest I could use

rsync -avhPX /mnt/disk4/ /mnt/disk12/

The previous command also includes a -v, but it does not show any output? It only says "sending incremental file list"
Also does -PX differs from -px as a command? I used px instead of PX.

Edited January 30Jan 30 by gnollo
add info

So thank you for the links, did a bit of research to compare the two group of commands

1) -avhPX

So a summary for what the command switches above do:

-a = -rlptgoD (preserves the permissions, timestamps, symbolic links, and other attributes of the files.) the -a command does the following

-r = Recurse into directories

-l = Copy symlinks as symlinks

-p = Preserve permissions

-t = Preserve modification times

-g = Preserve group

-o = Preserve owner

-D = preserve device and special files files (super-user only) and

-v = verbose (every action is written out)

-h = output numbers in a human-readable format,show progress during transfer

-P = resumes partial transfers combining --partial and --progress, resuming partial transfers in case a previous sync is interrupted, and showing the current transfer progress of all files, respectively

-X = preserve extended attributes

2) -rcvPX

-r = Recurse into directories

-c = skip based on checksum, not mod-time & size
-v = verbose

-P = resumes partial transfers

-X = preserve extended attributes

So from where I am standing the biggest differences between the two is

• one inclused a checksum comparison, is that slowing down the process?

• the other one includes -h which outputs numbers in readable formadn and is supposed to show progress during transfer

Interestingly both include -v but I am not seeing any text on the screen,

This is what I found about the -c command,

-c, --checksum

This changes the way rsync checks if the files have been changed and are in need of a transfer. Without this option, rsync uses a lqquick checkrq that (by default) checks if each file's size and time of last modification match between the sender and receiver. This option changes this to compare a 128-bit checksum for each file that has a matching size. Generating the checksums means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer (and this is prior to any reading that will be done to transfer changed files), so this can slow things down significantly.

The sending side generates its checksums while it is doing the file-system

scan that builds the list of the available files. The receiver generates its checksums when it is scanning for changed files, and will checksum any file that has the same size as the corresponding sender's file: files with either a changed size or a changed checksum are selected for transfer.

Note that rsync always verifies that each transferred file was

correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer lq Does this file need to be updated? rq check.

For protocol 30 and beyond (first supported in 3.0.0), the checksum used is

MD5. For older protocols, the checksum used is MD4.

CPU usage very low now, but no message on the console. I think it must have finished?

very annoying, has been a week now.

11 minutes ago, gnollo said:

no message on the console. I think it must have finished?

It should return to the command line prompt when it has completed,

2 hours ago, gnollo said:

I think it must have finished?

Remember this:

On 1/29/2026 at 12:22 PM, Frank1940 said:

(The old Unix/Linux guys never wanted things to be verbose because they were often using teletype machines as terminals and the printing noise drove everyone within a fifty yards crazy!)

So basically no output if everything went smoothly. The command line prompt simply returns.

One more thing. IF you were not using tmux than if the terminal window was terminated, the rsync process was killed when the terminal closed! IF you had to login into the terminal again, you can be almost certain that the terminal program was terminated by something.

To check, rerun the rsync command again. Read your post on switches and use that info... If the copy was completed sucessfully, it will finish in a few minutes. If it was terminated early, rsync will pick up where it left off.

5 hours ago, trurl said:

It should return to the command line prompt when it has completed,

5 hours ago, trurl said:

It should return to the command line prompt when it has completed,

The window timestamp at the bottom is changing in line with the time on the server, which leads me to believe is still running.
Also I cannot type anything on that window, so I think this means it is still running?

Edited January 31Jan 31 by gnollo
corrected the picture

I have rebooted the server to clear all activities and restart the emby docker, as my family was rioting after one week of askimg me are we there yet?
So I will restart the comparison on Sunday night to complete the check. I am going to go with

-avhPX

as I feel that the checksum comparison might be overkill, probably takes much longer than the command above.
If you think I should have the checksum as part of the final comparison before I wipe the source drive, let me know your thoughts please.

checksums not needed, size and timestamps should be enough since it is all on the same clock.

Updated unraid to latest version, 7.2.3, and now I get a message about

"Critical: Deprecated Filesystem

The following array devices are using deprecated filesystems:"

list of all my rfs drives

Action Required: Migrate to a supported filesystem (XFS v5, BTRFS, or ZFS). View migration guide →

Message on the guide is

• Any drives formatted in ReiserFS need to be migrated to another filesystem ASAP as they will not be usable in future releases of Unraid.

• Any drives formatted in older XFS versions need to be migrated before 2030.

The only method recommended there is

Via the WebGUI (Unraid 7.2+):

• Navigate to Main → Array Operation and stop the array

• Navigate to Settings → Global Share Settings. In the Emptying disk(s) area, select the disk(s) to empty and Apply. Note: this status will automatically be removed when the array is stopped.

  • In Unraid 7.2.0, any data on this disk will be hidden from user shares until this status is removed.

  • Starting with Unraid 7.2.1, the data remains available to user shares but new files will not be written to the disk until this status is removed.

• Navigate to Main → Array Operation and start the array

• On Main → Array Operation click Move (or wait until mover runs via its normal schedule)

• Mover will empty the disk, moving files to other array drives according to your Share settings. Note that files at the root of the drive are outside of any Shares and will not be moved.

• Check Tools → System Log for messages about any files that could not be moved due to being in use or a lack of free space

@gnollo What is the issue - that process looks correct (as far as the bit you have listed goes). You do not mention the other steps given that allow you to reformat the drive you have just emptied to a supported file system.