If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Hello everyone!
I completely understand the logic behind defragmentation but I simply don't understand how it could work given the hard-drives internal block mapping. If the hard drive assigns logical blocks 1, 2, and 3 to physical blocks 20, 132, and 88 respectively, then what good is it if the defragger orders it by logical contiguity when it's the physical that counts? I've searched usenet but couldn't find a straight answer, any gurus up to the challenge? Cheers! Anthony |
#2
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Previously Anthony Paul wrote:
Hello everyone! I completely understand the logic behind defragmentation but I simply don't understand how it could work given the hard-drives internal block mapping. If the hard drive assigns logical blocks 1, 2, and 3 to physical blocks 20, 132, and 88 respectively, then what good is it if the defragger orders it by logical contiguity when it's the physical that counts? I've searched usenet but couldn't find a straight answer, any gurus up to the challenge? Cheers! Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. Arno |
#3
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Hello Arno, thank you for replying!
Really? Hmmm... so is the only purpose for the mapping itself just for defect control? And does anyone have any links to a site that explains how this works on a low level? It's just out of curiosity. Thanks! Anthony Arno Wagner wrote: Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. Arno |
#4
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocksrather than physical?
Anthony Paul wrote:
Hello Arno, thank you for replying! Really? Hmmm... so is the only purpose for the mapping itself just for defect control? And does anyone have any links to a site that explains how this works on a low level? It's just out of curiosity. Thanks! Anthony Arno Wagner wrote: Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. Arno HD designers use several strategies for sector replacement, and they generally treat their choices as proprietary information (trade secrets). One common scheme is the sliding-sector, in which tracks have hidden sectors at the "end" of the track. If a defect-free track holds logical sectors ItoK in physical sectors ItoK and the HD decides that physical sector J is bad (IJK), then after allocating a hidden sector, logical sectors ItoJ-1 will be in physical sectors ItoJ-1, and logical sectors JtoK will be in physical sectors J+1toK+1. Yes, Virginia, it is a tad more complicated than that; OK, maybe a *lot* more complicated. -- Cheers, Bob |
#5
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
"Bob Willard" wrote in message
Anthony Paul wrote: Hello Arno, thank you for replying! Really? Hmmm... so is the only purpose for the mapping itself just for defect control? And does anyone have any links to a site that explains how this works on a low level? It's just out of curiosity. Thanks! Anthony Arno Wagner wrote: Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. Arno HD designers use several strategies for sector replacement, and they generally treat their choices as proprietary information (trade secrets). One common scheme is Well, it used to be on IBM drives. Not so anymore. the sliding-sector, Or nested reassign. in which tracks have hidden sectors at the "end" of the track. Or at the end of a cylinder. If a defect-free track holds logical sectors ItoK in physical sectors ItoK and the HD decides that physical sector J is bad (IJK), then after allocating a hidden sector, logical sectors ItoJ-1 will be in physical sectors ItoJ-1, and logical sectors JtoK will be in physical sectors J+1toK+1. I think this might have been on SCSI drives, I'm not so sure it was used on IDE. On IDE a sector might just have been replaced with a sector further up the track without slipping all the other sectors. On SCSI you were able to choose which mode to use. Yes, Virginia, it is a tad more complicated than that; No, not really. You made it overly complicated. I stays where it is, (the contents of) J and all sectors behind it move up one place in the track or cylinder and there blocknumbers readjusted. While this prevents a seek to a replacement sector and a seek back when reading I-K sequentially, the replacement action itself is rather time consuming when sectors have to be copied further up in a secure way. It's also expensive use of spares. A drive may run out of spares merely because it runs out of spares in only one track or cylinder. It also has the problem that you have extra inbuilt latency because of the spare sectors not used in every track or cylinder. That may be why that was abandoned for spares in the last cylinder(s) of the drive. At least IBM/Hitachi provided a way to (Low Level) reformat (resequence) the drives in such a way that all logical block numbers -as they appear physically on the drive- are renumbered in sequential order again, similar to the description in the paragraph above, but without the copying. Which is similar to what happens before they leave the factory. OK, maybe a *lot* more complicated. |
#6
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Previously Anthony Paul wrote:
Hello Arno, thank you for replying! Really? Hmmm... so is the only purpose for the mapping itself just for defect control? And does anyone have any links to a site that explains how this works on a low level? It's just out of curiosity. No official thing, but basically the disk stores a bitmap (which is loaded into drive RAM when running) which gives the good/defect status for each sector. The bitmap is for very fast access. For the defect mapping it depends on were the spare sectors are. A typical solution is to have localized spares. One possibility is that the disk has a table for the localized reallocation, that gives the original sector number for each spare. Finding the right one would then need a linear seach through that table. If a spare-pool has, say, 1000 sectors in it, this is still an operation that needs 1ms or so and is not an issue. Optimization would include to do mapping tables that are sorted (allows n log n binary search) or hashed. Arno Thanks! Anthony Arno Wagner wrote: Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. Arno |
#7
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Previously Bob Willard wrote:
Anthony Paul wrote: Hello Arno, thank you for replying! Really? Hmmm... so is the only purpose for the mapping itself just for defect control? And does anyone have any links to a site that explains how this works on a low level? It's just out of curiosity. Thanks! Anthony Arno Wagner wrote: Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. Arno HD designers use several strategies for sector replacement, and they generally treat their choices as proprietary information (trade secrets). One common scheme is the sliding-sector, in which tracks have hidden sectors at the "end" of the track. If a defect-free track holds logical sectors ItoK in physical sectors ItoK and the HD decides that physical sector J is bad (IJK), then after allocating a hidden sector, logical sectors ItoJ-1 will be in physical sectors ItoJ-1, and logical sectors JtoK will be in physical sectors J+1toK+1. Yes, Virginia, it is a tad more complicated than that; OK, maybe a *lot* more complicated. That would be sort of the pool idea, with the pool resticted to one track. Easier to implement, but more wasteful. Arno |
#8
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Anthony Paul wrote
Really? Hmmm... so is the only purpose for the mapping itself just for defect control? No, it also maps logical blocks to heads/cylinders/sectors. And with modern drives the number of sectors per track varys in bands across the drive, so the original CHS spec isnt even possible with modern hard drives. And does anyone have any links to a site that explains how this works on a low level? It's just out of curiosity. You dont need one, its too obvious to need that. Arno Wagner wrote: Very simple, the mapping between the outside block address and the physical block placement on the disk is allmost 1:1. Other mappings are only used for defect replacement and that will affect onlt an insignificantly small number of blocks. |
#9
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Anthony Paul wrote
I completely understand the logic behind defragmentation No you dont. but I simply don't understand how it could work given the hard-drives internal block mapping. If the hard drive assigns logical blocks 1, 2, and 3 to physical blocks 20, 132, and 88 respectively, Drives dont do that. then what good is it if the defragger orders it by logical contiguity when it's the physical that counts? In fact logical and physical are the same with the exception of the reallocated bads and there arent enough of those to matter. And defrags are also about ensuring that particular files are in a single contiguous set of blocks, rather than fragmented. I've searched usenet but couldn't find a straight answer, Which should have told you that there is a fundamental problem with your idea about how hard drives work. any gurus up to the challenge? There is no 'challenge' |
#10
|
|||
|
|||
Why does hd defrag work when they work on virtual/logical blocks rather than physical?
Thanks to all for replying!
Rod Speed wrote: Anthony Paul wrote I completely understand the logic behind defragmentation No you dont. Hmmm... I thought the whole purpose of defragmentation was to maintain file contiguity so that the read/write head could read the sectors in a sequential fashion rather than have to jump around. However, since you've pointed out that I don't understand it at all, perhaps you can show me which part of my definition needs correcting. but I simply don't understand how it could work given the hard-drives internal block mapping. If the hard drive assigns logical blocks 1, 2, and 3 to physical blocks 20, 132, and 88 respectively, Drives dont do that. Yes, I realize that now... you've been kind enough to point out the fallacies, perhaps you would like to devote a modicum of that effort towards enlightenment as well. then what good is it if the defragger orders it by logical contiguity when it's the physical that counts? In fact logical and physical are the same with the exception of the reallocated bads and there arent enough of those to matter. Yes, this is a surprise since I've been told otherwise in the past but it makes sense to me. And defrags are also about ensuring that particular files are in a single contiguous set of blocks, rather than fragmented. How is this different from my understanding of the logic behind defragmentation? I've searched usenet but couldn't find a straight answer, Which should have told you that there is a fundamental problem with your idea about how hard drives work. any gurus up to the challenge? There is no 'challenge' I'm puzzled as to why you felt the inherent need to reply in this fashion but to each his own; and for the record, it was precisely because I knew that there was something fundamentally wrong that I posted the question in the first place. Perhaps if more effort went into educating people rather than castigating them for their lack of knowledge... no no, what am I saying, that would be too much to ask for. Thanks to all for clarifying the matter! Cheers! Anthony |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Long hard drive access times... | Random Person | General | 13 | August 2nd 05 11:49 PM |
writing cd`s | biggmark | Cdr | 7 | December 31st 04 08:57 AM |
my new mobo o/c's great | rockerrock | Overclocking AMD Processors | 9 | June 30th 04 08:17 PM |
Nero help needed | foghat | Cdr | 0 | May 31st 04 08:23 PM |
Help! - The dreaded buffer underrun | XPG | Cdr | 5 | August 31st 03 06:27 PM |