Re: New hard disk architectures

Arno Wagner wrote:
In comp.sys.ibm.pc.hardware.storage J. Clarke <jclarke.usenet@xxxxxxxxxxxxxxxx> wrote:
Yousuf Khan wrote:

Arno Wagner wrote: 
How would you determine where the boot-sequence ends? What if
it forks? How far would you get actually (personal guess:
not far)? And does it realyy give you significant speed imptovement?
With Linux, kernel loading is the fastest part of booting. The
part that takes long is device detection and initialisatiom.
My guess is it is the same with Windows, so almost no gain from
reading the boot data faster.

You would manually choose which components go into the flash disk. Or
you would get a program to analyse the boot sequence and it will choose
which components to send to the flash. You can even pre-determine what
devices are in the system and preload their device drivers.

I think that is nonsense. ECC is something like 10%. It does not
make sense to rewrite every driver and the whole virtual layer just
to make this a bit smaller, except meybe from the POV of a
salesperson. From an enginnering POV there is good reason not
to change complex systems for a minor gain.

You've just made the perfect case for why it's needed. 10% of a 100GB
drive is 10GB, 10% of 200GB is 20GB, and so on.


So what?  And how much of that will you actually be recovering?  Changing
the sector size doesn't recover _all_ of the space used by ECC.  Further,
you've totally neglected sparing--to have the same number of spare sectors
available you'd have to devote 8 times as much space to sparing.

Good point. Since the defective sector rate is low, you will
likely have only one per sector, even with larger sectors and
indeed 8 times as much overhead for spares.

Space on the platters is so cheap that an 8-fold increase in an already small quantity is easily dismissed. Platters are so cheap that drive manufactures routinely make drives that only use 60% or 80% of the platters. What matters is the logic involved in managing the drives - and if the manufacturers think they can make things work faster, more reliably, or both, with 4096 byte sectors, then I'm willing to keep an open mind until they are proven wrong.

Also being overlooked in this thread is how a drive with 4096 byte physical sectors will interact with the operating system. With NTFS, for example, 512 byte allocation units (AKA "clusters") are possible, but 4096 bytes is by far the mostly commonly used cluster size. What kind of performance differences might we see if there is a one-to-one correspondence between 4 KB allocation units in the file system and 4 KB phyical sectors, instead of having to address 8 separate 512 byte sectors for each cluster?

In other words, the effect on how the drive and the OS work together could be far more important than the effect on the raw drive performance. Hardware design /should/ take into account the software that will use it - and vice versa.

As well, clusters larger than 4 KB are possible with most file systems, but except with FAT16 they are very seldom used. If the option of super-sizing clusters was dropped, that would allow for
leaner and meaner versions of file systems like NTFS and FAT32 - they could drop the "allocation unit" concept and deal strictly in terms of physical sectors. Simpler software with less cpu overhead to manage the file system can't possibly hurt.




.

Relevant Pages

  • Re: Bad Clusters
    ... BOTH drives issued a "bad ... clusters" notice on one file. ... I don't know if dozens of other sectors have recently been ... So an elective test may report ...
    (microsoft.public.windowsxp.general)
  • Re: I request inclusion of reiser4 in the mainline kernel
    ... >changes or extensions to the makers of drives and other storage ... >bad block relocation and allow the filesystem to perform the action. ... it made the higher level file system code handle odd stuff. ... >which sectors have been relocated so the data can be moved off of them ...
    (Linux-Kernel)
  • Re: 3Ware Escalade Issues
    ... corrected using the spares, until no more spare sectors are left for replacements. ... Since the file system is 1 TB in size, it would take 8+ hours to FSCK it. ... How old are the drives, ...
    (freebsd-questions)
  • Re: Bad Clusters
    ... If bad clusters were found, I assume the data in the clusters is now trash. ... facility has been around since 2G drives of the Win9x era. ... BIOS can report S.M.A.R.T. ... Then you find that even though the summary says "OK", there have been x sectors that had ...
    (microsoft.public.windowsxp.general)
  • Re: 61GB in bad sectors (ref: 200GB drive reads as 128)
    ... see is 61 GB in bad sectors. ... >>Windows found problems with the file system. ... > As for the capacity question, this is the old confusion between binary ... > values for reportion the capacity of their drives and so to them a ...
    (microsoft.public.windowsxp.hardware)
Loading