Re: Format XFS on replacement drive / Convert from RFS to XFS (discussion only)

[SSD]

So, I've been putting this off for some time, but finally ran out of other chores to do, so I've been going through this thread and a couple of others. I must say that I find it a little daunting to sling around terabytes on my server in one line commands and my head is spinning a bit after reading up on this.

 

Apart from the fact that it will take longer, is there something wrong with adding an extra drive (all my drives are 4TB) and then follow this scheme.

 

1. Use MC to copy everything from source drive to a /t folder on extra drive (TeraCopy is not for me either, as it hiccups a lot with large copy batches)

2. Verify that everything was copied correctly and fully

3. Reformat the old drive to XFS

4. Copy back the content of the /t folder to the source drive (now formatted to XFS)

5. Verify that everything was copied correctly and fully

 

It seems to me that this way I will not have to worry about new configs, disk placements and which disks are part of what share?

 

Nothing wrong. But migrating the data from drive to drive reduces the amount of data copied by 1/2. If you are doing 1 or 2 disks, maybe not such a big deal. But if you are doing 8 or 10, it certainly adds significant time to the effort.

[In2Photos]

Migrated my disks to XFS over the weekend. A big thanks to everyone here! Teracopy worked flawlessly for me! This is easily the most work I've done on this server since I build it years ago. Upgraded from 4.5.4 to 6, replaced the parity drive, added the additional data drive, and formatted all disks to XFS. Hoping the upgrades will keep this thing churning for a couple more years!

[jeffreywhunter]

In the original post...

 

10 - Now is the good time to move the files in the "t" directory to the root on [dest]. I do this with cut and paste from Windows explorer.

 

Wouldn't cut/paste from windows cause you to move ALL the files twice - and over the network?  Seems like you'd want to do all the operations disk to disk on the server?

[SSD]

In the original post...

 

10 - Now is the good time to move the files in the "t" directory to the root on [dest]. I do this with cut and paste from Windows explorer.

 

Wouldn't cut/paste from windows cause you to move ALL the files twice - and over the network?  Seems like you'd want to do all the operations disk to disk on the server?

 

No - this is a move not a copy. Since the move is on the same volume it is more of a rename and no data is copied. It happens very fast.

[jeffreywhunter]

Even when done via a windows PC over the LAN?  Is that a special feature of linux?  If I do this (a cut/paste from a remote PC to another drive on that remote pc) on a windows directory from a remote PC, all the files get copied from the first PC to the second (temp in memory I think), then again over the net to the destination drive.  Effectively copying the file twice...

[In2Photos]

Even when done via a windows PC over the LAN?  Is that a special feature of linux?  If I do this (a cut/paste from a remote PC to another drive on that remote pc) on a windows directory from a remote PC, all the files get copied from the first PC to the second (temp in memory I think), then again over the net to the destination drive.  Effectively copying the file twice...

 

I just did this move with a cut/paste over the weekend and it was instant. No copying of any files across my Windows PC or the network. Not sure of the "behind the scenes" details of how it works, but it does.

[JonathanM]

Even when done via a windows PC over the LAN?  Is that a special feature of linux?  If I do this (a cut/paste from a remote PC to another drive on that remote pc) on a windows directory from a remote PC, all the files get copied from the first PC to the second (temp in memory I think), then again over the net to the destination drive.  Effectively copying the file twice...

 

I just did this move with a cut/paste over the weekend and it was instant. No copying of any files across my Windows PC or the network. Not sure of the "behind the scenes" details of how it works, but it does.

If the source and destination are on the same physical drive, the move will be nearly instantaneous, as only the directory listing has changed, the data has not moved. If you are intending to vacate a drive by copying the data to a different drive, it will not be quick, it will move at whatever speed your network connection and drives can handle. Most peoples parity protected unraid systems are drive speed limited instead of network limited, so there is very little difference between doing a drive to drive copy over the network or locally.

[bigsing]

