Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Ron Johnson wrote:
> On Sat, 2006-04-15 at 15:54 -0700, Paul Scott wrote:
> > hendrik@topoi.pooq.com wrote:
> > > On Sat, Apr 15, 2006 at 12:27:35PM -0500, Ron Johnson wrote:
> > >
> > >> On Sat, 2006-04-15 at 06:30 -0400, hendrik@topoi.pooq.com wrote:
> > >>
> > >>> On Sat, Apr 15, 2006 at 10:25:28AM +0100, Wulfy wrote:
> > >>> (snip)
> > >>> because the sizes are measured in blocks originally, and a
block is 1024
> > >>> bytes, which is one KiB but 1.024 KB.
> > >>>
Actually - Block sizes are what they are (in binary), because computers
use Binary language to communicate/operate...Many HDD manufacturers
just like to *lie* and use a diff integer base (base10)...to make the
HDD look larger. Remember (if you use their base10 game) you lose
approximately 99GiB per every TeraByte of space;
1 TB = 10^12 = 1,000,000,000,000 (base10 - decimal)
1 TiB = 2^40 = 1,099,511,627,776 (base2 - binary)
> > >> Sectors are 512 bytes, and blocks (on hard disks) are typically
> > >> 4096 bytes (but that's determined when you format the partition,
> > >> and is determined at run-time).
> > >>
This (4096) may be true of most MS file systems - but AFAIK - not
according to the *nix 'dd' command, and Linux tools such as c/s/fdisk,
hdparm and others -- and Linux File systems (ext2, ext3). Honestly, I'm
not sure, I haven't looked at the numbers and done the math to see if
what these tools are reporting are nicely divisible by 4096
> > > But I believe the common filesystems use 1024-byte blocks anyway.
> > > At least space measurements seem to be done in blocks.
> > > lthough a few years ago I recall that both 512- and 1024 blocks
were in
> > > use -- very confusing.
> > >
> > Block sizes for several common file systems (ext2, ntfs, fat32) use
> > blocks whose sizes are multiples of 512 or 1024. 4096 is common
for a
> > reasonable sized partitions.
>
> And of course it always depends on disk capacity...
>
> A floppy drive has a 512 byte block, and MS-DOS formatted *old*
> HDDs with a 1024 byte sector size.
Referring to Fat12 perhaps ?
> > Powers of two are fairly obvious from a
> > hardware point of view.
I think we're leaving one relevant *term* out of the discussion; namely
*Track* - i.e.; "Sectors per Track"
Please note;
What I describe below is NOT set in stone in my meager brain :-)
The way I *think* I've come to understand it is; that 'block' and
'track' are synonymous -- BUT only when discussing MS file systems...In
Linux (such as ext2/3), I notice (atleast in tools such as
cfdisk/fdisk/sfdisk, and 'dd', etc) everything seems predicated on a
1024 'Block' size...(I certainly need to understand more about Linux
File systems - perhaps *nix file systems do not even use the term
"track").
Typical MS file systems (Fat16/Fat32/NTFS - excluding Fat12, just for
now please), have and use a *Sector* size of 512 Bytes (perhaps all
ATA/IDE/EIDE HDDs do (?)) -- but Track/Block size, can be
made/determined during the File system "Formatting" (<--MS specific?)
process. These *Tracks* or *Blocks* can be anywhere ranging in size
from 1-64KB (1024-65536 Bytes). Typical NTFS and Fat32 block sizes are
4096(4KB) ...while Fat16 used 32KB only (which created much "slack'
space), the introduction of Fat32 helped to lessen that issue (by using
4KB blocks). But Fat32 also introduced a whole host of 'proprietary'
oddities, like using a Non-Standard Boot Sector.
Fat32 has many *quirks* and oddities; The MBR (may) extend beyond the
1st 512 sector (CHS 0,0,1), a so-called 'xMBR' is sometimes used to
describe those other sectors. Also - It's maximum File SIZE capability
is 4GB (and then only when used on NT based OSes) - a 2GB limit on the
95/98/ME family.
Fat32 also increases it's Block size according to HDD partition size --
(note; off the top of my head) it will default to use 4KB blocks up to
8.4GB partitions, then 8KB blocks up to 32GB(or is it 64GB), then 16KB
blocks up to 127GB, etc....it's 'block' size is determined via the
partition size. I've created Fat32 partition using Debian installer (to
copy over a munged 98 partition's contents), and I guess I should
investigate that aspect a bit more ;-) ...BTW - While booted in 98,
"Scandisk" cannot even 'scan' this debian-made partition (likely due to
the variation of 'vfat' vs 'Fat32') - yet All the data is intact and
easily accessible.
NTFS can be set to use 1KB-64KB, though larger than 32KB is rare, and
is usually 4096 (4KB) ...IIRC - there may be some possible bad side
effects of using 64KB.
Fat32 has many *quirks* and oddities; The MBR (may) extend beyond the
1st 512 sector (CHS 0,0,1), a so-called 'xMBR' is sometimes used to
describe those other sectors. Also - It's maximum File SIZE capability
is 4GB (and then only when used on NT based OSes) - a 2GB limit on the
95/98/ME family.
more about both NTFS and FAT here;
(http://ntfs.com/)
If one ever used MS's utility "ScanDisk" or "Chkdsk" to do a Surface
Scan of the HDD, one notices the disk is sliced into Blocks or
*Clusters* (meaning Tracks in this case, I think)....uh oh, now I've
introduced yet _another_possible_proprietary_ term (?)
Then we can introduce into the discussion CHS (Cylinders/Heads/Sectors)
...or perhaps not :-) and how LBA INT13h distort the typical physical
translation that used to occur on much earlier and smaller HDDs, and
how we can define *absolute* vs *logical* sectors.
I'm only talking about MS proprietary formats in the hopes of responses
to help me understand the *Linux* File system standards and
terminology....and to further my understanding of manually editing
partition tables (using 'dd', 'c/s/fdisk', hex-editors and such).
How does any of this apply to RAID?
Well - RAID arrays need their *block* size determined upon creation.
Clarifications and Corrections are gladly welcomed.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Reply to: