Hey all!  Sorry I've been scarce lately, but on an out-of-town assignment and life unsettled.

 

I finally got around to starting an upgrade and tried to do something that should be simple, but hit a small snag and hoping someone can help.

 

Background:  With the number of changes I am going to make (including upsizing the parity disk), it makes sense to do as much as I can before changing the array config, then run a final parity check, exchange all my disks, and rebuild parity onto the new disk.  (If something were to go wrong, all of my original disks will be unchanged and I should have at least a fighting chance to recover.)

 

Process: I installed a new 1T drive into the machine (not in the array) and used preclear to do a burn-in test.  All went well.  I then formatted the drive with the command "mkreiserfs -q /dev/sds1".  It also worked fine.  I then copied a bunch of data to the new disk from old disks I plan to remove.  All appeared to work.

 

Problem:  While using the web interface, I noticed that the disk capacity was slightly smaller than usual for a 1T drive.  I looked at two identical disks with cfdisk and their partitions look quite different.  Attached is a screenshot.  The top one is a normal array disk formatted by unraid, the bottom one is the one I did manually. 

 

Can someone tell me how to re-format the disk so that it mimics the unraid format?

Well since heads and cylinder number is reported quite differently between the two disks, this is where the problem lies.

Not the format.

 

BTW neither is realistic.

If you calculate the heads by the cylinders of the second disk, you get a different number than the first disk.

 

Anyway, I would start from BIOS - are both disks on the same controller?

 

Make sure both disks are autodetected (or if not possble manually set) to have the same physical characteristics.

 

 

Well since heads and cylinder number is reported quite differently between the two disks, this is where the problem lies.

Not the format.

 

BTW neither is realistic.

If you calculate the heads by the cylinders of the second disk, you get a different number than the first disk.

 

Anyway, I would start from BIOS - are both disks on the same controller?

 

Make sure both disks are autodetected (or if not possble manually set) to have the same physical characteristics.

 

 

Use

fdisk -u -l /dev/sdX

to get accurate numbers reported in sectors.

 

The drive is on a 2 port PCI-based SATA II card.  It also has another drive attached - the cache drive.  Although that drive was not formatted while attached to that controller, it looks identical (except smaller capacity) to the upper disk in my screenshot (see OP).

 

If you look closely at the lower disk in the screen shot, it is not only the number of heads/cylinders that is different.  The upper disk indicates that the ReiserFS has been used.  The lower does not.  The partition type is "Primary" on the unraid formatted disk and "Pri/Log" on the manually formatted disk.  Finally, there are more cfdisk options in the lower screen in the top vs bottom disk.

 

Looking more closely at the lower shot, it almost appears that the disk is completely unpartitioned.  But I know that it is partitioned and functioning because I copied nearly 1T of data to it and it is showing up in unmenu/mymain as almost full.

 

Doesn't preclear partition the disk as per unRAID requirements?  Or should I have manually partitioned it before formatting it?

 

Here is the results of running the "fdisk" command on the two drives (sdf is an array disk, sds is the new disk):

 

root@Tower:~# fdisk -u -l /dev/sdf

 

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes

1 heads, 63 sectors/track, 31008336 cylinders, total 1953525168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x00000000

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sdf1              63  1953525167  976762552+  83  Linux

Partition 1 does not end on cylinder boundary.

root@Tower:~# fdisk -u -l /dev/sds

 

Disk /dev/sds: 1000.2 GB, 1000204886016 bytes

255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors

Units = sectors of 1 * 512 = 512 bytes

Disk identifier: 0x00000000

 

  Device Boot      Start        End      Blocks  Id  System

/dev/sds1              63  1953525167  976762552+  0  Empty

Partition 1 does not end on cylinder boundary.

I decided to try letting unRAID partition and format the disk.

 

So I used the dd command to write a couple of gigs of binary zeros to the front of the disk, and then booted unRAID with a default config folder.  I added the disk as disk1 (with no parity) and started the array, and then told unRAID to format the disk.

 

After rebooting back with the real config folder.  lIt now looks identical to the other disk (1 head and a bunch of cylinders) in cfdisk.

 

Interestingly, in mymain, the sizes are still slightly different.  Not sure if it is really different or if the method we use to get the size is a little different (I think the latter is more likely), but will know for sure after my reorg and this disk winds up in the array.

 

(Would be nice to have instructions on how to format a disk like unRAID likes.)

 

 

 

I decided to try letting unRAID partition and format the disk.

 

So I used the dd command to write a couple of gigs of binary zeros to the front of the disk, and then booted unRAID with a default config folder.  I added the disk as disk1 (with no parity) and started the array, and then told unRAID to format the disk.

 

After rebooting back with the real config folder.  lIt now looks identical to the other disk (1 head and a bunch of cylinders) in cfdisk.

 

Interestingly, in mymain, the sizes are still slightly different.  Not sure if it is really different or if the method we use to get the size is a little different (I think the latter is more likely), but will know for sure after my reorg and this disk winds up in the array.

 

(Would be nice to have instructions on how to format a disk like unRAID likes.)

Interesting.

The pre_clear script writes zeros to the area of the MBR that describes the cylinder/head/sector geometry.  The question is... how are the zeros interpreted by cfdisk. (as 1 head, or as 255?) Somehow, my guess is 255. 

 

If you go back through the thread where I was originally writing the pre-clear script I found tha sfdisk reported different geometry than fdisk... never bothered with cfdisk... I wonder which one it will agree with.

 

I know people would have been letting me know if the pre-cleared disks were still being cleared by unRAID... since they are not, the partitioning is what is expected. 

 

Joe L.

I have precleared a number of times and then added the disk to unraid.  It works great.  But I believe that unRAID is repartitioning the drive to its own preference when it formats the disk.

I have precleared a number of times and then added the disk to unraid.  It works great.  But I believe that unRAID is repartitioning the drive to its own preference when it formats the disk.

That would not surprise me at all.

 

All I've ever seen it do is

mkreiserfs -q /dev/mdX

Joe L.