Date: Sun, 18 Mar 2001 15:05:46 +0100
From: "Steven Lagerweij" <[EMAIL PROTECTED]>
Subject: RE: The large disk question...
With this info, maybe it is now possible for someone to write a small
program that marks that area as bad or in use or something so you can
partition without minding the gap and breaking up the hd in smaller pieces
Anyone up to it?
-----Original Message-----
From: Digby Tarvin [mailto:[EMAIL PROTECTED]]
Sent: donderdag 15 maart 2001 22:07
To: Libretto
Subject: The large disk question...
Date: Thu, 15 Mar 2001 21:00:06 +0000 (GMT/BST)
From: Digby Tarvin <[EMAIL PROTECTED]>
Subject: The large disk question...
For anyone who is interested, I have now picked up a 20GB
hard disk try upgrade my 100CT, and have done some
experimenting to see exactly what happens with hibernation.
The following are my results after a couple of hours of
testing, and may be BIOS version dependant. My Libretto
still has the original version 6.50 bios that it came with.
The disk drive is an IBM DJSA-220 Travelstar ATA/IDE. The
nominal capacity is 20GB, although for some mysterious
reason the label on the drive indicates:
16383CYL, 16HEADS, 63SEC/T
which according to my calculations corresponds to only 8GB.
Perhaps this is just documenting what capacity will be seen
by crippled Microsoft systems....
Probing the drive revealed an actual geometry of
38760CYL, 16HEADS, 63SEC/T
which I calculate to equal a real capacity of 20,003,880,960 bytes.
I then created three partitions as follows: first a 1GB partition
in which to re-install Toshiba's W95, and then a 2GB partition
for BSD Unix, and the balance in a scratch partition.
I then booted Unix and ran a small program to ppatternize
the third partition, then booted windows to initiate a
hibernation, and back to Unix run another program to search
the disk for sectors that have been written to.
The scan program prints a message at the start and end
of any sequence of non-patterned data, and reported the
following:
Start Data: 1F316F400 (8373335040) = sector 16,354,170
End Data: 1F337F000 (8375496704)
Start Data: 1F3386C00 (8375528448)
End Data: 1F7366200 (8442503680) = sector 16,489,265
Start Data: 4A8518600 (20003784192)
END OF PARTITION at 4a8530000 (20003880960)
This seems reasonable, with the memory image written near what would
be the end of an 8GB disk, and occupying about 64MB.
Interestingly, the first time I ran the test it only occupied
about 32MB of disk space. Up until that point I had not
noticed that my memory expansion had stopped working.
I reseated it and re-booted and I was back to the 64MB
that I should have had.
I interpret the small patternised region from 8375496704 to
8375496704 in the middle of the region to be the buffer used
by my program to patternise the disk which was still in RAM
when the hibernation took place.
Specifically, the size of the changed region was
8442503680-8373335040 = 69,168,640 (66MB)
And was 159,894 sectors (81,865,728 bytes = 2,538 tracks)
from what the BIOS presumably thought to be the end of the disk.
This is a whole number of tracks, which is encouraging, but I
don't see an obvious reason for the exact size of the region.
It seems about 14Mb bigger than it needs to be.
Perhaps there are other things than normal memory to store,
such as the content of the video memory.
Assuming that the drive geometry used by the BIOS is based on
the FDISK labels 'large disk' convolutions, ie 63 sectors
per track, 255 heads, 1024 cylinders, the start of the
save area corresponds to the start of cylinder 1018, which
is good because the start of a logical cylinder sounds a lot less
arbitrary. The total space allocated would correspond to what
the BIOS thinks is the last 6 cylinders on the disk.
I havn't really investigated the 96,768 bytes of non-pattern data
at the end of the disk, but it seems to be a difference between
the the end of the last FDISK partition (which for safety I used
for writing) and the end of the raw disk (which I used for reading).
For completeness, here is the disk partitioning I used for the test:
8 partitions:
# size offset fstype [fsize bsize cpg]
a: 49581 2104515 4.2BSD 1024 8192 16 # (Cyl. 2087*-
2136*)
b: 196560 2154096 swap # (Cyl. 2137 - 2331)
c: 39070080 0 unused 0 0 # (Cyl. 0 -
38759)
d: 2104452 63 MSDOS # (Cyl. 0*-
2087*)
e: 32772411 6297480 4.2BSD 0 0 0 # (Cyl. 6247*-
38759*)
h: 3946320 2350656 4.2BSD 1024 8192 16 # (Cyl. 2332 - 6246)
FDISK table:
# size offset scyl shd ssc ecyl ehd esc type
1: 2104452 63 0 1 1 130 254 63 0x0b # (OTHER)
*2: 4192965 2104515 131 0 1 391 254 63 0x9f # (BSDI)
3: 32756535 6297480 392 0 1 1023 254 63 0x9f # (BSDI)
4: 0 0 0 0 0 0 0 0 0x00 # (Unused)
Regards,
DigbyT
--
Digby R. S. Tarvin
[EMAIL PROTECTED]
http://www.cthulhu.dircon.co.uk
**************************************************************
http://libretto.basiclink.com - Libretto mailing list
http://libretto.basiclink.com/archive - Archives
http://www.picante.com/~gtaylor/portable/faq.html - FAQ
-------UNSUBSCRIBE-------
mailto:[EMAIL PROTECTED]?subject=cmd:unsubscribe
--------UNSUBSCRIBE DIGEST------
Use above but add DIGEST to the subject line...
**************************************************************
**************************************************************
http://libretto.basiclink.com - Libretto mailing list
http://libretto.basiclink.com/archive - Archives
http://www.picante.com/~gtaylor/portable/faq.html - FAQ
-------UNSUBSCRIBE-------
mailto:[EMAIL PROTECTED]?subject=cmd:unsubscribe
--------UNSUBSCRIBE DIGEST------
Use above but add DIGEST to the subject line...
**************************************************************
