I agree that is going to be a real task considering I need to do this with 5 reiserfs drives. Why even though it's been formatted, the partition deleted, and re-added does unRAID still insist on it being a reiserfs drive?

Screenshot of main GUI?

I've now started pre-clearing the drive as nothing else I could do seemed to show it as XFS. It's an empty drive. Even removing the partition and formatting to XFS through the unassigned devices plugin, when I add it back to the array, it says ReiserFS. Which is odd, because when I stop the array, and un-assign the drive, it shows in unassigned devices as XFS. I have refreshed my browser cache to be sure it wasn't just showing that way, and when this drive is added back it displays as ReiserFS. I'm all for moving all my drives to XFS, as it seems this is the root of my problem, is there an easier way than doing a new config for each drive?

Mike, you ever get to the bottom of what was causing all those ata07 issues in the bit of your log I posted?

 

 

 

Sent from my LG-H815 using Tapatalk

 

 

No but I suspect that the drive is failing, the SATA port or the backplane. I have a spare pre-cleared 4TB drive sitting here, and once I had successfully migrated all of this data from RFS to XFS, I was going to do some testing to see if it is the drive or the port. Something there is definitely failing, but I think it's entirely unrelated to the current issue.

Quick question ... Is there a reason why you have the cache disk formatted as BTRFS?

 

Rather than converting all of your ReiserFS data disks to XFS, maybe a quicker solution is to convert your cache disk to XFS.  This of course assumes that mover/rsync doesn't have a problem when copying between XFS and ReiserFS.

No but I suspect that the drive is failing, the SATA port or the backplane. I have a spare pre-cleared 4TB drive sitting here, and once I had successfully migrated all of this data from RFS to XFS, I was going to do some testing to see if it is the drive or the port. Something there is definitely failing, but I think it's entirely unrelated to the current issue.

Maybe so, but I personally would sort out a hardware issue like that as a priority, otherwise your parity may not save your ass if another drive goes down.

 

I certainly wouldn't start shifting tons of data until that is fixed.

Sent from my LG-H815 using Tapatalk

 

I had just thought that BTRFS was the "go to" for the cache drive, although I'd read some people doing it with XFS. I don't believe I chose this specifically, as much as unRAID defaulted to it when I first added a cache drive and started using docker.

some testing indicates there should be no issue between btrfs and reiserfs - only the attribules and acls... which makes me wonder why are there attributes in the first place.

