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

[RobJ]

@trurl thanks, I guess months ago when I setup disk3 I guess I excluded it from the global settings so nothing would get put on it. I removed the excluded and started up the array and it looks like my files are showing up in the share again and say they are on disk3.

 

I'm glad trurl gave you the help you needed.

 

I just started myself converting drives to XFS, and found a few tricks to help.  I wrote up a modified procedure just above, and I thought you might be interested in the swap procedure I found, in steps 10 through 14, for swapping back the shared files now on your Disk 3, and put them back to Disk 1.  I think it's a safe procedure, but you do need to be careful.  You're basically going to swap the drive assignments for Disk 1 and Disk 3, and their formats too if different, then restart the array.  You should then be able to exclude your Disk 3 again, if you wish.  Perhaps others already knew you could easily do this, but it was news to me.

[trurl]

RobJ, I just read your procedure and think I understand it. The one thing I wanted to double-check is that at no point a New Config is mentioned. I thought I had seen that unRAID would let you swap drive numbers without a New Config, but I had also seen other posts that seemed to indicate New Config was necessary but you could trust parity so it was OK. And I thought I had even seen a recent post that seemed to indicate that unRAID would not let you Start because of the swapped disk assignments.

 

So if I have read you correctly a New Config is NOT needed. I guess the tricky part in all this is to be sure to change the "expected" format to the actual format of the swapped drives. Since I have already converted all my drives to XFS I will not be testing your procedure.

 

Looks like a wiki! And since this is a sticky maybe a link in the first post.

 

[RobJ]

RobJ, I just read your procedure and think I understand it. The one thing I wanted to double-check is that at no point a New Config is mentioned. I thought I had seen that unRAID would let you swap drive numbers without a New Config, but I had also seen other posts that seemed to indicate New Config was necessary but you could trust parity so it was OK. And I thought I had even seen a recent post that seemed to indicate that unRAID would not let you Start because of the swapped disk assignments.

 

So if I have read you correctly a New Config is NOT needed. I guess the tricky part in all this is to be sure to change the "expected" format to the actual format of the swapped drives. Since I have already converted all my drives to XFS I will not be testing your procedure.

 

Looks like a wiki! And since this is a sticky maybe a link in the first post.

I did the New Config the first time, but got to thinking, and tried the shortcut - and it was over and done so fast I couldn't believe it.  But it checked out completely!  And I've repeated it since.  I first tried to figure out how to trick super.dat, to avoid having to reassign all the drives over and over after New Config, but it was going to be more work than it was worth, so I gave up on that idea, then hit on the simple idea above.  But I didn't actually expect it to work!  Especially so quickly!  The changing the formats part I discovered the hard way, but it's easy enough to do.

[JorgeB]

RobJ, I just read your procedure and think I understand it. The one thing I wanted to double-check is that at no point a New Config is mentioned. I thought I had seen that unRAID would let you swap drive numbers without a New Config, but I had also seen other posts that seemed to indicate New Config was necessary but you could trust parity so it was OK. And I thought I had even seen a recent post that seemed to indicate that unRAID would not let you Start because of the swapped disk assignments.

 

So if I have read you correctly a New Config is NOT needed. I guess the tricky part in all this is to be sure to change the "expected" format to the actual format of the swapped drives. Since I have already converted all my drives to XFS I will not be testing your procedure.

 

Looks like a wiki! And since this is a sticky maybe a link in the first post.

I did the New Config the first time, but got to thinking, and tried the shortcut - and it was over and done so fast I couldn't believe it.  But it checked out completely!  And I've repeated it since.  I first tried to figure out how to trick super.dat, to avoid having to reassign all the drives over and over after New Config, but it was going to be more work than it was worth, so I gave up on that idea, then hit on the simple idea above.  But I didn't actually expect it to work!  Especially so quickly!  The changing the formats part I discovered the hard way, but it's easy enough to do.

 

This works since at least v6.0.0, note that you can only change assigned disk slots, i.e., you can trade disks from slot 1 and 2, but if you have slot 4 empty and want to trade a disk from slot 5 it won’t let you, for that you still need a new config.

[JorgeB]

