Disks in read-only mode

[rslocalhost]

I've two new disks I'm trying to burn-in/test before putting them in production. My FreeNAS server has multiple hot swap bays. (This is a 4U system from ix systems.) I put the two new drives into the empty bays. System sees them and gives them da21/da0 and da42/da43 dev numbers (dual channel system, so each drive has two da's). But when I went to do a badblocks test,

Code:

badblocks -svw -b 4096 /dev/da0

I get Operation not permitted while trying to open /dev/da__. I get this with all the numbers.

If I remove the w from the badblocks command, making the command read-only, it works just fine. Smart tests also work. So it appears FreeNAS (FreeNAS-9.10.2-U6) is making the disks read-only for some reason. These are new disks, not part of any pool, and they should be blank.

dd commands also give the same error.

I did find another thread with almost the same problem (https://forums.freenas.org/index.php?threads/badblocks-testing-not-working-properly.49854/), but no solution. Another thread mentioned running sysctl kern.geom.debugflags=0x10 makes things work temporarily, but I'd (a) prefer a permanent solution, and (b) this is a production NAS, so I don't want to run commands I don't understand. The solution in that thread, gmirror, doesn't seem applicable to me and didn't work anyway on the drives.

Anyone have any ideas?

 

[cobrakiller58]

Afaik sysctl kern.geom.debugflags is the only way to do it which will stay in effect until the server is rebooted or you reset the debugflag to it's default value. I should also mention make sure you have the correct drive numbers because with that degubflag set you can run badblocks on drives that are in use.

 

[garm]

This is by design so people don’t fry their pools by miss identifying drives part of arrays and nuce them with dd or such.

“Burning in” drives in you prod system is insanely dangerous. I would recommend you use a secondary system

 

[rslocalhost]

garm,

Any way to override this? If the drives pass, I am planning to add them to the pool as replacement drives if they pass. What happens if I try to add them to a pool as replacement drives?

And yes, I would prefer to do this on a non-production system, but this is the only system we have that takes SAS drives.

 

[wblock]

Please show the output of diskinfo -v da21 and diskinfo -v da42. I can't recall if this is the error given on disks with 520-byte blocks, but it might be.

That "debugflags" sysctl is very dangerous. It should be considered a last resort. Due to the way disks are dynamically numbered, it is way too easy to misidentify one, then turn off the safety with that sysctl and destroy data. It would be worth picking up a 9211-8i just to use for testing drives. Cheaper than data recovery, anyway.

 

[rslocalhost]

I know how easy it is to get the numbering wrong. I'm very, very careful. I have someone else come behind me and confirm he gets the same numbers. Not fool-proof, but close. The 9211-8i looks cheap enough. I'll put one on my buy list.

Anyway, the info:

Code:

[root@snip] ~# diskinfo -v da21
da21
		512			 # sectorsize
		6001175126016   # mediasize in bytes (5.5T)
		11721045168	 # mediasize in sectors
		4096			# stripesize
		0			   # stripeoffset
		729601		  # Cylinders according to firmware.
		255			 # Heads according to firmware.
		63			  # Sectors according to firmware.
				K1KZ4H5N		# Disk ident.
		id1,enc@n5003048017b0d7fd/type@0/slot@14/elmdesc@Slot19 # Physical path

Code:

[root@snip] ~# diskinfo -v da42
da42
		4096			# sectorsize
		6001175126016   # mediasize in bytes (5.5T)
		1465130646	  # mediasize in sectors
		0			   # stripesize
		0			   # stripeoffset
		91200		   # Cylinders according to firmware.
		255			 # Heads according to firmware.
		63			  # Sectors according to firmware.
				NCGLR82Z		# Disk ident.
		id1,enc@n5003048017b0d7fd/type@0/slot@1/elmdesc@Slot00  # Physical path

 

[wblock]

da42 looks odd, with a block size of 4096 when da21 has a block size of 512. Are these disks supposed to be the same model? Were these commands both run on the same system? Do the results for da0 and da43 show the opposite?

The 9211-8i needs to be flashed to IT mode. Some places sell them that way.

 

[cobrakiller58]

Isn't that just showing one drive is a 4Kn and the other is 512e @rslocalhost those drives are different model#'s right?

 

[rslocalhost]

Yes, they are different model numbers, and the other da's show the same thing. I noticed the different sector sizes as I was posting this.

Anyway, any way other than the debugflags to get the drives writable? There must be something.

 

[wblock]

Are there other drives of the same model numbers as these that are working correctly? Comparing working with non-working with camcontrol identify might be helpful.

 

[rslocalhost]

>Are there other drives of the same model numbers as these that are working correctly?

Unfortunately, no. I have similar models, but not the exact same. But hoping they are close enough...
Working model HGST HUS726060AL4210:

Code:

[root@snip] ~# camcontrol identify da20 -v
camcontrol: sending ATA ATA_IDENTIFY via pass_16 with timeout of 30000 msecs
camcontrol: ATA ATA_IDENTIFY via pass_16 failed
(pass20:mpr0:0:33:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 00 00 00 00 00 00 00 00 40 ec 00
(pass20:mpr0:0:33:0): CAM status: SCSI Status Error
(pass20:mpr0:0:33:0): SCSI status: Check Condition
(pass20:mpr0:0:33:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(pass20:mpr0:0:33:0):
(pass20:mpr0:0:33:0): Field Replaceable Unit: 0
(pass20:mpr0:0:33:0): Command Specific Info: 0
(pass20:mpr0:0:33:0): Command byte 0 is invalid
(pass20:mpr0:0:33:0): Descriptor 0x80: f8 21camcontrol: sending ATA ATAPI_IDENTIFY via pass_16 with timeout of 30000 msecs
camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed
(pass20:mpr0:0:33:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 00 00 00 00 00 00 00 00 40 a1 00
(pass20:mpr0:0:33:0): CAM status: SCSI Status Error
(pass20:mpr0:0:33:0): SCSI status: Check Condition
(pass20:mpr0:0:33:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(pass20:mpr0:0:33:0):
(pass20:mpr0:0:33:0): Field Replaceable Unit: 0
(pass20:mpr0:0:33:0): Command Specific Info: 0
(pass20:mpr0:0:33:0): Command byte 0 is invalid
(pass20:mpr0:0:33:0): Descriptor 0x80: f8 21

Non working model HGST HUS726060AL4214:

Code:

[root@snip] ~# camcontrol identify da42 -v
camcontrol: sending ATA ATA_IDENTIFY via pass_16 with timeout of 30000 msecs
camcontrol: ATA ATA_IDENTIFY via pass_16 failed
(pass47:mpr0:0:53:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 00 00 00 00 00 00 00 00 40 ec 00
(pass47:mpr0:0:53:0): CAM status: SCSI Status Error
(pass47:mpr0:0:53:0): SCSI status: Check Condition
(pass47:mpr0:0:53:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(pass47:mpr0:0:53:0):
(pass47:mpr0:0:53:0): Field Replaceable Unit: 0
(pass47:mpr0:0:53:0): Command Specific Info: 0
(pass47:mpr0:0:53:0): Command byte 0 is invalid
(pass47:mpr0:0:53:0): Descriptor 0x80: f8 21camcontrol: sending ATA ATAPI_IDENTIFY via pass_16 with timeout of 30000 msecs
camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed
(pass47:mpr0:0:53:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0a 00 00 00 00 00 00 00 00 00 00 40 a1 00
(pass47:mpr0:0:53:0): CAM status: SCSI Status Error
(pass47:mpr0:0:53:0): SCSI status: Check Condition
(pass47:mpr0:0:53:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(pass47:mpr0:0:53:0):
(pass47:mpr0:0:53:0): Field Replaceable Unit: 0
(pass47:mpr0:0:53:0): Command Specific Info: 0
(pass47:mpr0:0:53:0): Command byte 0 is invalid
(pass47:mpr0:0:53:0): Descriptor 0x80: f8 21

 

[wblock]

Doh, "identify" is an ATA command. I don't know the equivalent for SAS disks.