reiserfs filesystem is deprecated and scheduled to be removed from the kernel in 2025

[Ockingshay]

Just been checking my log and noticed this. My server is very old and has gone through V4, 5 and now 6 of Unraid and as such 7 disks are REISERFS. I have never dared attempt to replace my file structures as the only way i can think of doing it would be to move all the data off a drive via something like the unbalance plugin, remove the drive from the array, rebuild the array, add it back in and then rebuild the array again. Doing that 7 times on an array with 14tb drives doesn't appeal to me 🤣 and so although the date is 2025, will Limetech work on any sort of array manipulation GUI tools?

 

i would also like to get rid of some of my old 3TB drives and replace with fewer 14TB and cut down on my energy consumption. I even bought a second license key with the idea of just building a new server and copying over 96TB of data, but again that doesn't really appeal to me either!

 

As technology and storage tech improves, it would nice to be able to upgrade the array just like we can with mobos and processors etc.

 

kernel: REISERFS warning:  read_super_block: reiserfs filesystem is deprecated and scheduled to be removed from the kernel in 2025

 

[JonathanM]

4 hours ago, Ockingshay said:

the only way i can think of doing it would be to move all the data off a drive via something like the unbalance plugin, remove the drive from the array, rebuild the array, add it back in and then rebuild the array again.

Half right (maybe just a quarter)

No need to remove drives and rebuild the array, but you do need to copy the data elsewhere, either another data drive in the array, or whatever.

 

There is a whole thread sticky'ed on doing the transition, but in a nutshell, accumulate enough free space to copy the content of your largest ReiserFS drive, format it to a newer format, copy the next victim to the freshly formatted drive, format it, lather, rinse repeat until the last drive is formatted.

 

Notice there was no drive removal, no rebuilding, nothing like that. Everything is done with the drives assigned where they are.

 

Now, since you said...

4 hours ago, Ockingshay said:

i would also like to get rid of some of my old 3TB drives and replace with fewer 14TB

my plan of attack would be, assuming you have at least a single vacant physical drive slot open and your parity drive(s) are currently smaller than 14TB

 

1. Purchase 2ea 14TB drives.

2. Run a noncorrecting parity check, proceed if zero errors and healthy SMART on all existing drives. If either thing is false, my whole strategy changes.

3. Replace the parity drive with one of the 14TB drives, or if your risk tolerance is low, add it as Parity2. After parity is done building, another parity check.

4. If you kept parity1 and added parity2, remove the parity1 drive now. Parity2 has to stay as parity2 to be valid, so you'll just have to deal with the OCD of not having a parity1.

5. Add the second 14TB as a new data drive. Run another parity check to be sure everything is still stable after all the horsing around.

6. Copy the content of as many ReiserFS drives as you wish to the new drive. NOTE. I said COPY. on purpose. 4ea 3TB drives would be good if they were all full, if not, maybe more would fit. I'd shoot to keep 2 or 3TB empty on a 14TB for now.

7. Once you are satisfied the copy went well, verifying by comparing content to whatever your risk tolerance and OCD require, then format any of the source drives that you want to keep in the array, and use those as targets to copy the rest of your ReiserFS drives.

8. When the only ReiserFS drives in the array are slated for removal because their content already was copied to other array drives in the new format, then you can set a new config with only the desired drives and rebuild parity, If you were working with parity2, you can move it to parity1 for the rebuild.

 

Caveat for this method...

When you are copying from drive to drive, there will be duplicate files that the user share file system will hide, because only the first copy of an identically named file in the same share path can be used. That means writes and updates to user shares could be lost, if the changes are made to the source of the copy instead of the destination, and in any case attempting to verify the copy will fail on the changed file. Reads can proceed as normal. If you must continue to write to the array while you have duplicates in place, there are ways to exclude the source disks, but it's easier just to not write if possible.

 

The reason I stressed copying vs. moving is the speed. Moving means a copy followed by a deletion, which is also a write, but on the source disk. Deleting a file from a well used ReiserFS volume is slow to begin with, add in the parity calculation, and the write to the destination disk which is also updating parity in a different sector, means a move can easily be 10X slower than a copy. Much faster to copy the content so only the destination disk and parity disk are writing. Plus you get to verify the copy because the source is still there for secondary checks and recopy if there is an issue, and once you are sure all your data is copied, the format to the new filesystem only takes a minute or two, vs. hours to delete the files one by one.

[Ockingshay]

Hi, just wanted to say thanks for the enlightening response. I'm going to tackle this over the Christmas period when i have some free time.

 

I have a Parity drive that's 14TB and 3 14TB array drives already; the rest are 3TB, being a mixture of XFS and reiserFS.

 

If i understand your steps i will be able to:

copy over the 3TB drive data to the 14TB

format them to XFS or remove from the array

set new config

run a parity   

?

 

That sounds very doable! but i may need to clarify with a few screenshots if that's ok before i press go!

Edited November 15, 2022 by Ockingshay

[JonathanM]

2 minutes ago, Ockingshay said:

Hi, just wanted to say thanks for the enlightening response. I'm going to tackle this over the Christmas period when i have some free time.

 

I have a Parity drive that's 14TB and 3 14TB array drives already; the rest are 3TB, being a mixture of XFS and reiserFS.

 

If i understand your steps i will be able to:

copy over the 3TB drive data to the 14TB

format them to XFS or remove from the array

set new config

run a parity   

?

 

That sounds very doable!

Yes, the only new config and parity build that needs to be done is when you are finished copying data around and wish to remove drives.

 

If you want a more detailed plan of what gets copied where and what order to do things, you should post

drive by drive list of capacity and usage currently

desired end state drive list.

 

for example

 

I now have

14T parity1

14T data1 - 10T XFS

3T data2 - 2.9T XFS

3T data3 - 2.5T ReiserFS

 

I want to end with

14T parity1

14T data1

14T data2 - contents of old data2 and data3

 

 

Putting this type of layout into print allows us to figure out the best way to get from A to B pretty easily with step by step easy to follow instructions that you can check off as you accomplish them.

 

[Ockingshay]

Incredible, thank you 

[Ockingshay]

It's time to give this a go!

 

I have x2 14TB drives arriving today, so i thought i would start moving some data around with what space i have whilst i wait.

 

1) I would like to replace disk 1 (as that's the oldest) with a new 14TB drive, but formatted to XFS.

 

2) Once that is in place i will be able to copy the data over from other 3TB drives, remove them from the system and then add the other 14TB drive. I do not have any further sata ports, so i will need to remove a drive (1) before i can add a new one.

 

What would be the correct procedure to accomplish part 1? In order to remove that drive (1), i will need to copy over the data to make it empty?

 

Many thanks for your help!

 

Part 1) Replace disk 1 with new 14TB drive and formatted in XFS.

 

**I have the unbalance plugin to copy (instead of move as per your suggestion?) and there will be no other activity happening on the server whilst this completes**

 

Edited December 31, 2022 by Ockingshay