Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Andrei Popescu wrote:
> Willie Wonka <floydstestemail@yahoo.com> wrote:
>
> > Binary Example
> > 1,024
> > 1,048,576
> > 1,073,741,824
> > 1,099,511,627,776
> >
[snipped]
> > 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.
I concur;
-- however (and I should refine my statement earlier, about HDD Manu's
in general, as a *lie* - to perhaps *exaggerate*, or a similarly less
harsh word), - your 20GB HDD actually size (contains) is more than 20
Billion Bytes (likely ~20,587,000,000 bytes). This just makes for
unnecessary further confusion..here's an example using the 'hdparm'
utility (which I'm sure you're familiar with);
e.g.; I have some 80GB HDDs here, which are actually 82,348MB -or-
78,533MiB
~$ sudo hdparm -I /dev/hda
...
...
device size with M = 1024*1024: 78533 MBytes
device size with M = 1000*1000: 82348 MBytes (82 GB)
> > 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.
I think I'll leave this part of the topic alone for now, since I need
to brush up on my understanding of the 'physical' (CHS) vs 'logical'
(LBA) differences, but indeed a *Track* in Linux seems to contain 63
sectors, as noticed again using 'hdparm'
~$ sudo hdparm -I /dev/hda
....
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors: 4128705
LBA user addressable sectors: 160836480
LBA48 user addressable sectors: 160836480
....
> > 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.
I'll accept that info for now... thanks;
I'll digest it over time, and research a bit more, before again
addressing this sub-topic ;)
> > > 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.
Yep ....Ok
> Bye
> Andrei
I appreciated this dialog/dialogue :-)
All I can think of now, because I'm hungry is
(donuts/doughnuts/dough-nuts).
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Reply to: