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

[spuddo]

Thanks for the replies gentlemen. I was not in any way questioning the process.  Simply, I was trying to further understand UNRAID and how it works.

 

Regards

[Ice_Black]

I've just upgraded to unRAID 6.0 with a fresh install.

 

I only have 3 disks:

 

2TB Party 

2TB Disk1

2TB Disk2

 

- I have deleted some files from Disk2 to free up some space

- Created a t dir in Disk2

- [in Progress] Right now I am copying all the files from Disk1 to Disk2 (rsync -arv /mnt/disk1 /mnt/disk2/t)

- Once it has been completed, I will format Disk1 to XFS

- Copy everything from Disk2 to Disk1 (using rsync command)

- Format Disk2 to XFS

- Copy all the files from Disk1 excluding t dir to Disk2

- on Disk 1, move /mnt/disk1/t/ to /mnt/disk1/

 

Is this good step?

 

[danioj]

I've just upgraded to unRAID 6.0 with a fresh install.

 

I only have 3 disks:

 

2TB Party 

2TB Disk1

2TB Disk2

 

- I have deleted some files from Disk2 to free up some space

- Created a t dir in Disk2

- [in Progress] Right now I am copying all the files from Disk1 to Disk2 (rsync -arv /mnt/disk1 /mnt/disk2/t)

- Once it has been completed, I will format Disk1 to XFS

- Copy everything from Disk2 to Disk1 (using rsync command)

- Format Disk2 to XFS

- Copy all the files from Disk1 excluding t dir to Disk2

- on Disk 1, move /mnt/disk1/t/ to /mnt/disk1/

 

Is this good step?

 

Do you have a Backup of data? I hope so!!!

[itimpi]

I've just upgraded to unRAID 6.0 with a fresh install.

 

I only have 3 disks:

 

2TB Party 

2TB Disk1

2TB Disk2

 

- I have deleted some files from Disk2 to free up some space

- Created a t dir in Disk2

- [in Progress] Right now I am copying all the files from Disk1 to Disk2 (rsync -arv /mnt/disk1 /mnt/disk2/t)

- Once it has been completed, I will format Disk1 to XFS

- Copy everything from Disk2 to Disk1 (using rsync command)

- Format Disk2 to XFS

Up to here is what I would expect.

 

- Copy all the files from Disk1 excluding t dir to Disk2

- on Disk 1, move /mnt/disk1/t/ to /mnt/disk1/

 

Is this good step?

Not sure what I understand what you are trying to achieve here?  What you have specified should work but it will end up with all the files that were originally on disk2 now on disk1 and vice versa.  I would have expected you to be copying the contents of disk1/t back to the reformatted disk2 to get back the files that were originally there?  Is that what you are trying to achieve or have I missed something?

[Ice_Black]

I've just upgraded to unRAID 6.0 with a fresh install.

 

I only have 3 disks:

 

2TB Party 

2TB Disk1

2TB Disk2

 

- I have deleted some files from Disk2 to free up some space

- Created a t dir in Disk2

- [in Progress] Right now I am copying all the files from Disk1 to Disk2 (rsync -arv /mnt/disk1 /mnt/disk2/t)

- Once it has been completed, I will format Disk1 to XFS

- Copy everything from Disk2 to Disk1 (using rsync command)

- Format Disk2 to XFS

Up to here is what I would expect.

 

- Copy all the files from Disk1 excluding t dir to Disk2

- on Disk 1, move /mnt/disk1/t/ to /mnt/disk1/

 

Is this good step?

Not sure what I understand what you are trying to achieve here?  What you have specified should work but it will end up with all the files that were originally on disk2 now on disk1 and vice versa.  I would have expected you to be copying the contents of disk1/t back to the reformatted disk2 to get back the files that were originally there?  Is that what you are trying to achieve or have I missed something?

 

The original contents of disks2 will need to go back to the reformatted disk2

 

If you re-read my post, I am copying all the contents from Disk1 to Disk2/t and then Disk1 will be formatted (XFS).

 

Disk2  then will be copied to Disk1 (new format XFS)

 

Format Disk2

 

Then copy everything from Disk1 to Disk2  excluding "t" folder..

 

That mean I will have original contents in Disk1 and Disk2.

 

 

 

[itimpi]

OK.  I think I missed one of the copying stages you planned to do

[spuddo]

You might want to verify that the copy to Disk2/t worked before you format Disk1.

 

This will show any errors

 

rsync -nrcvPX /mnt/disk1 /mnt/disk2/t

 