8 - It is now highly recommended to compare the checksums of the source to the dest. (If not, at least spot check several files). There are multiple ways to do that including md5sum, bitrot (a user contributed script). There is also a way to use rsync (perhaps Weebo will post or link instructions - sorry, i couldn't find them) to do the copy and verify in one rsync step. If there are questions here, please ask. My method is a bit of a Rube Goldberg, but will try to clean it up and post if there is interest.

 

UPDATE: Here is one way to complete step 8 (see later post in this thread) (thanks to danioj):

 

From a screen session, run this command:

  rsync -nrcv /mnt/[source] /mnt[dest]/t >/boot/verify.txt

 

This will put the output of the comparison in a file on the flash disk. It will likely have little or no output, but this will preserve all output in case it is lengthy and would scroll off the screen.

 

You can view the output with this command in another session:

  cat /boot/verify.txt

 

bjp999, i was reviewing the steps you posted on the first page and noticed an error. There is a / missing between /mnt and [dest] in the rsync command. Just thought i'd point it out.

[SSD]

bjp999, i was reviewing the steps you posted on the first page and noticed an error. There is a / missing between /mnt and [dest] in the rsync command. Just thought i'd point it out.

 

Thanks! Fixed:

  rsync -nrcv /mnt/[source] /mnt[dest]/t >/boot/verify.txt

 

changed to

  rsync -nrcv /mnt/[source] /mnt/[dest]/t >/boot/verify.txt

[Just Me]

There is still a "/" missing: http://lime-technology.com/forum/index.php?topic=37490.msg382778#msg382778

 

rsync -nrcv /mnt/[source]/ /mnt/[dest]/t >/boot/verify.txt

[SSD]

There is still a "/" missing: http://lime-technology.com/forum/index.php?topic=37490.msg382778#msg382778

 

rsync -nrcv /mnt/[source]/ /mnt/[dest]/t >/boot/verify.txt

 

Done.

[arcane]

Started to use this guide to migrate from RFS to XFS.  I used the diskmv script from another thread to transfer the files which does not use a /t directory.  Verified all files in the end without any problems with dupes.

 

 

Which reminds me, I've wanted to ask, has *anyone* done it without using the extra T folder, and did you have any problems?  Did file duplicates appear, and if they did, were they a serious problem, or just a temporary nuisance?

[RobJ]

Started to use this guide to migrate from RFS to XFS.  I used the diskmv script from another thread to transfer the files which does not use a /t directory.  Verified all files in the end without any problems with dupes.

 

 

Which reminds me, I've wanted to ask, has *anyone* done it without using the extra T folder, and did you have any problems?  Did file duplicates appear, and if they did, were they a serious problem, or just a temporary nuisance?

 

Thank you!

[SSD]

Started to use this guide to migrate from RFS to XFS.  I used the diskmv script from another thread to transfer the files which does not use a /t directory.  Verified all files in the end without any problems with dupes.

 

 

Which reminds me, I've wanted to ask, has *anyone* done it without using the extra T folder, and did you have any problems?  Did file duplicates appear, and if they did, were they a serious problem, or just a temporary nuisance?

 

Thank you!

 

I would not expect the "t" directory to be needed normally, but I imagine someone copying several million files small files (maybe mp3s or jpgs) causing an issue. I don't think it makes the process much more complicated and may avoid a problem for some edge case.

[ekim]

Just working through converting my drives at the moment.

 

I did my first transfer of files but the space free on each drive according to UnRaid is different? I would expected it to be the same. I am verified the files and nothing came up different. Any obvious reasons that the file space remaining wouldn't be equal between the two drives?

[SSD]

Just working through converting my drives at the moment.

 

I did my first transfer of files but the space free on each drive according to UnRaid is different? I would expected it to be the same. I am verified the files and nothing came up different. Any obvious reasons that the file space remaining wouldn't be equal between the two drives?

 

Different filesystems will not use exactly the same amount of space to store the same set of files. It will be rather close, but not exact. I have seen cases where XFS has used more space than RFS, and cases where the opposite is true. The md5 / content compares with are the key to verifying the copies completed successfully.

[ekim]

I had thought that might be the case. Was 2gb different for my first disk transfer. The rsync check came back fine so figured it was all good.

 

The second drive came back 8gb different and just checking the rsync now.

 

[tr0910]

Even with the same file system it is possible.

 

I had 2 rfs disks replicated daily with rsync for the last 2 years where the destination disk was smaller than the source even after a successful rsync. This started my exploration into Bitrot and bunker, as my files had no md5 hashes. We proved that it is possible to have the same contents with differing free space on rfs.

[SSD]

I had thought that might be the case. Was 2gb different for my first disk transfer. The rsync check came back fine so figured it was all good.

 

The second drive came back 8gb different and just checking the rsync now.

 

2-8g are reasonable differences on 3-4T drives. You are talking about 0.05% - 0.27%.

[alphazo]

Just to post another success story on moving from ReiserFS to XFS. Well it took some time (14 disks) and I only used rsync, hashdeep (found in md5deep package) and vim (not on unRAID).

Basically I did for each disk and in parallel using multiple screen sessions. diskX is the source (rfs), diskY is the destination (XFS) diskZ is a scratch area to save the checksums.

mkdir /mnt/diskY/diskX
rsync -av --stats --progress /mnt/diskX/ /mnt/diskY/diskX
cd /mnt
hashdeep -r -l -e diskX > /mnt/diskZ/hash-diskX-source
cd /mnt/diskY
hashdeep -r -l -e diskY > /mnt/diskZ/hash-diskX-copy

 

Then it was time to compare the hashes before wiping out the source disk. Since the hashes are not written in the same order.

There might be more elegant way to sort and clean the top of the file but I just used vim (on my PC and not unRAID) for that.

vim /mnt/diskZ/hash-diskX-source

Then I needed to remove the 4-5 top lines

5dd

 

Then sorted the hash list

:sort
:wq

 

Same Vim operation needs to be done with /mnt/diskZ/hash-diskX-copy

 

After that diff can be used to verify that the copy is perfect.

diff /mnt/diskZ/hash-diskX-copy /mnt/diskZ/hash-diskX-source

 

If the diff operation doesn't return anything bad then you are good to go for:

• Formatting diskX
  
• Moving everything from /mnt/diskY/diskX to the root of /mnt/diskY (this can be done with mv and doesn't take any time
  
• Move to the next drive

 

I recommend to keep a spreadsheet handy so you can track the actions to run especially if you run concurrent rsync and hashdeep operations.

 

I do recognize that going through the hashing is a bit extreme and paranoid but heck it doesn't hurt as well.

[tr0910]

The wiki for converting drives had the rsync command as follows

 

rsync  -avPX  /mnt/disk15  /mnt/disk5

 

When I run that I get a folder called disk15 on disk5

 

Isn't this the correct command?

 

rsync  -avPX  /mnt/disk15/  /mnt/disk5/

 

I updated the wiki...

[shooga]

I successfully moved from rfs to xfs using the process and commands from this thread. Thanks for the great info.

 

Specifically, I used:

 

rsync -av --progress --remove-source-files /mnt/diskX/ /mnt/diskY/ >rsync.log 2>rsync.err

 

Those last two arguments (>rsync.log 2>rsync.err) send the output and errors to separate log files, which I monitored using the tail command: tail -f filename.ext

 

I did this all in three screen sessions (one for the rsync and one for each tail command). Worked great and I was able to follow the progress while also capturing the output in case anything went wrong and I needed to refer to it later. Thankfully, there were no errors.

[Brucey7]

The wiki for converting drives had the rsync command as follows

 

rsync  -avPX  /mnt/disk15  /mnt/disk5

 

When I run that I get a folder called disk15 on disk5

 

Isn't this the correct command?

 

rsync  -avPX  /mnt/disk15/  /mnt/disk5/

 

I updated the wiki...

 

The command you need is

 

rsync --progress -avh /mnt/disk15/ /mnt/disk5

 

This will not give you a top level directory of disk15 with your data under it.  Unfortunately, the rsync documentation is wrong on some sites, I have found this out by trial and error.  I should add, this will leave your original disk untouched, i.e. not remove the files.

[Furby8704]

im in the process of moving my data over to xfs

started my first 2tb transfer with rsync last nite

 

im currently running plex only since its only on disk1 and isnt being use by any share

i assumed it be slow while transferring but not to the point where its unusable

is that normal?? pretty much plex been down since the transfer began

if thats the case ill have to time my transfer to avoid this issue lol

 

EDIT:

 

just started my 2nd 2TB transfer. plex seems to be slow but working ok for now

my kodi box works fine but does buffer on occasion. ill keep an eye on plex

 

EDIT 2:

 

yea plex doesnt work when moving the files over

ive transferred 8TB and plex been down for a few days now

kodi is handling way better almost to no difference

[Billz]

I have a quick question.  I'm sorry if it has already been covered, but I'm still on Unraid 5.  I want to move to 6 and convert all my disks to XFS gradually.  If I run the array with mostly RFS disks and one or two XFS disks, will my array still be protected?  Can I recover from a disk loss, either RFS or XFS disk losses?  I just want to be sure as I have all 2tb drives and want to slowly convert all of them to 5TB drives over the period of a year.  Any clarification would be greatly appreciated.