Confused about converting array drives to XFS


Go to solution Solved by JonathanM,

Recommended Posts

I recently was recommended to convert the filesystem on all array drives to XFS. From reiserfs. Not sure about the benefits but I will take your word for it.

 

I have emptied out one array disk by copying its contents to other array disks. The disk usage now shows at 33MB despite no files residing on it.

 

I am confused as to how to proceed from here. I can see a lot of options on the guide for this and am simply unsure which one is for me.

 

I have turned off docker. I am ok with rebooting in safe mode to turn off plugins. Parity disk is in place and parity is valid. Based on something I read, I have removed all user share restrictions and set all shares to the defaults of including all disks and excluding none.

 

Please guide for the easiest path here onwards.

Link to comment

What you are seeing is the disk space require for the file system.  See here for an excellent explanation of why:

 

    https://forums.unraid.net/topic/125592-empty-hard-drive-shows-gigabytes-of-used-space/#comment-1145274

 

I did the conversion on both my servers from reiserfs to XFS and I used the Mirroring Procedure as described in this WIKI section:

 

    https://wiki.unraid.net/File_System_Conversion#Mirroring_procedure_to_convert_drives

 

I will say it is a daunting task.  What I did was to make up a table  of listing each step for the conversion for each disk with the variable names for each step.  I checked off each step as I went along.  It also takes time.  (I seem to recall it took about 2-3 hours per TB to move the data from the disk with the old file system to the disk with the new file system.)   I also used the last four digits of the serial number of the disk to keep track of them.  

 

I also had a printed copy of the instructions rather than trying to work from the monitor display.  (I find (personally) that having a printed copy, I can highlight important points and it just helps me to be more mentally organized.  Of course, I spend the first sixty years of my life having only printed copies of instructions....  😏 🙄  )

  • Like 1
Link to comment

One more thing.  Make sure that you understand that the 'shell' program that you use in the terminal session has editing features built into it.  Pressing the <arrow> keys will move you up and down previously entered commands.  The <right-arrow> and <left-arrow> keys will move back and forth in the line to allow editing of a previously entered command.  This makes the grunt work a lot easier!

Link to comment
  • 2 weeks later...

I'm still confused. So like I mentioned, I have one disk which I have emptied. Its showing 33MB since many days so obviusly nothing is being written to it. I have disabled docker.

 

Can I now do the following:

 

1. Stop the array

2. un assign the drive I emptied out

3. start the array (data will be preserved but no parity until i add the missing drive or replacement drive)

4. format the drive i just un assigned from reiserfs to xfs (I assume this shoiuld be a one click process using unassigned devices)

5. after the format is done, assign this drive to the missing data drive slot.

6. Start the array and let parity rebuild.

 

Is this ok?

 

Link to comment
  • Solution
16 minutes ago, extremeaudio said:

Is this ok?

No, totally wrong.

 

Format is part of parity, so if you remove a drive and format it, Unraid will rebuild it with whatever format was on it prior to removal. If you set a new config and rebuild parity that would work, but you are unnecessarily risking a drive failure.

 

Simply click on the target drive in the main GUI with the array stopped, change the file system type to XFS, and when you start the array it should offer to format that drive, and ONLY that drive. Make sure the target drive is the only one in the list to be formatted.

  • Like 1
Link to comment

No need to rebuild anything, just reformat the disk with the array started and parity will be updated. Format only writes a small amount of metadata to represent an empty filesystem, and all writes in the array update parity.

 

This is what often trips up people who have an unmountable filesystem. They format the disk then try to rebuild from parity, but parity has already been updated by the format.

  • Like 1
Link to comment

I posted a link to the procedure that most people have used.  It is tried-and-true.   You have to have an empty disk (of files that you want to preserve) to start with.  (This could be a new disk if you have a spare drive slot or an array drive that you have moved all the files off of.)  There is no shortcut to this step! 

 

