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

[RobJ]

No matter what, to convert a drive you MUST move all the data off of it, before you can format it with a new file system, then copy data to it.  So their case is just an extra preliminary step, basically picking one of the largest drives with the least amount of data, then either using unBalance or manually moving all of its data to the rest of the drives.  At that point, they have freed up a drive, and therefore fall into the normal situation, and can use the same procedure as everyone else.  There's no way around it, you HAVE to free a drive up!  To convert your array, you must start with a free and empty data drive, whether you add it or juggle data around to create it.  (I'll try to add this preliminary step to the wiki, for those who need it.)

 

I've now added the gist of the above as 'A preliminary step' to File System Conversion.  I think this is a good thing, as it generalizes the routine for those who cannot add another drive to the array, but still want to convert it.

 

I've also added the term 'swap drive' to refer to the empty drive used for each conversion.  I *think* (not sure) it makes it slightly more intuitive.

[SSD]

RobJ -

 

It is impossible to make anything foolproof, because fools are so ingenious.

 

-Anonymous

[Harro]

Waited till the forum migration was done to ask a few questions regarding this topic. I have an array with 16 data disks along with a parity and cache drive all in reiserfs, I have another array with nothing on it but with the xfs format, I read somewhere that moving the data from a reiserfs disc should be moved to another reiserfs disc, is this correct? Or since I am moving from one array to another array it will make no difference in the disc format?

Another question is on my cache drive, which is holding my dockers, is it simply a copy the appdata folder to somewhere else and format the drive to xfs and copy back?

My array isn't getting any smaller and would like to get this done before I have way too much to move.

Thanks

[trurl]

1 hour ago, Harro said:

... I read somewhere that moving the data from a reiserfs disc should be moved to another reiserfs disc, is this correct?

I can't imagine where you read this, but it isn't correct. When moving and copying between disks or between systems it doesn't matter about the filesystem since those operations are only concerned with files and folders. If you copy a file from your unRAID to your Windows you don't worry about this, right?

1 hour ago, Harro said:

Another question is on my cache drive, which is holding my dockers, is it simply a copy the appdata folder to somewhere else and format the drive to xfs and copy back?

You could do it that way, but you can get unRAID to do most of the work for you by following this wiki, except at step 6 you would just stop the array and skip to step 9 since you aren't replacing the disk.

[Harro]

Thanks for the reply trurl.  I have read the wiki 4 times on the reformatting section but not about the replacing the cache drive. Thanks again. I am still trying to figure out my plan of attack on this. My end goal is to replace the parity with a new 8TB and take old parity (4TB) and replace a 2TB in array, also to replace old blue cache drive with new ssd drive.

My plan of attack in my mind is thus:
My other array with nothing on (used as a test server) holds 10TB, so I could possibly move up to 3 disks in my current array(10-4TB and 6-2TB drives) to my test server, then format those 3 empty disks and move files back on the new reformatted disks. I know this will take time but little will be my time and all computer time.  Does this sound like a reasonable plan or would there be a better way? 

[trurl]

3 hours ago, Harro said:

Thanks for the reply trurl.  I have read the wiki 4 times on the reformatting section but not about the replacing the cache drive. Thanks again. I am still trying to figure out my plan of attack on this. My end goal is to replace the parity with a new 8TB and take old parity (4TB) and replace a 2TB in array, also to replace old blue cache drive with new ssd drive.

My plan of attack in my mind is thus:
My other array with nothing on (used as a test server) holds 10TB, so I could possibly move up to 3 disks in my current array(10-4TB and 6-2TB drives) to my test server, then format those 3 empty disks and move files back on the new reformatted disks. I know this will take time but little will be my time and all computer time.  Does this sound like a reasonable plan or would there be a better way? 

I would say you need some more details in your plan of attack.

The wiki never mentions using another server for reformatting and copying, and not just because many people don't have one. Moving disks between servers will invalidate parity.

Unless you have a really good idea what you're doing and have a very detailed and specific approach in mind, moving disks from one server to another is going to invalidate parity in both. And moving the disks back with files on them is going to invalidate parity in both no matter what you do.

Even if you don't care anything about parity on the test server you are still going to invalidate parity on your main server moving disks back and forth.

Do you understand how parity works? What I say here is pretty obvious if you do understand parity.

[Harro]

I may have over simplified the procedure, but I do understand the parity reasoning. After thinking about all this, another thought for the conversion I have is to take my cache drive out, disable my dockers and mover, replace cache with my 8TB drive and move from within the array itself. If I did that I could move files from disk 1 to new drive, reformat disk 1 and move files back to disk 1.Thinking that should keep my parity valid without running new permissions. Is my thinking correct in that? 

[trurl]

4 minutes ago, Harro said:

I may have over simplified the procedure, but I do understand the parity reasoning. After thinking about all this, another thought for the conversion I have is to take my cache drive out, disable my dockers and mover, replace cache with my 8TB drive and move from within the array itself. If I did that I could move files from disk 1 to new drive, reformat disk 1 and move files back to disk 1.Thinking that should keep my parity valid without running new permissions. Is my thinking correct in that? 

That sounds like a good approach. Maybe one that nobody else has thought of because nobody has a cache disk that large. You could even get your dockers working with this "yuge" cache if you wanted, using the replace cache method I linked before. That way you would still have your apps while going through the lengthy process of converting the other drives. Then replace cache again when done and use it for parity as planned. I like it!

[Harro]

I never thought of keeping the dockers in play during the moving. So that brings me to this question; if dockers were left working on the 8TB drive, I would assume I would need to exclude the disk I am moving (disk 1) in the global setting to prevent any files from being written to that disk until the move, reformat and move back were complete. So in essence I would have to exclude the 8TB and the disk 1. I am moving, correct? I then would move on to next disk with same procedure until I had finished all.  

[trurl]

3 hours ago, Harro said:

I never thought of keeping the dockers in play during the moving. So that brings me to this question; if dockers were left working on the 8TB drive, I would assume I would need to exclude the disk I am moving (disk 1) in the global setting to prevent any files from being written to that disk until the move, reformat and move back were complete. So in essence I would have to exclude the 8TB and the disk 1. I am moving, correct? I then would move on to next disk with same procedure until I had finished all.  

Those details would be up to your specific configuration. For example, I let all disks participate in user shares (global), but for each user share I only include specific disks. Different people set these things up differently and for their own reasons, not always good ones.

 

The main thing to remember about user shares is each user share's settings really only controls where things get written. Any disk which has files for the user share (top level folder) will be included for reads of the share, unless excluded globally from all user shares.

[garycase]

9 hours ago, trurl said:

Moving disks between servers will invalidate parity.

 

I don't think he's talking about physically moving the disks -- but moving the data, which will of course maintain parity on both systems.

Other than the time involved (which Harro correctly notes is virtually all "computer time" and almost none of his time), it's not a bad way to do this, as it completely eliminates any chance of "messing up" with copies/moves within the same server (e.g. the user share copy bug).

 

The only caveat I'd add is to be sure the copies in both directions are done with verification.

 

It's not the quickest way, but it's a VERY safe way to do the migration -- and considering that there's really no "rush" to change the format I'd be inclined to just do one "set" every few days until everything's migrated [where a "set" is 2 4TB drives and 1 2TB drive, since there's 10TB available for the data on the 2nd server].

 

 

[jbrodriguez]

 

11 hours ago, Harro said:

After thinking about all this, another thought for the conversion I have is to take my cache drive out, disable my dockers and mover, replace cache with my 8TB drive and move from within the array itself. If I did that I could move files from disk 1 to new drive, reformat disk 1 and move files back to disk 1

 

But wouldn't data be left without parity protection after disk 1 is reformatted (assuming new drive means the new 8tb cache drive) ?

[Harro]

7 hours ago, garycase said:

3 hours ago, jbrodriguez said:

 

 

But wouldn't data be left without parity protection after disk 1 is reformatted (assuming new drive means the new 8tb cache drive) ?

The only caveat I'd add is to be sure the copies in both directions are done with verification.

 

It's not the quickest way, but it's a VERY safe way to do the migration -- and considering that there's really no "rush" to change the format I'd be inclined to just do one "set" every few days until everything's migrated [where a "set" is 2 4TB drives and 1 2TB drive, since there's 10TB available for the data on the 2nd server].

 

 

Yes garycase that was my initial thought. Then I came up with the second idea , still haven't taken any solid direction in either case yet. But whichever it may be I would like it to be the safest as possible, barring any drives red balling on me.

 

jbrodriguez: the 8TB drive will be replacing a 4TB parity drive once all is done with my upgrading/formatting. For your question on disk 1 without parity, my take on this is, Parity would rebuild disk 1 even if it were empty as long as I keep all disks in the same order and don't change it around. So if my copy fails from the 8TB back to disk 1, parity would see what is missing and rebuild. This is my thinking, but many on here are a lot more component and wiser than I on this. So I may be just blowing smoke out my  *ss.

[trurl]

4 hours ago, jbrodriguez said:

But wouldn't data be left without parity protection after disk 1 is reformatted (assuming new drive means the new 8tb cache drive) ?

I think he does have a point here. If you move the data to cache as I was thinking, then the data is unprotected while on cache.

 

40 minutes ago, Harro said:

Parity would rebuild disk 1 even if it were empty

Parity would rebuild an empty disk. Maybe I'm not understanding what you have in mind.

[Harro]

30 minutes ago, trurl said:

I think he does have a point here. If you move the data to cache as I was thinking, then the data is unprotected while on cache.

 

Parity would rebuild an empty disk. Maybe I'm not understanding what you have in mind.

Maybe I am over thinking this. My mind thinks that if I moved the data from disk 1 to the cache, reformatted disk 1 that parity would be null while disk 1 is being reformatted. But after reformat parity would see disk 1 back in array and could rebuild it at that point if it needed to. But I move the data files from cache back to disk 1, thus giving parity back to valid. Is my thinking wrong ?

[dboonthego]

8 minutes ago, Harro said:

Maybe I am over thinking this. My mind thinks that if I moved the data from disk 1 to the cache, reformatted disk 1 that parity would be null while disk 1 is being reformatted. But after reformat parity would see disk 1 back in array and could rebuild it at that point if it needed to. But I move the data files from cache back to disk 1, thus giving parity back to valid. Is my thinking wrong ?

You are correct except once you format disk1, you've told the system you want to wipe all data from it. Parity is updated to reflect that decision.  If your cache disk failed at this point, you would have data loss.  Someone can correct me if I'm wrong.

[trurl]

8 minutes ago, dboonthego said:

You are correct except once you format disk1, you've told the system you want to wipe all data from it. Parity is updated to reflect that decision.  If your cache disk failed at this point, you would have data loss.  Someone can correct me if I'm wrong.

This is exactly correct.

 

Format is a write operation. It writes an empty filesystem to the disk. unRAID treats this write exactly as it does any other, but updating parity from the written data. So after the format, a rebuild would result in an empty filesystem.

[Harro]

 

25 minutes ago, dboonthego said:

You are correct except once you format disk1, you've told the system you want to wipe all data from it. Parity is updated to reflect that decision.  If your cache disk failed at this point, you would have data loss.  Someone can correct me if I'm wrong.

 

14 minutes ago, trurl said:

This is exactly correct.

 

Format is a write operation. It writes an empty filesystem to the disk. unRAID treats this write exactly as it does any other, but updating parity from the written data. So after the format, a rebuild would result in an empty filesystem.

 

Ah yes that is my missing thinking about the system seeing the new format as empty. Thanks for enlightening me. But if no disaster happens from the time I reformat disk 1 to the time I move data back to disk 1, I would still then keep a valid parity? Or would I need to run a parity check after each successful move of data from each disk?

My plan would run a parity first and then move data from one disk, reformat and move back to said disk. Follow this through until all disks have been reformatted and then run another parity check. I would move all the data with verification, as garycase suggested. 

[dboonthego]

1 hour ago, Harro said:

Ah yes that is my missing thinking about the system seeing the new format as empty. Thanks for enlightening me. But if no disaster happens from the time I reformat disk 1 to the time I move data back to disk 1, I would still then keep a valid parity? Or would I need to run a parity check after each successful move of data from each disk?

My plan would run a parity first and then move data from one disk, reformat and move back to said disk. Follow this through until all disks have been reformatted and then run another parity check. I would move all the data with verification, as garycase suggested. 

 

Yes, parity is written while your data is copied back to disk1; when the copy is complete, parity is valid.  You don't need to run a parity check after each disk copy.  Doing a final parity check isn't required, but not a bad idea.  I disabled/unassigned my parity disk when I did my conversion and was unprotected during the conversion.  When all disks were converted, I reassigned the parity disk and was forced to recalculate parity.

Edited February 22, 2017 by dboonthego

[trurl]

3 minutes ago, dboonthego said:

 

I disabled/unassigned my parity disk when I did my conversion.  When all disks were converted, I reassigned the parity disk back and was forced to recalculate parity.

And this method has the advantage of write speed, at the expense of having no protection until parity is rebuilt at the end.

 

Turbo (reconstruct) write would get you some of the speed back while keeping parity.

 

[garycase]

Harro => I assume you're clear now that as long as you do operations within the array, parity will always be maintained and valid -- but it will reflect the current state of those operations ... i.e. if you format disk #1, then parity will represent an empty, freshly formatted, disk 1.  etc.    But data on the cache drive is NOT protected by parity (as you know), so using that as your intermediate repository for data while you reformat a disk means that data isn't protected during that operation.

 

Personally, I'd just do the copy to the other server; then copy back approach -- which means your data will always be parity protected.   But there's an alternative that would let you do most of the copies on your server =>  (a) copy all of the data from one of your 4TB drives to the 2nd server;  (b)  reformat the 4TB drive to XFS.   But don't copy the data back ... instead, copy all of the data from another 4TB drive to the drive you just formatted as XFS;  then reformat the drive you just copied the data from as XFS, and repeat this for another drive;  etc. ... until all of your drives are XFS.   Then copy the data back from the 2nd server.

 

[Harro]

1 hour ago, garycase said:

Harro => I assume you're clear now that as long as you do operations within the array, parity will always be maintained and valid -- but it will reflect the current state of those operations ... i.e. if you format disk #1, then parity will represent an empty, freshly formatted, disk 1.  etc.    But data on the cache drive is NOT protected by parity (as you know), so using that as your intermediate repository for data while you reformat a disk means that data isn't protected during that operation.

 

Personally, I'd just do the copy to the other server; then copy back approach -- which means your data will always be parity protected.   But there's an alternative that would let you do most of the copies on your server =>  (a) copy all of the data from one of your 4TB drives to the 2nd server;  (b)  reformat the 4TB drive to XFS.   But don't copy the data back ... instead, copy all of the data from another 4TB drive to the drive you just formatted as XFS;  then reformat the drive you just copied the data from as XFS, and repeat this for another drive;  etc. ... until all of your drives are XFS.   Then copy the data back from the 2nd server.

 

I like that idea. Thank you. After everything is moved would I need to write a new config?

[rednick69]

I would really appreciate some advice on what I'm about to do. My server is running version Unraid 6.3.2 and I have 6 drives in my array all on the reiserfs. Five are 3TB and one is 1TB. My Parity drive was a 3TB but I replaced it with a 6TB to get ready for the upgrade I'm about to ask yall about. I purchased four 6TB drives for my upgrade and conversion. As mentioned, one is already been installed as my parity. 

 

I have read two different WIKI posts that seem to fit what I want to do. One of them gave instructions to convert from RFS to XFS and the other told how to replacing multiple data drives with a single larger drive. The two wiki posts are below.

http://lime-technology.com/wiki/index.php/File_System_Conversion

https://lime-technology.com/wiki/index.php/Replacing_Multiple_Data_Drives_with_a_Single_Larger_Drive

 

With that said, I haven't found instructions on converting and consolidating together. I'm starting to think that what I'm going to have to do is the "Faster Method" in the wiki post "Replacing Multiple Data Drives with a Single Larger Drive."

 

Could I get more of an expert opinion on this topic?

 

[trurl]

55 minutes ago, Harro said:

I like that idea. Thank you. After everything is moved would I need to write a new config?

All New Config does is let you change disk assignments and rebuild parity. Why would you need to do that?

[trurl]

15 minutes ago, rednick69 said:

With that said, I haven't found instructions on converting and consolidating together. I'm starting to think that what I'm going to have to do is the "Faster Method" in the wiki post "Replacing Multiple Data Drives with a Single Larger Drive."

 

Could I get more of an expert opinion on this topic?

The faster method as outlined leaves you without parity protection until after the data is consolidated. Do you have backups?

 

One thing the wiki doesn't mention is formatting the new large disk. unRAID will give you the option to format that disk after adding it when you start the array. Since that method doesn't involve rebuilding any disk, you can format that disk to any filesystem you want.

 

You could also do the "safer method". I mentioned Turbo write earlier in the thread, but I'm not sure how much advantage that would give since there would be reads of the source data mixed in with reads of all disks to calculate parity writes. Of course, since you would be rebuilding this first large disk, it would be the same filesystem as the original disk, so you would eventually have to empty it and reformat.