...In addition, from statements online, I understand that rsync ALWAYS checksums every bit of data transferred all the way to its reconstruction at the destination.  That makes the additional lengthy checksum verification almost redundant, so I include that verification only as an option, for the most paranoid.

 

Are you sure this is true? From my online searches and experience I’m don’t think so, I posted somewhere on this thread that one of my disks redballed during the rsync copy, this resulted in a corrupted file, there was no error on the rsync operation.

 

You would also expect to see some read activity after copying a file if rsynch was verifying it and it does not happen.

 

But I do believe you don’t need to run checksums after copying unless a disk error occurs.

 

 

 

Edit: I believe this below better explains it and why it’s only important to run checksums in case of a disk write error.

 

rsync always uses checksums to verify that a file was transferred correctly. If the remote file already exists, rsync may skip updating the file if the modification time and size match the source file, but if rsync decides that data need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overheard of a byte-level comparison over the network.

 

Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.

 

As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.

 

. While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.

 

Source: the man page and eyeballing the rsync source code to verify.

 

http://unix.stackexchange.com/questions/30970/does-rsync-verify-files-copied-between-two-local-drives

 

 

[RobJ]

This works since at least v6.0.0,

I didn't know that.  I'm surprised that more users haven't caught on to this, because it saves a lot of time not having to New Config and reassign everything, and you don't have to worry about getting the Parity drive right.

 

note that you can only change assigned disk slots, i.e., you can trade disks from slot 1 and 2, but if you have slot 4 empty and want to trade a disk from slot 5 it won’t let you, for that you still need a new config.

That's really odd, I wonder why it's different.  Slot assignment is an arbitrary thing, a software thing, so it shouldn't matter.

[JorgeB]

That's really odd, I wonder why it's different.  Slot assignment is an arbitrary thing, a software thing, so it shouldn't matter.

 

Agree, should also allow it, maybe LT didn’t anticipate that situation, should be easy to add.

[RobJ]

...In addition, from statements online, I understand that rsync ALWAYS checksums every bit of data transferred all the way to its reconstruction at the destination.  That makes the additional lengthy checksum verification almost redundant, so I include that verification only as an option, for the most paranoid.

 

Are you sure this is true? From my online searches and experience I’m don’t think so, I posted somewhere on this thread that one of my disks redballed during the rsync copy, this resulted in a corrupted file, there was no error on the rsync operation.

 

You would also expect to see some read activity after copying a file if rsynch was verifying it and it does not happen.

 

But I do believe you don’t need to run checksums after copying unless a disk error occurs.

 

 

 

Edit: I believe this below better explains it and why it’s only important to run checksums in case of a disk write error.

 

rsync always uses checksums to verify that a file was transferred correctly. If the remote file already exists, rsync may skip updating the file if the modification time and size match the source file, but if rsync decides that data need to be transferred, checksums are always used on the data transferred between the sending and receiving rsync processes. This verifies that the data received are the same as the data sent with high probability, without the heavy overheard of a byte-level comparison over the network.

 

Once the file data are received, rsync writes the data to the file and trusts that if the kernel indicates a successful write, the data were written without corruption to disk. rsync does not reread the data and compare against the known checksum as an additional check.

 

As for the verification itself, for protocol 30 and beyond (first supported in 3.0.0), rsync uses MD5. For older protocols, the checksum used is MD4.

 

. While long considered obsolete for secure cryptographic hashes, MD5 and MD4 remain adequate for checking file corruption.

 

Source: the man page and eyeballing the rsync source code to verify.

 

http://unix.stackexchange.com/questions/30970/does-rsync-verify-files-copied-between-two-local-drives

That's similar to what I found.

 

Actual read activity is highly unlikely because of caching, both in the kernel and on the drive itself.  Which is why I added the 'almost' in my "almost redundant" comment, because it is not truly checksumming it end to end, all caches flushed, read after write (which would require a rotation on spinners, noticeably slower).  However we can assume it's checksummed to the final write, then the busses have their own CRC and parity checking, then it's CRC checked over the SATA link, and then the drive adds ECC info to the write, all of which 'almost' completely guarantees its safety.  Would you agree with that?

 

I've actually been performing the extra verification, old habits and hard experience.  But I agree that logically it no longer makes sense, and most users should not bother.  It's *extremely* unlikely to help.

[JorgeB]