Is it something with the apps? (Don't use them - just plain jane torrenting on my cache drive)

Also testing to rsync between the two shows the files properly moved.  but i guess there might be something still with the move binary - whatever it is.

In retrospect you are probably correct CHBMB, so if I can simply get this one single drive to show back up as XFS correctly, I can at least very quickly tell where that problem with disk7 lies. I'll swap sata cables on the backplane and if unraid sees issues with the same drive I'll know it's the drive. If I swap ports and it still sees disk7 as bad, I'll swap out the backplane and or motherboard. Will pre-clearing drive1 and trying to add it back this way make any difference? Because no matter what I seemed to do, it just showed back up as RFS. Making a new config for every drive would be extremely tedious, especially doing this 5x.

Also ken-ji, I had no issues with this happening with 6.1.9 between BTRFS and RFS. Everything worked as it should. Since upgrading to 6.2 is when this problem began for me.

have you checked in settings | disks (?) for the default array disk format?

 

Also ken-ji, I had no issues with this happening with 6.1.9 between BTRFS and RFS. Everything worked as it should. Since upgrading to 6.2 is when this problem began for me.

The mover was modified in 6.2 - I just don't quite remember what changed and am too lazy right now to check.

When I've deleted the partition through unassigned devices (having to type "Yes") and then click format, it says XFS, and I also have to type "Yes" for that. But when I add it back in, it still shows as resierfs. Even stopping the array and un assigning it, shows in unassigned devices as xfs.

That is the Disk Settings page, which is the settings for all disks. Where you need to go is the Settings page for the specific disk by clicking on the disk itself in Main.

 

Also, this might be useful:

 

... the XFS conversion post (found here)....

thanks trurl, I had been all over the forums and I missed this somehow. So to achieve getting this disk back into the disk 1 position as XFS, I must preclear it, assign it to a new slot, and exclude this disk from user shares. Then stop the array and switch this disk back to the disk1 position? Would that be the correct way to do this? I'm reading your post, and I have another blank drive, I just don't have another SATA port so I'm trying to follow half way along as my scenario is a bit different.

I've now started pre-clearing the drive as nothing else I could do seemed to show it as XFS. It's an empty drive. Even removing the partition and formatting to XFS through the unassigned devices plugin, when I add it back to the array, it says ReiserFS. Which is odd, because when I stop the array, and un-assign the drive, it shows in unassigned devices as XFS. I have refreshed my browser cache to be sure it wasn't just showing that way, and when this drive is added back it displays as ReiserFS.

From your screenshot, it would appear that you are confusing the physical disk which is currently formatted as XFS with the emulated disk1 which is still formatted ReiserFS. As long as the emulated disk is still ReiserFS, every time you put a drive back in that slot, unraid will dutifully erase what is on the physical disk and put the emulated format back on, just like what happens when a disk fails. In order to change the format, you have to stop the array, change the format for the disk1 slot by clicking on disk1, and then starting the array. It will then say that disk1 is unmountable, and offer to format it. When you click the checkbox to accept it, it will proceed to format the disk in the type you set for that disk.

 

This behavior will happen as long as parity remains valid. If you set a new configuration, you can force unraid to use what is on the physical disk and rebuild parity from all your physical disks, whatever format they happen to be.

So I have transferred the entire contents of drive1, one of my reiserfs drives, to another drive. I have tried stopping the array, removing the partition on disk1, formatting to xfs, and no matter what I do, it keeps appearing in the MAIN tab as reiserfs. Even when I stop the array, unassign the disk, it shows in unassigned devices as xfs, but when I try to add it back to the array, it shows as resierfs. So I have one empty disk, disk1. What is the correct method to format it to xfs and add it back into the array as a new, blank disk with nothing on it?

this sounds like you are trying to change the format outside the unRAID GUI?   

 

If you stop the array then you should be able to change the format to XFS.  On restarting the array the disk should show as unmountable and the option to format unmountable disks offered.  It should now be possible to format it to XFS.

 

If you want to reformat a disk that is already in the specified format then you should do the above steps twice, the first time to format it to a different format, and then the second time time to format it to the desired one.

 

The above process should keep parity valid throughout the process (whereas doing it another way is likely to invalidate parity.

 

There have been reports of remnants of previous file systems causing problems, and the fix for this seems to be to use pre-clear (only the write phase being necessary if you trust the drive) to remove any remnants of previous portioning and/or file system format.

I have just tested here to see if there is any problems with btrfs to reiserfs. The mover moves the files from the cache drive to the reiserfs array disk without problems.

I tested with copying a file to the share first. Mover finished, and moved the file from cache to array disk.

Then I installed sabnzbd and downloaded a file with the same result as above.

 

So I would say it's something local with your setup that is the problem. For me it doesn't look like an unraid problem.

As already mentioned before, I would check out your disk problems before doing the reformat to xfs.

I don't think it's just me saarg, as there are reports of similar within the previous mentioned unbalance post. I've successfully gotten my drive1 to XFS, but however I did it forced a parity check. Moving forward, attached is my MAIN screenshot. How can I move disk2's contents to disk1, and change it's format to XFS without forcing a parity check. I really tried to follow the instructions, but the way I did it still forced a parity check. Any way some gracious person could give me a step by step to move disk2's contents to disk1 and change it's format to XFS without forcing a parity check?

 

Thanks you SO much in advance for all of the help. Also, with the drive with the most free space (disk1) being XFS, all of my sonarr and couchpotato problems have disappeared and things seem to be smooth sailing.

Once you empty a drive you can just stop the array, click on the drive to go to its settings page, and change its format. When you start unRAID will format it, and parity will be updated when the new filesystem is written so parity will remain in sync.

I feel silly for it being that easy. So the drive just needs to be empty, and then changing it within the disk settings and letting unRAID format it is sufficient? Thanks again so much.

I feel silly for it being that easy. So the drive just needs to be empty, and then changing it within the disk settings and letting unRAID format it is sufficient? Thanks again so much.

Actually, unRAID won't care if the drive is empty or not, but you might. If you change the format unRAID will format it regardless of its contents. We often have people who somehow think they need to format a drive when they are trying to rebuild it. NOT!

So the drive just needs to be empty, and then changing it within the disk settings and letting unRAID format it is sufficient? Thanks again so much.

The migration process is faster if you DON'T empty the drive. COPY, not move, the entire contents of your next ReiserFS disk to the empty XFS disk, and when you are satisfied the two disks have identical content, format the ReiserFS disk using the procedure given. It's much faster to copy instead of move, given that each deletion is also a write that needs to be reflected on the parity drive. When you move files from one drive to another, the deletion from the source drive takes a not insignificant amount of time. Copy only reads the source disk and writes destination and parity, so much less seeking and thrashing.

I was using the rsync command referenced in RobJ's post. Is this not the most correct way to do this?

I was using the rsync command referenced in RobJ's post. Is this not the most correct way to do this?

Sure, that rsync command is probably the best way to copy the data from one drive to another. Rob also references using a second rsync run to confirm the drives are identical before you format them. I was referencing your statement that you wanted the drive empty before reformatting, and reinforcing trurl's statement that an empty drive wasn't needed. Deleting the files to empty the drive is time needlessly wasted.

Got it. I really appreciate all the help. I'm slowly getting these drives converted. One thing I am going to run into though....if you see the above picture of my MAIN tab, I am going to be left in a situation where I will have just under 3TB of things to copy, but I'll have to split them among multiple drives to accomplish copying my 1st 3TB drive. Can I still use rsync just on certain directories or what would be the best plan of action? I still also have a 4TB WD Red sitting here, pre-cleared, just no more SATA ports to plug any more drives into. What would be my best move? Just remove one of the 3TB drives, add the 4TB and let parity rebuild the data? I plan on purchasing another 8 port SATA PCI card in the near future as the new case I have allows space for 20 drives, but atm, I am limited to 12. Any more guidance would be greatly appreciated.

 

Also, CHBMB, the disk7 errors I was receiving were due to a loose backplane connection. I removed the drive from the RAID cage and just hooked it up normally, rebooted and the errors vanished. I then re-inserted the disk, using a good bit of force to push it into the cage, and the errors are now gone.