SOLVED Unable to GPT format the disk "multipath/disk1"

[nephri]

Hi,

I try to create a pool with some disks (using SAS multipath) and having the following error "Unable to GPT format the disk "multipath/disk1" using the Volume Manager GUI

What i can say:

The disk was formated using sg_format in order to use 512 bytes per sectors.

I have :

• FreeNAS-9.10.1-U2 (f045a8b)
• /dev/da10 is the active device in the multipath config
• /dev/da8 is the passive device in the multipah config
• /dev/multipath/disk1 is the multipath device

The sg_format commands give:

Code:

[root@nas] ~# sg_format -v /dev/da10
	HITACHI   HUS72302CLAR2000  C442   peripheral_type: disk [0x0]
	  PROTECT=1
	  << supports protection information>>
	  Unit serial number: YGH1E3DD
	  LU name: 5000cca01c3af458
	mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=3907029168 [0xe8e088b0]
  Block size=512 [0x200]
	read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00
Read Capacity (10) results:
   Number of logical blocks=3907029168
   Logical block size=512 bytes
No changes made. To format use '--format'. To resize use '--resize'

The diskinfo give:

Code:

[root@nas] ~# diskinfo -v multipath/disk1
multipath/disk1
		520			 # sectorsize
		2000398933520   # mediasize in bytes (1.8T)
		3846921026	  # mediasize in sectors
		0			   # stripesize
		0			   # stripeoffset
		239459		  # Cylinders according to firmware.
		255			 # Heads according to firmware.
		63			  # Sectors according to firmware.
		YGH1E3DD				# Disk ident.
		id1,enc@n5000ccab020379ff/type@0/slot@37/elmdesc@Drive_Slot_#55_5000CCA01C3BE796_	   # Physical path

At this stage, the sg_format give 512 bytes, but the diskinfo give 520 bytes...
Which is accurate ? for continue, the gmultipath give also 520 bytes:

Code:

[root@nas] ~# gmultipath list disk1
Geom name: disk1
Type: MANUAL
Mode: Active/Passive
UUID: (null)
State: OPTIMAL
Providers:
1. Name: multipath/disk1
   Mediasize: 2000398933520 (1.8T)
   Sectorsize: 520
   Mode: r0w0e0
   State: OPTIMAL
Consumers:
1. Name: da10
   Mediasize: 2000398933520 (1.8T)
   Sectorsize: 520
   Mode: r1w1e1
   State: ACTIVE
2. Name: da8
   Mediasize: 2000398933520 (1.8T)
   Sectorsize: 520
   Mode: r1w1e1
   State: PASSIVE

Now, when i try to create the zpool via the GUI, i can show the GPT but no underlying partitions (like freebsd-swap and freebsd-zfs)

Code:

[root@nas] ~# gpart show multipath/disk1
=>		34  3846920959  multipath/disk1  GPT  (1.8T)
		  34  3846920959				   - free -  (1.8T)

the /var/log/messages give me :

Code:

Aug  8 16:09:00 nas notifier: dd: /dev/multipath/disk1: Invalid argument
Aug  8 16:09:00 nas notifier: 1+0 records in
Aug  8 16:09:00 nas notifier: 0+0 records out
Aug  8 16:09:00 nas notifier: 0 bytes transferred in 0.000501 secs (0 bytes/sec)
Aug  8 16:09:00 nas notifier: dd: /dev/multipath/disk1: Invalid argument
Aug  8 16:09:00 nas notifier: 1+0 records in
Aug  8 16:09:00 nas notifier: 0+0 records out
Aug  8 16:09:00 nas notifier: 0 bytes transferred in 0.000507 secs (0 bytes/sec)
Aug  8 16:09:00 nas manage.py: [middleware.exceptions:37] [MiddlewareError: Unable to GPT format the disk "multipath/disk1"]

So, i tried to use dd manually and wasn't able to perform it like

Code:

[root@nas] ~# dd if=/dev/zero of=/dev/multipath/disk1 bs=512 count=2048
dd: /dev/multipath/disk1: Invalid argument
1+0 records in
0+0 records out
0 bytes transferred in 0.000038 secs (0 bytes/sec)

So, my theory is that the disk is always in 520 bytes per sector somewhere... but i used sg_format multiple times like this usage:

Code:

[root@nas] ~# sg_format -v --format --fmtpinfo=0 --pfu=0 --size=512 /dev/da10
	HITACHI   HUS72302CLAR2000  C442   peripheral_type: disk [0x0]
	  PROTECT=1
	  << supports protection information>>
	  Unit serial number: YGH1E3DD
	  LU name: 5000cca01c3af458
	mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=3907029168 [0xe8e088b0]
  Block size=512 [0x200]

A FORMAT will commence in 15 seconds
	ALL data on /dev/da10 will be DESTROYED
		Press control-C to abort

...
	format cdb: 04 18 00 00 00 00

Format has started
Format in progress, 0.99% done
Format in progress, 0.99% done
...
Format in progress, 98.99% done
FORMAT Complete

But it take a very long time (multiple hours) and seems to change nothing...

So i have no more idea for resolve this issue.
If someone have few hints or magical wand ^^

Thanks in advance,
Sébastien.

 

[MatthewSteinhoff]

I'm not even going to pretend I know what I'm talking about but I just had that same problem and did this to beat my drives into a volume group. After trying several different variations it was the addition of '--six' that made magic happen.

Cheers,
Matt

 

[nephri]

Thanks for your reply,

I'm launched this command:

Code:

 sg_format -v --format --fmtpinfo=0 --pfu=0 --size=512 --six /dev/da11

/dev/da11 is another disk (but in the same configuration), it's for avoid to reformat the same disk again and again...

I will see tomorrow what is the result. I'm a bit annoyed with this issue.

 

[nephri]

Unfortunately, it's the same result with the --six option.
After the format command, the drive is always shown with 520 bytes sector size with the diskinfo command.

 

[nephri]

After the sg_format, we must reboot the system and after that all disks are detected with 512 bytes sector size.

Thanks for helps.