Converting FileSystems

[Tbtf]

Hi,

 

I was planning on performing a filesystem conversion from reiserfs to xfs. I watched a video on youtube (https://www.youtube.com/watch?v=uPPnY3jbRKg) and read the wiki and understand the process for the most part. However the video i watched did not maintain parity throughout the process, and from reading the wiki it seems like its possible to do so. From my understanding what i need to do is the following to maintain parity throughout the conversion process.

 

1) Make sure each share has 0 exclusions for drives and has inclusions for ALL drives in the array

2) Use unbalance to move the data from a reiserfs drive to the formatted xfs drive in the array

3) After moving all the data off the reiserfs drive stop the array and format the reiserfs to xfs. Im a little bit fuzzy on this step as the wiki didnt go into much detail on how to exactly do this. But would I just stop the array go to the disk details for the HD that I moved all the data off of? And then change the filesystem type to xfs, then start the array back up? From there i believe it lets you format the disk? I was just assuming after formatting i would need to rebuild parity.

 

Another question I have is the wiki mentions stopping the user shares. Do i just do that by going to each individual one and putting them as export = NO?

The wiki also references stopping this APP Backup plugin, however im not sure where that is? 

 

Here is a screenshot of the array, I have moved off all of the 500gb to the the 3tb xfs disk. I was planning on moving one of the 2tb's off to the 3tb then formatting them using the method above.  Does that sound correct?

 

Thanks

[JonathanM]

5 minutes ago, Tbtf said:

I was just assuming after formatting i would need to rebuild parity.

Parity has no concept of files or format, it just tracks bit changes. As long as you don't remove drives, or operate on the drives without the array started, parity will be maintained. Format is just another part of the binary patterns that make up the data on the disk.

8 minutes ago, Tbtf said:

Here is a screenshot of the array, I have moved off all of the 500gb to the the 3tb xfs disk. I was planning on moving one of the 2tb's off to the 3tb then formatting them using the method above.  Does that sound correct?

Yep.

 

All the other stuff is just about making sure nothing gets written to the drive after you cleaned it off and before you format it. As long as you are positive there is nothing you need on the drive, you can format it.

 

BTW, it's much slower to delete the data from the source ReiserFS drive than it is to just copy it to the destination XFS and format it after you are sure the copy is complete and accurate, but I understand why you want to do it that way.

[Tbtf]

Thank you @jonathanm, 

 

3 minutes ago, jonathanm said:

BTW, it's much slower to delete the data from the source ReiserFS drive than it is to just copy it to the destination XFS and format it after you are sure the copy is complete and accurate, but I understand why you want to do it that way.

When you say this are you suggesting it would be much quicker to perform a copy instead of a move using unBalance, then format to XFS?

 

Also was this formatting procedure correct

1) Stop the Array

2) Go to Disk Details and change File system type, from reiserfs to xfs

3) Start the array, the disk should show in not able to mount

4) Format the unmountable disk

 

Done.

 

[JonathanM]

1 hour ago, Tbtf said:

When you say this are you suggesting it would be much quicker to perform a copy instead of a move using unBalance, then format to XFS?

Copy is always faster than move when going from one parity protected array disk to another. Reason being, when you move, the source disk is asked to delete the file after the copy, which is a write operation to update the table of contents. So you are writing to both the source and destination disks, both of which are updating the parity disk, at different physical addresses, causing a slowdown in general, typically halving performance or worse.

 

It REALLY doesn't help that ReiserFS can take ages to delete files anyway.

 

However... if you copy instead of move, you have to do more due diligence to make sure nothing is added or changed on the source drive between the time you started the copy and finished checking to make sure the copy was done completely. If you are moving files, it's pretty easy to check that the source drive is indeed empty before formatting.

 

So, your choice is speed and being aware of what's being written to the array to the finest detail, or take your time and move things.

 

BTW, copying introduces another quirk that you must be aware of, that is the duplicate files on the disks will temporarily cause the user shares to act strangely if you aren't aware of what's going on. Consider this, file at /mnt/disk1/usershare/text1.txt is copied to /mnt/disk2/usershare/text1.txt and you navigate to /mnt/user/usershare. You will only see the first copy that's physically on disk1, and if you edit it, the changes happen on disk1. If you then delete the file on disk1, your changes will be gone. Also, if you are looking at the file on /mnt/usershare, and delete it while both copies exist, it will appear as though nothing happened, because the file on disk2 will take its place.

 

If all this sounds too complicated to digest, then just continue with your original plan, it will work fine, just slower. If you are willing to disable the docker service, VM service, and force everyone to stay off the server so nothing will get changed while copying is in progress, then copying is the way to go.

[Tbtf]

makes sense thank you for the help!