Re: Native BSD disklabel access

[Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>]

At 11:10 Uhr +0900 22.1.2012, Izumi Tsutsui wrote:
>> In the wake of netbsd-6, I didn't want to be too intrusive (although
>> disksubr.c could use some tough love), just plopped in an adapted version
>> of the mac68k routine, and was able to access the sparc disk.
>>
>> Comments? Okay to commit?
>
>What should happen if writedisklabel() is called
>after readdisklabel() reads sparc disklabel?

Currently, you get something like

# disklabel sd2
# /dev/rsd2c:
type: SCSI
disk: M2512A
label: My MO test disk
flags:
bytes/sector: 512
sectors/track: 32
tracks/cylinder: 64
sectors/cylinder: 2048
cylinders: 217
total sectors: 446325
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

7 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 c:    446325         0     unused      0     0        # (Cyl.      0 -
217*)
 g:    446325         0     4.4LFS   1024  8192     7  # (Cyl.      0 -
217*)
disklabel: warning, partition p increased number of partitions from 7 to 16
disklabel: partitions g and p overlap
disklabel: partition j: partition extends past end of unit
disklabel: partition k: partition extends past end of unit
# disklabel -e sd2

[editor session]

disklabel: ioctl DIOCWDINFO: Input/output error
re-edit the label? [y]: n
#

(whatever issues that error), which is fine with me. As you indicate,

>Should non-native label be readonly?

you would have to be careful to (a) re-write a native label to the position
you read it from, (b) punt cases like the embedded sun label, (c) not mess
with platform-specific partition schemes like Apple's partition table or
mbr. So, not re-writing a BSD disklabel when it is not the platform's
native and preferred partition scheme seems safe to me.

        hauke

--
"It's never straight up and down"     (DEVO)