Would you agree with that?

 

Completely agree, I never checked mine when I did the conversion (except the redballed disk), have run some checks after and never found any corruption.

 

I believe it should be checked if you suspect a disk, e.g., destination disk x reallocated some sectors during a copy, or if you get a redball, in my case I was using the --remove-source-files switch, so when I woke up I had a redballed disk but all data was deleted from source, so after rebuilding the disk I verified checksums (using corz at the time), and had one corrupted file.

 

[JorgeB]

This works since at least v6.0.0,

I didn't know that.  I'm surprised that more users haven't caught on to this, because it saves a lot of time not having to New Config and reassign everything, and you don't have to worry about getting the Parity drive right.

 

Did some quick tests, and can confirm that it works from at least v5beta12a, you can change the order of all disks, except parity naturally, it could be even better if LT allowed to trade an empty slot, this could be useful for when users remove a disk, very nice find Rob. 

[JorgeB]

I did the New Config the first time, but got to thinking, and tried the shortcut - and it was over and done so fast I couldn't believe it.  But it checked out completely!  And I've repeated it since.  I first tried to figure out how to trick super.dat, to avoid having to reassign all the drives over and over after New Config, but it was going to be more work than it was worth, so I gave up on that idea, then hit on the simple idea above.  But I didn't actually expect it to work!  Especially so quickly!  The changing the formats part I discovered the hard way, but it's easy enough to do.

 

This shortcut stopped working on v6.2beta, people using this method to convert to XFS better finish before upgrading.

[Van Helsing]

Will rsync pickup where it left off if Windows restarted during screen session? What about the temporary file that was left behind will that be deleted?

[itimpi]

Will rsync pickup where it left off if Windows restarted during screen session? What about the temporary file that was left behind will that be deleted?

Not quite sure what you are asking?    If you were using screen then rsync would have continued running and you can reconnect to its screen session.    If you are asking whether rsync carries on from where it was if the rsync is aborted if you use the same rsync command then my experience is that it does s with the file that was being copied at the time of the abort.  However the temporary file that was being created at the time of the abort is left behind.

[Van Helsing]

I started the rsync operation as in RobJ's tutorial from a windows telnet session. Went to bed and when I awoke to check the operation, found that windows had performed an update and rebooted, terminating the telnet session and as far as I can tell the copy operation as well because the new drive was not even close to having the same amount of data that the copied drive had. I really don't know anything about Linux, but from my research it seemed to indicate that rsync will continue to copy but depending on what version of Linux you have, the partial hidden file my or may not be deleted. Since I'm trying to make an exact copy for replacing the reiserfs disk with the xfs disk I'm concerned about what effect the partial file would have and if there is some way I can determine what the name of the file is and delete it if it indeed exists and wasn't already deleted. I've inputed the same exact rsync command and it seems to be picking up where it left off but I have no idea if the partial file was deleted.

[RobJ]

I started the rsync operation as in RobJ's tutorial from a windows telnet session. Went to bed and when I awoke to check the operation, found that windows had performed an update and rebooted, terminating the telnet session and as far as I can tell the copy operation as well because the new drive was not even close to having the same amount of data that the copied drive had. I really don't know anything about Linux, but from my research it seemed to indicate that rsync will continue to copy but depending on what version of Linux you have, the partial hidden file my or may not be deleted. Since I'm trying to make an exact copy for replacing the reiserfs disk with the xfs disk I'm concerned about what effect the partial file would have and if there is some way I can determine what the name of the file is and delete it if it indeed exists and wasn't already deleted. I've inputed the same exact rsync command and it seems to be picking up where it left off but I have no idea if the partial file was deleted.

I don't know about whether there's a temporary file or what it's named (I've never had one), but it should have a current timestamp, as the last thing written.  I'd use a file manager and view the destination folder(s), sort by date modified with newest on top, and look for the most recent file.

[gravymaker]

 

Procedure to convert drives to XFS format

================================

System assumptions before you begin:

<snip>

 

I followed RobJ's excellent instructions and converted 12 disks, including the cache drive, from RFS to XFS in about a week.  Great tips to use "screen" and go slow and triple check each key step along the way.

 

Thanks to everyone in this thread for great ideas, and to RobJ for the steps.

[Van Helsing]

