Willie Wonka <[EMAIL PROTECTED]> wrote: > Binary Example > 1,024 > 1,048,576 > 1,073,741,824 > 1,099,511,627,776 > > notice the 'column' of numbers (aligned vertically, from the top); > 024 > 048 > 073 > 099 > > The "difference" (between decimal/binary) as sizes increase is _never_ > the same *percentage* wise...The binary total is *compounded* as the > sizes increase...(to a degree, and for lack of a better word). > > Explained another way (hopefully); > If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* > If you bought a 1,000,000 Byte (1MB) HDD - you'd lose 48 *KiloBytes* > If you bought a 1,000,000,000 Byte (1GB) HDD - you'd lose 73 > *MegaBytes* > If you bought a 1,000,000,000,000 Byte (1TB) HDD - you'd lose 99 > *GigaBytes* > > Pertaining to sizes of HDD -- The more you buy, the more you lose. > The Larger the HDD, the Larger the amount of lost area, in the > conversion.
Agree > What you *appear* to be doing (as do many others; likely > unintentionally) is just taking ~93.1% of a given base10 number. > > Hence; > 1,000,000,000,000 * .931 = 931,000,000,000 = *your* 931 [G]iB *result* > 1,000,000,000 * .931 = 931,000,000 = *your* 931 [M]iB *result* > 1,000,000 * .931 = 931,000 = *your* 931 [K]iB *result* > > But by doing so, you can do this with ANY power of 10 and still arrive > at the *same*percentage* as the sum/total...which is not the case > IMHO....I am open to correction though. > > To try and sum up my point; > Everytime you step *up* using a power of 10, you lose MORE when > converting to Binary. > > IMHO; > 1024 * 1024 = Correct > 1024 * 1000 = Incorrect > 1000 * 1000 = Incorrect > > I think much of the confusion stems from the numeric *starting* point. > Perhaps I'm just Full_of_$Hit ...and I have been wrong before in my > life :-) I did the calculations only for the TB/TiB case, but you have to redo the calculation for ever given size. Real life case: my laptop has a 20GB HDD = 2000000000 B /1024 /1024 = ~ 19.07 GiB => I lose ~ 903 MiB. For me this makes more logic, as there will never be a 20, 80, 200 GiB HDD, they are all 20, 80, 200 GB. What real size they have, you have to calculate for each one. Your rule is correct, but it doesn't tell me what the size of a given HDD is. > > Here is what I know about HDDs and stuff, someone please correct me > if > > I'm wrong. > > > > Tracks are something else. Physically a HDD is divided into > cylinders, > > heads, tracks and sectors. A track contains more sectors. I would > have > > to draw to explain this nice, but I'm sure you can find that on the > web. > > I actually already have nice pictures/diagrams of HDDs, but thank you > ;-) > Tracks are clusters of Sectors (of a set size) - AFAIK > > In this example, I'll use [Sector=512Bytes] and [Track=4096Bytes = 8 > Sectors]. > Data (File) that occupies more space than 1 sector (512Bytes), will > fill up those sectors until the Track/Block/Cluster (8 sectors) is > full, ...and a larger File will then overflow onto the next > Sectors/Track, and so on -- this is merely a consequence of > *contiguous* writing of data. You can't mix tracks and sectors with blocks/clusters. The former are physical 'units' while the later are logical. > Fragmentation occurs from Non-contiguous writes to the disk (storage of > data). > Definition; > Contiguous describes two or more objects that are adjacent to > each other. In computing, contiguous data is data that is moved > or stored in a solid uninterrupted block. In general, contiguous > data can be accessed more quickly than data that is stored in > fragments because fewer access operations will be required. > Files are sometimes stored in fragments so that storage space > can be used more efficiently (all the small spaces can be used). > > Cylinders are ring-shaped, vertically aligned areas of the HDD - think > of stacking doughnuts or rings; one on top of each other, the only > difference (besides the obvious), is that no 2 stacks of > cylinders/doughnuts/rings are the same physical size...yet they are > stacked vertically (according to the platters). This all starts to get > real *funky* once you start using LBA, instead of *phsyical* address. And a track is one dough-nut. And because in reality the radius of the dough-nut and hence also its length, the number of sectors/track is variable. But the OS doesn't see this. The numbers are converted inside the HDD logic and passed to the BIOS/OS as if the number of sectors/track is constant. Otherwise a C/H/S address would make no sense to the BIOS/OS. > > The smallest physical unit is the sector which is always 512 B. > > When you format a partition you divide it in allocation units. In > *nix > > they are called blocks, in MS clusters. > > Yes, I concur; > but I'd refine it to *a group of sectors, which has a set size* > perhaps. and that size is always 2^x * 512B where x is a positive integer value (zero allowed). How big it can get depends on filesystem limitations. Bye Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
