I'm in the process of changing the file system from reiserfs to xfs on my main server, and I noticed that most 1.5 and 2TB drives are now showing as MBR-unaligned.

 

I thought I had setup a jumper on them, back when I originally installed them, to have them aligned.  But it's been a long time, and I may be having a brain fart.  Drives are a bunch of WD15EARS, WD15EADS and WD20EARS.  In settings / disk settings I have  selected Default partition format: MBR: 4k-aligned

 

1. Has anything changed between 5.0.5 and 6 beta in how the MBR: 4k-aligned issue is handled?

2. What is the performance hit from having some of the drives "unaligned"?

If the jumper is set, then un-aligned is fine. The alignment won't change unless you clear the disk partition and start over. Since you are erasing the drives anyway, you could always write zeros to the partition table and force unraid to create a new aligned partition if it really bothers you.

 

I'd leave it alone if it were my machine.

If the jumper is set, then un-aligned is fine. The alignment won't change unless you clear the disk partition and start over. Since you are erasing the drives anyway, you could always write zeros to the partition table and force unraid to create a new aligned partition if it really bothers you.

 

I'd leave it alone if it were my machine.

 

Thanks for replying. Just to make sure I got this right, you're saying that formatting the drive reiserfs > xfs should not have changed whether the drives are aligned or not. I am happy to leave this alone if it's a non issue, but I'm wondering why unRAID thinks that some of the drives are not aligned.

 

In backing up and restoring the drives, I'm seeing some seemingly random slow copying to/from some of the drives.  Usually drive to drive speed is above 40-50 MBps, but for a couple of 1.5TB drives was crawling well under 10MBps.

On 9/26/2014 at 11:46 AM, jonathanm said:

If the jumper is set, then un-aligned is fine. The alignment won't change unless you clear the disk partition and start over. Since you are erasing the drives anyway, you could always write zeros to the partition table and force unraid to create a new aligned partition if it really bothers you.

 

I'd leave it alone if it were my machine.

My jumper on the drive apparently wasn't set and I got 63 read errors on the drive after converting it to XFS while the aligned status showed unknown (hoping that was what the read errors were about), so now I'm going to write 0s to the partition table like you recommended with the following steps (please correct me if I'm wrong/missing something):

 

fdisk-l /dev/sdX   -- view the partition table before wiping it out:
dd if=/dev/zero of=/dev/sdX count=1 bs=512 -- write zeros to the current 512k partition table (or bs=4096 if you already had 4k and wanted that gone)
fdisk -l /dev/sdX -- view the partition table after wiping it out (it should say doesn't contain a valid partition table)

 

Partition tables are written into memory upon booting the machine, so a reboot is required for this change to take effect, that is, for your computer to realize that there is no partition table on that hard disk.

After rebooting, start the array, format the drive, and then when you view the drive properties you should see 4K aligned rather than unknown.

 

6 minutes ago, nate1749 said:

My jumper on the drive apparently wasn't set and I got 63 read errors on the drive after converting it to XFS while the aligned status showed unknown (hoping that was what the read errors were about), so now I'm going to write 0s to the partition table like you recommended with the following steps (please correct me if I'm wrong/missing something):

It's been so long since I messed with this, I don't remember exact steps, but it sounds about right.

 

There is no data on this drive slot, correct? Fresh empty XFS filesystem, waiting to be filled as the target of your next ReiserFS disk to be converted?

 

I really can't see why you would get read errors because of partition location, unless the partition was accidentally placed past the physical end of the drive. I'd be more focused on the syslog during the period of time that the read errors occurred, and the smart status of the drive. A long smart test wouldn't be out of line either. 

I'm converting the disk from reiserfs to xfs, and the drive has had the data moved off of it, but it's not a new drive or anything.

 

The read errors may be because of something else; that drive was listed as not connected a week ago, although after a reboot it was detected. It passed short and long smart tests, but I took the opportunity to move all the data off of it in case it failed, although before I did that, I did rebuild the data and did a parity check and it had 0 errors on the disk and everything succeeded.

 

After moving the data off and converting the disk to XFS I ran a parity check and it had 63 errors. Thinking these errors were due to alignment issues, I wrote 0s to the entire drive, formatted it again, the MBR is now aligned 4K, and after a parity check it has 0 errors and still passes a short and long smart test and I do not recall seeing any numbers increasing (e.g. pending sectors to be moved has been at 2 for awhile), so I was hoping the 63 errors were actually related to the alignment because that means it's resolved. As for the drive disappearing, I'm hoping I just need to re-seat the plug as I was inside the server case a month ago, but since the server is physically far away, I can't re-seat it right now to address that.

 

I'm not too worried about it at the moment, but am sorry to hear that the errors probably weren't due partition table alignment.

Edited August 9, 20178 yr by nate1749