[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference aosg::lsm

Title:	LSM

Moderator:	SMURF::SHIDERLY

Created:	Mon Jan 17 1994
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	803
Total number of notes:	2852

758.0. "voldisksetup and block 0" by UTRTSC::WINDMEIJER () Wed Feb 19 1997 07:17

    
    Hello,
    
    I've installed Digital Unix v4.0b on my system. When I ran voldisksetup
    on a RZ28 I got the following disklabel:
    
      a:   131072        0    unused        0     0         # (Cyl.    0 - 95*)
      b:   401408   131072    unused        0     0         # (Cyl.   95*- 386*)
      c:  4110480        0    unused        0     0         # (Cyl.    0 - 2987*)
      d:  1191936   532480    unused        0     0         # (Cyl.  386*- 1253*)
      e:  1191936  1724416    unused        0     0         # (Cyl. 1253*- 2119*)
      f:  1194128  2916352    unused        0     0         # (Cyl. 2119*- 2987*)
      g:  4109456        0   LSMpubl                        # (Cyl.    0 - 2986*)
      h:     1024  4109456   LSMpriv                        # (Cyl. 2986*- 2987*)
    
    
    Now everbody knows that you got a problem when the disk starts at block
    0 (disklabel). That is why in Digital Unix v3.2x LSMpubl starts at
    block 16.
    This issue prevented me to make a mirror because I couldn't write block
    0
    
    I tried to modify partion g with size 4109440 starting at block 16
    but then disklabel is complaining about the g partition already in
    use, which is't because I just wrote a new label on it.
    
    Can anyone explain this and why in DU v4.0 LSMpubl starts at block 0.
    
    Peter Windmeijer
    MCS Holland

T.R	Title	User	Date	Lines
758.1	no need to fix it cause its not broken	SMURF::SCHLOSS	`Mon Feb 24 1997 20:34`	17
	I'm not sure if I understand exactly what you are asking but I think that I understand the gist of it. The "everybody knows" part was fixed in 4.0. LSMpubl, LSMpriv, and LSMsimp partitions can now properly handle partitions that include block 0. There is code in place to skip the first 16 sectors (block 0 plus bootstrap) for those disk types. LSMnopriv disks are a different matter and you may have problems if you attempt to do anything fancy reconfigurations. As for why you had trouble modifying the disklabel, the problem was that LSM was still using the disk. The system tried to prevent you from relabeling the disk while it was in use. If you forced it then you will need to remove the disk from LSM and then place it back under LSM to allow it to initialize the disk correctly. You no longer need to muck with the disklabel to deal with block 0. LSM now handles this correctly.
758.2	What is wrong with this	UTRTSC::WINDMEIJER	`Wed Mar 19 1997 13:29`	91
	You skipped the essence of this problem. There was no problem with making a volume but a problem with making the mirror. Do the following. Take two disk and make the both sliced. Make a volume on the first one. (no problem). Make a mirror by adding the second disk and this will result in an error Example: # volprint -Aht Disk group: rootdg DG NAME GROUP-ID DM NAME DEVICE TYPE PRIVLEN PUBLEN PUBPATH V NAME USETYPE KSTATE STATE LENGTH READPOL PREFPLEX PL NAME VOLUME KSTATE STATE LENGTH LAYOUT ST-WIDTH MODE SD NAME PLEX PLOFFS DISKOFFS LENGTH DISK-NAME DEVICE dg rootdg 852721120.1025.sys1.fire.dec.com dm rz0d rz0d simple 1024 1190912 /dev/rrz0d dm rz26 rz26 sliced 1024 4109456 /dev/rrz26g dm rz27 rz27 sliced 1024 4109456 /dev/rrz27g # volassist make vol01 20M rz26 # volprint -Aht Disk group: rootdg DG NAME GROUP-ID DM NAME DEVICE TYPE PRIVLEN PUBLEN PUBPATH V NAME USETYPE KSTATE STATE LENGTH READPOL PREFPLEX PL NAME VOLUME KSTATE STATE LENGTH LAYOUT ST-WIDTH MODE SD NAME PLEX PLOFFS DISKOFFS LENGTH DISK-NAME DEVICE dg rootdg 852721120.1025.sys1.fire.dec.com dm rz0d rz0d simple 1024 1190912 /dev/rrz0d dm rz26 rz26 sliced 1024 4109456 /dev/rrz26g dm rz27 rz27 sliced 1024 4109456 /dev/rrz27g v vol01 fsgen ENABLED ACTIVE 40960 SELECT - pl vol01-01 vol01 ENABLED ACTIVE 40960 CONCAT - RW sd rz26-01 vol01-01 0 0 40960 rz26 rz26 # volassist mirror vol01 rz27 fsgen/volplex: Volume vol01, plex vol01-02, block 0: Plex write: Error: Write failure fsgen/volplex: Error changing plex vol01-02: Record not in disk group fsgen/volplex: Attempting to cleanup after failure ... volassist: Unable to find the target mirror in vol01 As you can see you can't create the mirror. Then the second problem about the changing the disklabel. Again an example # voldisk list DEVICE TYPE DISK GROUP STATUS rz0d simple rz0d rootdg online rz27 sliced rz27 rootdg online # disklabel -z rz26 # disklabel -rw rz26 rz28m # voldisksetup rz26 # disklabel -e rz26 986 /g:/ g: 4109456 0 LSMpubl # (Cyl. 0 - 2986) s/ 0/16/p g: 4109456 16 LSMpubl # (Cyl. 0 - 2986) w 986 q Warning, edit session exited abnormally! write new label? [y]: y partition 'g' overlaps with partition 'h' which has an in-use fstype re-edit the label? [y]: The question is why can't I change the label. At this point LSM should not have opened the disk. /Peter
758.3	no need to edit disklabel	SMURF::SCHLOSS	`Wed Mar 19 1997 18:36`	29
	The problem is not that the mirror is failing, that is just the symptom. The problem is the disks were added to LSM in a manner that did not account for the 16 block disklabel/bootstrap. To fix this you need to first remove the disks from LSM control and then add them back again. Removing them from rootdg will not be sufficient. I would suggest: 1. Remove any volumes, plexes, and subdisks located on the disks 2. Run "voldg rmdisk" to remove the disks from rootdg 3. Run "voldisk rm" to remove the disks from LSM control 4. Run "voldiksetup -i" on each disk to place the disk back under LSM control. 5. Run "voldg adddisk" to add each disk to rootdg. The second problem concerns editing the disklabel. The disklabel utility was enhanced in V4.0 to prevent you from inadvertently corrupting data. It does this by not allowing you to move or shrink a disk partition that is marked as being in-use. The voldisksetup command allocates the partitions and marks them as in-use. You are then trying to shrink one of the partitions. As far as disklabel is concerned there is data there and what you are trying to do is a no-no. Think about this as if there were a UFS partition there. If you move the front of the partition the entire filesystem will be lost. It doesn't matter if the filesystem is mounted and the partition is open or not. If you really want to edit the partition you need to do this in two steps. The first step would be to mark the partition as unused. The next step would be to change of offset and length and to mark the partition as in-use by LSM. Again, there should be no need to do this in V4.0. I hope that this makes things clear.