I know that it is complex and seems confusing when you read it.  As I said, print the procedure out.  Then sit down and actually set up a table of the steps that are required.  Then note the 'disk#' and actual serial  numbers (I use only the last four digits) of the first two drives that you are going be using.  Write these into the table so you know exactly what parameter(s) to enter in the command and.  When you understand the steps and start to do it, check off each step as you proceed.  A bit of organization will help prevent you from making a mistake...

 

The big advantage to this procedure is that it maintains parity throughout the entire process! 

 

Postnote:  If you don't have a spare slot, you could set a drive up outside of the case and run a power cable and data cable out to it.  If you have to leave the case open to do this, you should setup a large room fan (12" to 20") and use that to maintain airflow over the hard disks.

  • Like 1
Link to comment

Also very important. Do not move files via /shares to /disks or /disks to /shares 

When I did mine I copied files from /disk to /disk

If you mix /shares and /disks you might end up in some kind of loop or cause corruption. 

 

I think I did mine a long time ago using rsync and Unbalance plugin which took a lot of the guess work out of it. Made me feel really lazy. Lol

 

Also in settings or is it tools I don't remember. Don't forget to set the default disk formatting for future drives. I'm guessing you have it currently set to btfrs you should change it to xfs unless you don't want future drives to be xfs. 

 

 

  • Like 1
  • Upvote 1
Link to comment
  • 1 year later...

I'm trying to digest everything that needs to take place here.  It seems best (or maybe required) to disable all DOCKERS while going through this process as well as any VMs.  But I don't see any mention of MOVER.  Do you need to disable MOVER as well for some reason before starting a process like this?

Link to comment
1 hour ago, JP said:

I'm trying to digest everything that needs to take place here.  It seems best (or maybe required) to disable all DOCKERS while going through this process as well as any VMs.  But I don't see any mention of MOVER.  Do you need to disable MOVER as well for some reason before starting a process like this?

When I did the conversion (several years ago now), I did not have any Dockers running that would have affected the array. 

 

About mover,  when I did the conversion, I basically took the server off-line as far as doing anything to it so whether it ran or not was immaterial. 

 

I would guess that you could continue to add files to the  server using a cache while doing the copying.  When mover ran, it would simply write the files to the array.  What you would have to do is, after rsync finished  copying of the files to the new disk is to immediately rerun the same command again.  Because of the -a switch, rsync would only copy any new files on the source disk (and not on the destination disk) that were written there by the mover.  So it will only take the time required to move those files.  Of course, you would have to make sure that mover was not running at this point.  (You will have to read in the documentation for rsync what the --a switch does about an updated file. I think it does copy updated files but I am not sure for certain..)

Edited by Frank1940
Link to comment
50 minutes ago, Frank1940 said:

When I did the conversion (several years ago now), I did not have any Dockers running that would have affected the array. 

 

About mover,  when I did the conversion, I basically took the server off-line as far as doing anything to it so whether it ran or not was immaterial. 

 

I would guess that you could continue to add files to the  server using a cache while doing the copying.  When mover ran, it would simply write the files to the array.  What you would have to do is, after rsync finished  copying of the files to the new disk is to immediately rerun the same command again.  Because of the -a switch, rsync would only copy any new files on the source disk (and not on the destination disk) that were written there by the mover.  So it will only take the time required to move those files.  Of course, you would have to make sure that mover was not running at this point.  (You will have to read in the documentation for rsync what the --a switch does about an updated file. I think it does copy updated files but I am not sure for certain..)

 

Thanks.  Some of this is a little over my head, which tells me I just need to learn some more.  Reading through this topic in a number of posts, they refer to some documentation in the WIKI, however, the links always lead to the home page of the WIKI.  I can only assume that topic has been moved or something like that and that is why it defaults to the home page.  BUT when I look in the WIKI, it does have instructions around how to complete the file conversion, but they are really high-level.  Things like rsync aren't even mentioned.  Is there possibly a more detailed WIKI entry I'm missing somewhere?

Edited by JP
typo
Link to comment
1 hour ago, JP said:

BUT when I look in the WIKI, it does have instructions around how to complete the file conversion, but they are really high-level.  Things like rsync aren't even mentioned.  Is there possibly a more detailed WIKI entry I'm missing somewhere?

