This message is from the T13 list server.

I think that a partition table is not a problem itself. Considering that
HDDs are becoming larger and larger, the possibility of split a huge data
space in smaller parts (partition!) get each more needed. Usually, only the
first two entries of the partition table are used when there are extended
partition(s). Of course, since there are four entry, anyone could create up
to four primary partitions. But, as people use fdisk-alike programs to
create partitions, it results that the two last entries are wasted, what
represents 32 bytes that could be employed to provide at least four bytes to
become those 32-bit wide fields in 48-bit ones. The remaining bytes could be
allocated to some other thing or left idle as spare to future needs.
x86-based computers use BIOS that expect to find a 0xAA55 signature at the
end of C/H/S=0/0/1 sector to consider it a candidate to a bootable disk. I
don't see a so big problem about this signature, since it's only a way to
"validate" (in a very relaxed manner) the disk. But I think that the rigid
C/H/S=0/0/1 or LBA 0, it doesn't matter,  address expectation is the real
problem! A defective LBA 0 sector (I am not saying a sector with corrupted
data, but a really unreadable one) makes a HDD unuseful! It doesn't mean
definitely lost data at all, but a HDD that final user will have to discard.
Maybe BIOS makers and OS manufactures could make things more flexible,
allowing to define that the first sector to be seeked is the LBA X one,
where X >= 0. At least, a well defined range as, for example, 0 to 62. So,
BIOS will first seek the user-defined sector that could be the LBA 0 or any
other. In case of failure, an alternative sector (or a list of alternatives)
would be read.  Usually the first partition created begins at LBA 63. In the
old times, the first partition started at C/H/S=0/1/1. For long time,  HDDs
showed an architecture of 63 sector per track and it seems that fdisk-like
makers get acostumed to  :)
I work on low-level environment and I have a curiosity, if someone can spend
some time to answer: why Read/Write Long Sector commands were banned from
AT/A-4 on?
........................................................................
Perito S�rgio Raposo - Niter�i - RJ (Brazil)
........................................................................

(see english version of this signature below)

Resgate cient�fico de arquivos, per�cia investigativa de dados,
quebra �tica de prote��o e desenvolvimento de software b�sico.

   http://www.recuperacaodedados.com.br
   http://www.periciadigital.com.br

   telefone:_______0**21 2611-4209, 2610-5070
   celular:________0**21 9136-4003
   fax:____________0**21 2611-4209, 2610-5070
   e-mail:[EMAIL PROTECTED]

Aviso: o conte�do deste e-mail � exclusivamente direcionado ao(s)
destinat�rio(s) explicitamente arrolado(s) e unicamente para seu
conhecimento. Exceto sob permiss�o expressa, � desautorizada sua
divulga��o e/ou c�pia, parcial ou integralmente, em qualquer m�dia
que franquie o acesso a terceiros, intencional ou acidentalmente.
Se esta mensagem foi erroneamente recebida, por gentileza, apague-a.
........................................................................

Scientific data rescue, forensic disk analisys/computer evidence,
password/protection ethical cracking and low-level/system programming.

   http://www.recuperacaodedados.com.br
   http://www.periciadigital.com.br

   phone:__________+55 21 611-4209, 610-5070
   cellular phone:_+55 21 9136-4003
   fax:____________+55 21 611-420, 610-5070
   e-mail:[EMAIL PROTECTED]

Notice: this e-mail content is exclusively addressed to the one(s)
explicitly listed and uniquely for awareness purpose. A partial or
integral reprodution of this content is not authorized if the copy
will be accessable for anyone else, either intentionally or accidentally.
If this message was improperly received, please, delete it.
........................................................................


Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to