I started the rsync operation as in RobJ's tutorial from a windows telnet session. Went to bed and when I awoke to check the operation, found that windows had performed an update and rebooted, terminating the telnet session and as far as I can tell the copy operation as well because the new drive was not even close to having the same amount of data that the copied drive had. I really don't know anything about Linux, but from my research it seemed to indicate that rsync will continue to copy but depending on what version of Linux you have, the partial hidden file my or may not be deleted. Since I'm trying to make an exact copy for replacing the reiserfs disk with the xfs disk I'm concerned about what effect the partial file would have and if there is some way I can determine what the name of the file is and delete it if it indeed exists and wasn't already deleted. I've inputed the same exact rsync command and it seems to be picking up where it left off but I have no idea if the partial file was deleted.

I don't know about whether there's a temporary file or what it's named (I've never had one), but it should have a current timestamp, as the last thing written.  I'd use a file manager and view the destination folder(s), sort by date modified with newest on top, and look for the most recent file.

 

UPDATE:

After what happened above I started a new telnet session, reissued the rsync copy command exactly as before.

After it completed I started a rsync checksum verification, which took as long to copy all the files, so yes lengthy with no apparent errors or recopied files.

Did a disk to disk file and folder comparison with Ultracompare and it was an exact duplicate.

Ran a parity sync with no errors.

 

So even after the interrupted copy procedure, everything came out A-OK as far as I can tell and feel confident that this is a very secure procedure. As far as I can tell with my limited knowledge of Linux the -a (archive command) saves the interrupted file and then picks up where it left off when reissued. Thanks for all the help.

[Van Helsing]

Also a couple of noob questions just to clarify a few minor points.

 

1. Does the parity disk have a file system and is there any need to change it, because none is listed?

 

2. In the final step when you stop the system and change the copied RFS disk to XFS and then format it, is the parity still intact or should another parity sync be done?

[garycase]

... 1. Does the parity disk have a file system and is there any need to change it, because none is listed?

 

No, the parity disk does not have a file system.

 

 

... 2. In the final step when you stop the system and change the copied RFS disk to XFS and then format it, is the parity still intact or should another parity sync be done?

 

Parity is maintained, so no sync is needed.

 

[Harblar]

Ok, so I'm starting the process of switching over to XFS from reiserfs.  I moved all the data off from a 4tb drive to another I already had formatted as xfs.  I then stopped the array, changed the (now empty) drive to xfs, restarted, and then started the formatting process. I just came back to check on it and the drive is formatted but currently 10% of the way through a Rebuild. It was an Empty Drive, so there technically shouldn't be anything to rebuild after the format, correct?

 

Do I let it finish, or is it ok to cancel it and get started on the next drive in line?

[trurl]

Empty and/or format has absolutely nothing to do with rebuild. The only way rebuild should have occurred is if the drive was missing or replaced. Can you tell us more about what you have done?

[Harblar]

Yeah, that's what I thought.

 

I transferred all the files on the drive, disk 7, to disk 8.

 

I then stopped the array.

 

Not exactly remembering how the format process went, I changed disk 7 to unassigned and restarted the array.

 

I realized that wasn't right so I stopped the array again and reassigned disk 7 as it was before.

 

This time, before starting the array, I clicked on disk 7 and changed its file system to XFS.

 

I restarted the array and then had the option to format disk 7.

 

My guess is, at this point, that I triggered the rebuild when I unassigned/reassigned disk 7.  That being the case should I let it go, or is it ok to just stop it and continue on?

[JorgeB]

Not exactly remembering how the format process went, I changed disk 7 to unassigned and restarted the array.

 

This is what caused the rebuild, you could stop it, do a new config and a parity check, but it's easier and safer to just let the rebuild finish.

[garycase]

Note that when the rebuild finishes, disk 7 will be exactly how it was before -- including the formatting (which will still be Reiser).    At that point you can stop the array; change the format for disk 7 to XFS (do NOT unassign it); and then when you Start the array it will format the drive.

[Harblar]

Note that when the rebuild finishes, disk 7 will be exactly how it was before -- including the formatting (which will still be Reiser).    At that point you can stop the array; change the format for disk 7 to XFS (do NOT unassign it); and then when you Start the array it will format the drive.