Date: Sat, 12 Nov 2005 23:43:59 +0100
From: Philip Nienhuis <[EMAIL PROTECTED]>
Subject: Re: [LIB] 110CT Large Drives with EZ BIOS...
[EMAIL PROTECTED] wrote:
Date: Sat, 12 Nov 2005 10:09:52 -0600 (CST)
From: [EMAIL PROTECTED]
Subject: Re: [LIB] 110CT Large Drives with EZ BIOS...
Hello Raymond and thank you for your reply...
I was amazed at how this topic was discussed so much over the years with no
real end result that I could determine. It took many days to read the full
archives. The BIOS HDD <8.4 seems like a simple thing. Sort of a Yes/No to
me. A "No" of course is not what I wanted to hear. Also because much of the
information did not apply to the 100/100 directly I hoped it might be outdated
at least for these last two CT Models.
I will gladly accept the "No" at this point. :)
This all leads back to a previous question however...
I have allowed this computer to hibernate a number of times now since safely
duplicating the drive. The drive is full less 1/2 gig or so free. I opened
up a number of browsers and spreadsheets etc to make certain the memory would
have been completely full when written to disk.
I realize that Scandisk is NOT a high level tool, but I simply can not believe
it can't find a 64meg damaged spot on the hard drive, which hibernation should
have caused. Is it inaccurate to believe Hibernation should have blown the
formatting, data, everything on that area of the disk?
Any idea?
(As an aside: the "damaged spot" it is not just 64 MB but rather 64 MB
RAM + 2 MB video RAM + BIOS data)
As regards scandisk: Damage assessment depends on where the crucial disk
organization data are stored (i.e., tables with pointers to clusters
containing file fragments). On FAT(-32), this is usually at the start of
the partition. As long as those pointer tables (File Allocator Tables)
are intact, scandisk simply won't notice that the actual cluster
contents are blown to pieces.
You know, scandisk won't inspect a cluster that is in use by e.g., some
.xls file to check if that cluster contains valid Excel data; it just
checks that the cluster chain itself (in the FAT) is still complete and
its beginning is attached to some file descriptor somewhere in the FAT.
IOW, the very contents of data clusters is not quite scandisk's affair -
it won't even look at the data area proper (unless you instruct it to do
a surface check).
While FAT32 may be a bit more complex than FAT16 (or FAT12), this must
be largely the explanation you seek. Even if there are aditional FATs
elsewhere on the partition, as long as these have not been touched
scandisk won't ever notice problems.
Other file systems (NTFS, HPFS (OS/2), ext2 / ext3 (Linux)) have their
crucial data areas scattered over the entire partition, so they are much
more vulnerable and data corruption would be noted much easier.
BTW As Raymond wrote, there has been considerable debate on the merits
of various disk overlays. Even an otherwise very (IMO) knowledgeable &
prominent Lib user (dr. Xin Feng) once believed that some Maxtor overlay
(MaxBlast III) would finally fix the BIOS hibernation of Librettos
100/110CT. Alas, he was corrected all too soon.....
I think the BIOS hibernation routines might be patched (at least
theoretically), but it would take considerable disassembly efforts of
some very knowledgeable guy to come up with a BIOS "upgrade". I once
tried a similar thing on an ancient AT-like desktop, but although I
could recognize a lot from IBM BIOS sources in the AT tech ref manual,
after a week I had to give up - it was too complicated. Now the Lib110
design date is about 10-12 years later than that desktop and is thus
much more complicated - so I think there's little chance that anyone
will ever be able to succeed.
Philip