If you get errors they can be corrected by removing the -n option

 

rsync -rcvPX /mnt/disk1 /mnt/disk2/t

 

For copying files I do a dry run first, then do the copy. I use this command

(I believe the '-a' option includes the'-r'. worked for me.

 

rsync -navPX /mnt/disk1 /mntdisk2/t

 

Then if that looks OK, remove the -n option

 

rsync -avPX /mnt/disk1 /mntdisk2/t

 

 

 

[spuddo]

Could I have some help please with instructions for converting my 60G SSD Cache drive from RFS to XFS.

 

My sever:

 

Parity 3TB

Disk1 1TB

Disk2 1TB

Disk3 3TB

Disk4 1TB

Disk5 3TB

Cache 60Gb SSD

 

 

I am in the process of moving my data drives from RFS to XFS (Many thanks to RobJ and bjp999 for their very good instructions and hints.) So far all is going well.  Took about 8 hours to move the first 1G of data

 

The Cache has a docker.img file and a "cache only" apps share that contains Plex Media Server data.

 

[SSD]

Took about 8 hours to move the first 1G of data

 

Assuming you mean 1T of data.

 

In general, converting a cache drive just requires copying the data off of the current cache drive to another disk, stopping the array, changing the filesystem on the cache, starting the array, and then formatting the cache. THen copying the cache data back to the cache disk.

 

In order to do this you'd need to stop docker, and maybe disable it completely. This might force you to recreate the docker.img on the newly formatted drive, which might be a little PITA but not so difficult either.

 

I have never tried to preserve the existing docker.img but can think of some ways to fake out unRAID (like coping docker.img to another disk, then disabling docker and deleting the docker.img on the cache, reformatting to XFS, creating a new docker.img, and then overwriting the new docker.img with the backup). This is not for the casual user to do, as you'd need to do all the copying of docker.img very carefully while docker.img is not mounted as the loopback file system, but seems possible.

 

RobJ or others may have a more practical and tested process. I have just never done it myself.

 

Update: Refer to THIS LINK for instructions on recreating the docker.img file.

[spuddo]

Thank you. Yes I did mean 1TB.

 

I was intending to stop Plex but will look at the Docker ideas and link you provided.

 

Will do this in the next day or so and let you know how I go.

 

I am keen to convert the cache to XFS as RFS does not seem to support FSTRIM on the SSD.

[JimPhreak]

If I have 2 empty disks, can do 2 copying sessions in screen at once or will the speed be the same regardless?

[spuddo]

Can't see why not. I would just did one at a time. It's not a race.

[JimPhreak]

Can't see why not. I would just did one at a time. It's not a race.

 

It's not a race but this is my backup server and there is some data I'd like to get backed up to it ASAP.

[SSD]

If I have 2 empty disks, can do 2 copying sessions in screen at once or will the speed be the same regardless?

 

I would recommend one at a time if your destinations are part of the parity protected array. Although the data disk may be different, they both require reads and writes to parity. I think copying serially may be faster than in parallel. If parity were disabled, doing in parallel would be a good idea.

[In2Photos]

Can someone tell me if I am planning this correctly?

 

I have a small server. Right now I have a 3 drives and my shares span across both drives:

 

Disk 0 - 3TB Parity

Disk 1 - 1.5TB Data (RFS)

Disk 2 - 500GB Data (RFS)

 

I am in the process of pre-clearing a new drive right now (Disk 3 - 3TB Data). When finished I will format it XFS. This drive could hold all the data from both drives. So my plan is to:

 

1. Format the new 3TB drive (disk 3) XFS when pre-clear finishes.

2. Create a "t" directory on Disk 3.

3. Copy files from Disk 1 to Disk 3. I plan to use Teracopy instead of the command line in screen as I am more comfortable with Teracopy and it validates the copy. I guess I could still perform Step 8 though, Thoughts?

4. Copy files from Disk 2 to Disk 3. Since the folders for the shares already exist on this drive from the previous copy it should "merge" all the subfolders into the same share folders correct?

5. Move the files from the "t" directory to the root of Disk 3.

6. Format Disk 2 XFS.

7. Format Disk 3 XFS.

 

This should give me all 3 disks formatted XFS. But all of my data will be on Disk 3. Should I split the data up after this? Should I move the data from the first move and format Disk 1 before moving to Disk 2? Then I could copy Disk 2 to Disk 1, then for format Disk 2. This would leave Data on 2 disks?

 

Anything I should change? Thanks!

[trurl]

Can someone tell me if I am planning this correctly?

 

I have a small server. Right now I have a 3 drives and my shares span across both drives:

 

Disk 0 - 3TB Parity

Disk 1 - 1.5TB Data (RFS)

Disk 2 - 500GB Data (RFS)

 

I am in the process of pre-clearing a new drive right now (Disk 3 - 3TB Data). When finished I will format it XFS. This drive could hold all the data from both drives. So my plan is to:

 

1. Format the new 3TB drive (disk 3) XFS when pre-clear finishes.

2. Create a "t" directory on Disk 3.

3. Copy files from Disk 1 to Disk 3. I plan to use Teracopy instead of the command line in screen as I am more comfortable with Teracopy and it validates the copy. I guess I could still perform Step 8 though, Thoughts?

4. Copy files from Disk 2 to Disk 3. Since the folders for the shares already exist on this drive from the previous copy it should "merge" all the subfolders into the same share folders correct?

5. Move the files from the "t" directory to the root of Disk 3.

6. Format Disk 2 XFS.

7. Format Disk 3 XFS.

 

This should give me all 3 disks formatted XFS. But all of my data will be on Disk 3. Should I split the data up after this? Should I move the data from the first move and format Disk 1 before moving to Disk 2? Then I could copy Disk 2 to Disk 1, then for format Disk 2. This would leave Data on 2 disks?

 

Anything I should change? Thanks!

I assume for step 7 you meant to say Format Disk 1 XFS. There is no need to split the data after you have it all on disk3. 

[Just Me]

I guess I could still perform Step 8 though, Thoughts?

You could but teracopy will already check the checksum and make sure all data are okay. I would trust teracopy and skip step 8.

[gundamguy]

2. Create a "t" directory on Disk 3.

 

 

I'm not sure that this step was ever really necessary, but doing it won't hurt. 

 

3. Copy files from Disk 1 to Disk 3. I plan to use Teracopy instead of the command line in screen as I am more comfortable with Teracopy and it validates the copy. I guess I could still perform Step 8 though, Thoughts?

 

 

I'm not exactly sure how Teracopy validates but I would trust its methods. Peforming a rsync -c check will take awhile and is wasted time if you've already validated the data IMO.

 

Other then what has already been pointed out, looks good.

[SSD]

I am a teracopy fan, and use it often. But for some reason, doing massive copies it has given me trouble. On two separate occasions involving different disks, a destination disk has red-balled after over 900G of data of a multi-terabyte operation. This was using Teramove with compare. Doing server side operations (cp,mv) I have never had a problem with even the largest operations. No explanation, and may be unique to my array, but I now don't use teracopy if trying to move more than a couple hundred gig (which is extremely rare).

[In2Photos]

Can someone tell me if I am planning this correctly?

 

I have a small server. Right now I have a 3 drives and my shares span across both drives:

 

Disk 0 - 3TB Parity

Disk 1 - 1.5TB Data (RFS)

Disk 2 - 500GB Data (RFS)

 

I am in the process of pre-clearing a new drive right now (Disk 3 - 3TB Data). When finished I will format it XFS. This drive could hold all the data from both drives. So my plan is to:

 

1. Format the new 3TB drive (disk 3) XFS when pre-clear finishes.

2. Create a "t" directory on Disk 3.

3. Copy files from Disk 1 to Disk 3. I plan to use Teracopy instead of the command line in screen as I am more comfortable with Teracopy and it validates the copy. I guess I could still perform Step 8 though, Thoughts?

4. Copy files from Disk 2 to Disk 3. Since the folders for the shares already exist on this drive from the previous copy it should "merge" all the subfolders into the same share folders correct?

5. Move the files from the "t" directory to the root of Disk 3.

6. Format Disk 2 XFS.

7. Format Disk 3 XFS.

 

This should give me all 3 disks formatted XFS. But all of my data will be on Disk 3. Should I split the data up after this? Should I move the data from the first move and format Disk 1 before moving to Disk 2? Then I could copy Disk 2 to Disk 1, then for format Disk 2. This would leave Data on 2 disks?

 

Anything I should change? Thanks!

I assume for step 7 you meant to say Format Disk 1 XFS. There is no need to split the data after you have it all on disk3.

 

Yes I did. Thanks!

 

I guess I could still perform Step 8 though, Thoughts?

You could but teracopy will already check the checksum and make sure all data are okay. I would trust teracopy and skip step 8.

 

Thanks!

 

2. Create a "t" directory on Disk 3.

 

 

I'm not sure that this step was ever really necessary, but doing it won't hurt. 

 

3. Copy files from Disk 1 to Disk 3. I plan to use Teracopy instead of the command line in screen as I am more comfortable with Teracopy and it validates the copy. I guess I could still perform Step 8 though, Thoughts?

 

 

I'm not exactly sure how Teracopy validates but I would trust its methods. Peforming a rsync -c check will take awhile and is wasted time if you've already validated the data IMO.

 

Other then what has already been pointed out, looks good.

 

Thanks!

 

I am a teracopy fan, and use it often. But for some reason, doing massive copies it has given me trouble. On two separate occasions involving different disks, a destination disk has red-balled after over 900G of data of a multi-terabyte operation. This was using Teramove with compare. Doing server side operations (cp,mv) I have never had a problem with even the largest operations. No explanation, and may be unique to my array, but I now don't use teracopy if trying to move more than a couple hundred gig (which is extremely rare).

 

Recently I have used Teracopy to create a backup of my entire server to an external drive as well as moved several hundred gigs around with no problems. I'll keep my fingers crossed though!

[garycase]

I am a teracopy fan, and use it often. But for some reason, doing massive copies it has given me trouble. On two separate occasions involving different disks, a destination disk has red-balled after over 900G of data of a multi-terabyte operation. This was using Teramove with compare. Doing server side operations (cp,mv) I have never had a problem with even the largest operations. No explanation, and may be unique to my array, but I now don't use teracopy if trying to move more than a couple hundred gig (which is extremely rare).

 

When I built my backup server a year or so ago, I did a massive TeraCopy from my media server (24TB) and another pretty large one (~ 11TB) from my backup server.    Both worked just fine.    The only difference from what you noted is that these were copies with verification -- not moves.  Was there anything "special" about the moves you were doing -- i.e. were they restricted to a specific disk?  [still hard to see how that would cause a red-ball, but it's equally hard to see how TeraCopy could be responsible for this either.]

 

 

 

[danioj]

I am a teracopy fan, and use it often. But for some reason, doing massive copies it has given me trouble. On two separate occasions involving different disks, a destination disk has red-balled after over 900G of data of a multi-terabyte operation. This was using Teramove with compare. Doing server side operations (cp,mv) I have never had a problem with even the largest operations. No explanation, and may be unique to my array, but I now don't use teracopy if trying to move more than a couple hundred gig (which is extremely rare).

 

+1 for no issues with Terracopy either. I use it ALL the time with Verify Copy enabled. Have thrown TB's of data around, never an issue.

 

EDIT: I tell a lie. The v3.0 Alpha is a buggy thing. Crashes all the time. All my positive comments relate to the Stable versions.

[opentoe]

I am a teracopy fan, and use it often. But for some reason, doing massive copies it has given me trouble. On two separate occasions involving different disks, a destination disk has red-balled after over 900G of data of a multi-terabyte operation. This was using Teramove with compare. Doing server side operations (cp,mv) I have never had a problem with even the largest operations. No explanation, and may be unique to my array, but I now don't use teracopy if trying to move more than a couple hundred gig (which is extremely rare).

 

This is the twilight zone. I've always had these type issues with Teracopy. And it crashing on me all the time. I never mentioned anything cause everyone praised it so much.

[WizADSL]

I'm using the rsync method to move from RFS to XFS on UnRaid 6.0.1.  The command line I am using is:

 

rsync -avX --progress --remove-source-files /mnt/diskXX/ /mnt/diskXX/

 

In my case I've added the X flag to preserve extended attributes (although I'm not sure I need it, I seem to recall that RFS extended attributes are used to store some samba attributes).  The reason for my post is that the version of rsync this is installed in 6.0.1 is 3.1.0 and I noticed after copying a 3TB drive that although the "a" (archive) flag preserves the timestamps on copied files, it does not do this for directories.  I decided to install the latest version of rsync (3.1.1) and it DOES preserve directory timestamps. There is a flag (-O, --omit-dir-times) available in order is disable the behavior; since this flag is present in 3.1.0 and 3.1.1 then I assume the directory dates not being set was a bug in 3.1.0.

 

If anyone is interested I got version 3.1.1 from http://mirrors.slackware.com/slackware/slackware64-current/slackware64/n/rsync-3.1.1-x86_64-1.txz

 

Please keep in mind that when using the rsync command as illustrated above the entire directory structure from the source will be created on the destination disk with the current date/time and only after the directory's contents have been copied will the timestamp be updated.

[t33j4y]

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?