Edited 1 hour ago by JP

 

Read the section: 

 

https://legacy.wiki.unraid.net/index.php/File_System_Conversion#Methods_for_drive_and_array_conversion

 

Then I suggest using this method:

 

https://legacy.wiki.unraid.net/File_System_Conversion#Mirroring_procedure_to_convert_drives

 

IT is a bit confusing (at least, I found it so),  I recommend printing out a physical copy and set a step-by-step table for converting the first disk with the proper variable for your server setup and check off each step as you go.  (The time required is lengthy for many of the steps and checking them will help prevent getting lost.)

  • Like 1
Link to comment
22 hours ago, Frank1940 said:

 

Read the section: 

 

https://legacy.wiki.unraid.net/index.php/File_System_Conversion#Methods_for_drive_and_array_conversion

 

Then I suggest using this method:

 

https://legacy.wiki.unraid.net/File_System_Conversion#Mirroring_procedure_to_convert_drives

 

IT is a bit confusing (at least, I found it so),  I recommend printing out a physical copy and set a step-by-step table for converting the first disk with the proper variable for your server setup and check off each step as you go.  (The time required is lengthy for many of the steps and checking them will help prevent getting lost.)

 

Geesh...thanks for this.  I was way off when it came to how I thought this process was supposed to work.  I see now that you copy data from the RFS Data Drive to your XFS Swap Drive and then after the copy sort of "trick" the OS into thinking the XFS Swap Drive (now having identical data) is now the Data Drive and the RFS Data Drive is now your swap drive.

 

Great advice on writing all this out first.  I don't have a ton of drives, but I can see how it could get very confusing.  Thanks again.   

Link to comment
43 minutes ago, JP said:

but I can see how it could get very confusing.  Thanks again.   

 

One more thing, and I can't remember if this mentioned.  You must also look at the size of the drives and the amount of data on each drive so that the data from the next drive in the conversion sequence will fit on the drive that it is being copied to.  Often it is not a problem but if you have a fair number of drives of various sizes, it can become an issue...

  • Like 1
Link to comment
On 10/10/2023 at 2:11 PM, Frank1940 said:

 

One more thing, and I can't remember if this mentioned.  You must also look at the size of the drives and the amount of data on each drive so that the data from the next drive in the conversion sequence will fit on the drive that it is being copied to.  Often it is not a problem but if you have a fair number of drives of various sizes, it can become an issue...

 

Thanks.  I only have 3 4TB drives that are RFS so I'm probably good there.  My swap drive will be 4TB, which is essentially my backup drive that I always have sitting off to the side in the event a drive fails.  

 

One question though, once I complete this full process, I'll then have one extra formatted (blank) 4TB drive sitting in the array.  I could follow the steps to remove it from the array and then take it out of the server.  This would essentially put me in the same exact spot I was before I started this process. 

 

However, and what might be better (and I suspect others probably do), is keep the drive in the server, but remove it from the array and have it "at the ready" in the event a drive does fail.  This would just save me the time from having to install the drive again, should a drive fail in the future. 

 

My question is, what is the best way to accomplish this and where is the best place to put the extra backup drive?  I would not want it drawing power from the power supply and I do have UNASSIGNED DEVICES installed.  Would it be best to remove it from the array, somehow move it to UNASSIGNED DEVICES, and then spin it down so it doesn't draw any power?  Thanks again. 

Link to comment

IF you want it as a 'hot spare' you will have to remove it from the array and rebuilt parity.  This is because that disk will still be part of the parity calculation even though it does have any accessible data on it.  (When you move a file off a disk, the OS will simply update the file table to indicate that that file been abandoned and the space is available to store another file.  However, all the 1's and 0's for that file are still there on the disk and they are a part of the parity calculation.)

 

If you attempt to un-assign that disk to reassign it to the slot of the failed disk, you will have two disks in an error state--- the original disk that failed and 'hot spare' disk that will now be missing from it assigned slot.

Edited by Frank1940
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.