Hi there. That is exactly what I get, and the suggestion from McClarc works. Format should only update the disk label when you use the label command, and any other operations (print partition table, for example) will use the "current" label. format "Verify" and "Current" certainly does not pick up anything on the LUNs with "old" labels. I tried MCC's suggestion below. - Initially, Format sees disk #10 as "OPEN-E" - Inquire however reports it as "OPEN-E*2", whilst "Current" and "Verify" both print the contents of the Label. - And as mcc suggested, Type 0 detects the disk as an E*2 (27 Gb) Thanks _Johan P.S. In all fairness, Tommy Falsen hinted in the right direction too! # format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c0t0d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133> /sbus@54,0/SUNW,fas@0,8800000/sd@0,0 1. c1t0d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133> /sbus@55,0/SUNW,fas@0,8800000/sd@0,0 2. c2t14d33 <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,400000/sd@e,21 3. c2t14d34 <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,400000/sd@e,22 4. c2t14d42 <HITACHI-OPEN-E*15-SUN-0117 cyl 65533 alt 2 hd 15 sec 434> /sbus@54,0/fce@1,400000/sd@e,2a 5. c4t16d33 <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,401000/sd@10,21 6. c4t16d34 <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,401000/sd@10,22 7. c4t16d42 <HITACHI-OPEN-E*15-SUN-0117 cyl 65533 alt 2 hd 15 sec 434> /sbus@54,0/fce@1,401000/sd@10,2a 8. c4t17d3 <HITACHI-OPEN-E*10-0117 cyl 65533 alt 2 hd 30 sec 144> /sbus@54,0/fce@1,401000/sd@11,3 9. c4t17d4 <HITACHI-OPEN-E*3-0117 cyl 59275 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,401000/sd@11,4 10. c4t17d5 <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,401000/sd@11,5 Specify disk (enter its number): 10 selecting c4t17d5 [disk formatted] FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character volume name !<cmd> - execute <cmd>, then return quit format> inq Vendor: HITACHI Product: OPEN-E*2 -SUN Revision: 0117 format> ver Primary label contents: Volume name = < > ascii name = <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> pcyl = 19759 ncyl = 19757 acyl = 2 nhead = 15 nsect = 96 Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) 0 1 unassigned wm 0 0 (0/0/0) 0 2 backup wu 0 - 19756 13.57GB (19757/0/0) 28450080 3 - wu 0 - 0 0.70MB (1/0/0) 1440 4 - wu 1 - 19756 13.57GB (19756/0/0) 28448640 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0 format> cur Current Disk = c4t17d5 <HITACHI-OPEN-E-SUN-0117 cyl 19757 alt 2 hd 15 sec 96> /sbus@54,0/fce@1,401000/sd@11,5 format> ty AVAILABLE DRIVE TYPES: 0. Auto configure 1. Quantum ProDrive 80S 2. Quantum ProDrive 105S 3. CDC Wren IV 94171-344 4. SUN0104 5. SUN0207 6. SUN0327 7. SUN0340 8. SUN0424 9. SUN0535 10. SUN0669 11. SUN1.0G 12. SUN1.05 13. SUN1.3G 14. SUN2.1G 15. SUN2.9G 16. Zip 100 17. Zip 250 18. SUN9.0G 19. HITACHI-OPEN-E*15-SUN-0117 20. HITACHI-OPEN-E*10-0117 21. HITACHI-OPEN-E*3-0117 22. HITACHI-OPEN-E-SUN-0117 23. HITACHI-OPEN-E*5-0117 24. HITACHI-OPEN-E*2-0117 25. HITACHI-OPEN-E-0117 26. other Specify disk type (enter its number)[22]: 0 c4t17d5: configured with capacity of 27.13GB <HITACHI-OPEN-E*2-SUN-0117 cyl 39516 alt 2 hd 15 sec 96> selecting c4t17d5 [disk formatted] |---------+---------------------------> | | mcclark <mcclark| | | @daewerk.net> | | | | | | 23/04/2003 01:49| | | PM | | | | |---------+---------------------------> >------------------------------------------------------------------------------------------------------------------| | | | To: Johan Hartzenberg <jhartzen@csc.com> | | cc: | | Subject: Re: NON-SUMMARY: Mismatch between physical geometry and disk label contents | >------------------------------------------------------------------------------------------------------------------| Johan, You might get some success using format, then 'type' and '0'. That should re-probe your disk geometry... I think it should ask you whether you want to relabel the disk or not at that point if it thinks the old geometry is not correct. I'm not sure about whether doing this will cause 'current' to then show you the modified geometry or not if you don't relabel (I don't have a disk I can try it on right now...). If you're slicing space off of large physical LUNs on a storage arrary, you might want to incorporate this as a first step in disk layout once the LUN is presented. Some storage arrays (like StorEdge 6960) don't write anything to the LUN at all when the space is allocated, and what can happen is that if an old LUN was de-allocated, and a new one created starting at the same space, Solaris may see the old label and presume that it is valid. -mcc Johan Hartzenberg wrote: >Hi Gurus, >Unfortunately, I did not get any solution. I had suggestions to just >"Label" the disk, but my problem is not fixing a disk with an incorrect >label, but rather finding such disks (LUNs) across many systems because >these disks are currently "in use" and as a result, some portions of the >disk is not available. > >Richard Hobbs mentioned having seen the same thing in the past when moving >disks from one system to another. > >Using "format" to label a disk with an existing label does not re-read the >disk geometry from the physical disk, it reads it from the existing label. >The only way to really re-label a disk is by first corrupting the label, eg >using the following procedure: > >First, corrupt the first sector on the disk c#t#d# > dd if=/path/to/any/file of=/dev/rdsk/c#t#d#s2 count=1 bs=512 > >Next, use format to write a new label to the disk > format > select disk > label? YES > quit > >Then finally, encapsulate the disk, or partition and start using it as per >normal. > > >My Original question: > > > >>>Hi gurus, >>> >>>I was happily scripting a couple of weeks ago and came across something >>>that produced a message similar to this (off the top of my head) >>> >>>Warning: The label contents does not match the geometry reported by the >>>physical device. >>> >>>Now I can not remember the command I ran, but I want to use it in >>> >>> >another > > >>>script. I was busy writing a script to report on raw disk sizes as >>> >>> >seen > > >>by >> >> >>>Solaris (not Veritas), and I was playing with commands like >>> >>>format, prtvtoc, fmthard >>> >>>I've been searching the web and sunsolve, but I can't find out what it >>> >>> >is > > >>I >> >> >>>did. Makes me want to "script" to record everything I do... ! >>> >>>The situation I have is that sometimes when the storage administrators >>>allocate a whole bunch of LUNs I do not check each individually, and >>>sometimes I don't realise I am not seeing the full LUN (eg if the first >>>sector of an expanded LUN was previously the first sector of a smaller >>>LUN). I am trying to write a script which will tell me where I may be >>>using LUNs without getting access to the whole full size of the LUN. >>> >>> >>> >>>moreover, I have tried to write something to compare the output of >>> >>> >fdisk > > >>-g >> >> >>>with that of fdisk -G, but I always get the following message: >>> >>># fdisk -g /dev/rdsk/c3t11d4s2 >>>* Label geometry for device /dev/rdsk/c3t11d4s2 >>>* PCYL NCYL ACYL BCYL NHEAD NSECT SECSIZ >>> 39516 39516 2 0 15 96 512 >>># fdisk -G /dev/rdsk/c3t11d4s2 >>>/dev/rdsk/c3t11d4s2: Cannot get physical disk geometry. >>> >>> >>> >>>devinfo appears totally useless, and on Solaris 2.6 I get for -g and -G >>>both: >>> >>> Disk does not support fixed disk partition table >>> >>> >>>Any ideas/suggestions ? >>> >>>Thanx, >>> _Johan _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Apr 24 03:01:04 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:09 EST