On Tue, Sep 11, 2012 at 09:04:29PM +0200, MERIGHI Marcus wrote: > Hello Jan, > > thanks for your time and sorry for partly wasting it. > > h...@stare.cz (Jan Stary), 2012.09.11 (Tue) 14:27 (CEST): > > On Sep 11 12:48:40, MERIGHI Marcus wrote: > > > Hello, > > > > > > I did a complete deletion of all partitions of an external usb hd by > > > means of diskmgmt.msc under windows, followed by partitioning and > > > formating to msdos fat32 with kind help of acronis true image since > > > windows xp does not do such things natively. > > > > > > Very unexpectedly (to me) under OpenBSD the fdisk output (see below) > > > reflects the new layout, but disklabel output (see below) shows the old > > > partition size. > > > > What "old size"? > > sorry, I did not provide full history and context: > 1) the disk was in use before, partitioned 500GB/200GB msdos/ffs. > 2) to have a duid, a ran disklabel on it. > (that's the disklabel I was suprised to find after the following > steps, the duid was still the same) > 3) found I needed 700GB msdos > 4) backed up data on another disk > 5) repartioning and reformating as described in my initial message > 6) restore backed up data, 200GB remained free.
If you neither zero'd the disk sector containing the old disklabel nor did something that overwrote that sector with other data, then the disklabel will of course survive. And in the absence of an OpenBSD MBR partition to read the disklabel from, the code in readdoslabel() in kern/subr_disk.c, WILL attempt to read it from sector 1 if nothing else tickles its fancy. Assuming you are on i386 or amd64 anyway. And if the old disklabel happens to be sitting in one of the areas that the code tries, it will be assumed to be current. The real interesting question is what exactly did the old layout look like and which sector would that layout have caused the disklabel to be written in. Note that if the diskabel was written long enough ago, it may have been put somewhere that appears surprising today. :-) If you'd like to instrument the kernel and find out exactly what happened/is happening, please contact me off list and I'll be happy to help. I'm kinda curious myself. .... Ken > > > You repartitioned the disk under windows. > > So now it has no real BSD label. What does > > The other way 'round, it does have one, to my surprise. > > > disklabel do with such disks? The sensible thing: > > > > Note that when a disk has no real BSD disklabel, the kernel creates > > a default label so that the disk can be used. This default label will > > Do you really think I did not read that, though I was referring to > disklabel(5) even in the subject line? > > > And that's exactly what happened: > > > > > Disk: sd1 geometry: 91201/255/63 [1465149168 Sectors] > > > Offset: 0 Signature: 0xAA55 > > > Starting Ending LBA Info: > > > #: id C H S - C H S [ start: size ] > > > ------------------------------------------------------------------------------- > > > *0: 0C 0 32 33 - 91201 52 51 [ 2048: 1465145344 ] Win95 > > > FAT32L > > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] > > > unused > > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] > > > unused > > > 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] > > > unused > > disklabel recognized the fdisk DOS partition > > Correctly, the full 700GB of that disk. > > > and created a default disklabel for that: > > Wrong. > > > > # /dev/rsd1c: > > > type: SCSI > > > disk: SCSI disk > > > label: holmer-medien-01 > > > duid: 94f3e0ef639263f9 > > > flags: > > > bytes/sector: 512 > > > sectors/track: 63 > > > tracks/cylinder: 255 > > > sectors/cylinder: 16065 > > > cylinders: 91201 > > > total sectors: 1465149168 > > > boundstart: 0 > > > boundend: 1465149168 > > > drivedata: 0 > > > > > > 16 partitions: > > > # size offset fstype [fsize bsize cpg] > > > c: 1465149168 0 unused > > > i: 1048576000 2048 MSDOS # > > If you were right, ``i'' would be the full size, as in the fdisk output, > not just 500GB. > > Meanwhile I've tested ``D'' in disklabel editor; after that the correct > size is reported. Did not dare to save the disklabel, though. Still > hoping for a "go ahead, that's the right thing to do". And an > explanation of how the disklabel could survive, but that's optional :-) > > Thanks and good night, Marcus > > > !DSPAM:504f2f5b153932021786788!
