Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Mon, May 08, 2006 at 01:50:27PM -0400, Daniel B. wrote: Mike McCarty wrote: Well, I used to work as a watchmaker, and I can't think of any context where KB stands together as written with K meaning karat. That's not surprising--in SI, the prefix is the scale factor, and the remainder is the unit. I don't think there are any unit symbols that have multiple uppercase letters. Is Hz for Hertz not standard? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
[EMAIL PROTECTED] wrote: On Mon, May 08, 2006 at 01:50:27PM -0400, Daniel B. wrote: Mike McCarty wrote: Well, I used to work as a watchmaker, and I can't think of any context where KB stands together as written with K meaning karat. That's not surprising--in SI, the prefix is the scale factor, and the remainder is the unit. I don't think there are any unit symbols that have multiple uppercase letters. Is Hz for Hertz not standard? Yes, it is standard. Why do you ask? It's certainly not a unit symbol with multiple uppercase letters. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Tue, May 09, 2006 at 04:38:16PM -0400, Daniel B. wrote: [EMAIL PROTECTED] wrote: On Mon, May 08, 2006 at 01:50:27PM -0400, Daniel B. wrote: Mike McCarty wrote: Well, I used to work as a watchmaker, and I can't think of any context where KB stands together as written with K meaning karat. That's not surprising--in SI, the prefix is the scale factor, and the remainder is the unit. I don't think there are any unit symbols that have multiple uppercase letters. Is Hz for Hertz not standard? Yes, it is standard. Why do you ask? It's certainly not a unit symbol with multiple uppercase letters. Daniel Ah! Missed the word uppercase. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka wrote: Serial ATA (SATA) data transfer rate specification = 1500 *mbps* or *mb/sec* (megabits per second). No. Megabits be per second is Mbps (lowercase m means milli). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka wrote: ... 1 bit * 8 = 1 byte ^^ I forgot to capitalize my 'B' in Byte above The word byte doesn't need to be capitalized. (Were you thinking of the capitalized letter B by itself when it stands for the word byte?) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka wrote: ... IOW - Is this how one would correctly display these rates ? 1500mbps = 1.5gbps = 187.5mBps = 1.875gBps ? I think you mean 1500Mbps = 1.5Gbps = 187.5MBps = 1.875GBps As you can see the capitalized 'B' appears a tad ...'out of place'(?), but it's likely /very/ necessary, in order to maintain clarity. If you're at all familiar with SI it shouldn't look out of place. Consider the scaled units mA, GW, kV, mPa, etc. While I may over-annunciate and over-emphasize when referring to Bytes, instead of bits (via my use of GB/MB/KB vs. gb/mb/kb), Why are you changing the capitalization of the prefix letters there? Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Mike McCarty wrote: Well, I used to work as a watchmaker, and I can't think of any context where KB stands together as written with K meaning karat. That's not surprising--in SI, the prefix is the scale factor, and the remainder is the unit. I don't think there are any unit symbols that have multiple uppercase letters. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Monday, May 08, 2006 6:47 PM GMT, Daniel B. [EMAIL PROTECTED] wrote: Willie Wonka wrote: ... IOW - Is this how one would correctly display these rates ? 1500mbps = 1.5gbps = 187.5mBps = 1.875gBps ? I think you mean 1500Mbps = 1.5Gbps = 187.5MBps = 1.875GBps AFAIK, SATA uses a start and stop bit for each byte, so the 1.5Gbps are still 150MB/sec, which explains the 120MB/sec people usually get from the interface at the common ~80% efficency for ATA interfaces. BTW, 187.5MB/sec = 0.1875GB/sec (0.1831 to be exact) not 1.875GB/sec which is 1875MB/sec. Regards, IraqiGeek www.iraqigeek.com Murphy's Computer Law 34: There's never time to do it right, but always time to do it over. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Richard Lyons [EMAIL PROTECTED] writes: All very strange. I grew up with lowercase for small, uppercase for large: m milli- 10^-3 c centi- 10^-2 d deci-10^-1 D deca-10 H hecta- 10^2 K kilo-10^3 M mega-10^6 G giga-10^9 etc... Everything up to kilo is lowercase. See http://en.wiktionary.org/wiki/Wiktionary_Appendix:SI_units#SI_prefixes_.28with_symbols_in_parentheses.29 Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Paul Johnson wrote: That's right, except it's kb or kB (for kilobits and kilobytes respectively), never KB or Kb. k is kilo, K is Karat. Paul just mistook prefixes and units... mm is milimeter, where first 'm' means mili and second 'm' means meter. One letter can have more meanings. On 19.04.06 11:49, Mike McCarty wrote: By convention, the k for kilo is permitted to be in either case. once again, the convention was that small 'k' means 1000, while capital K means 1024... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Where do you want to go to die? [Microsoft] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* Matus UHLAR - fantomas wrote: No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. On 19.04.06 12:09, Mike McCarty wrote: Nope. Both the K and the k have been used in electronics to mean times 1000 since I got involved in about 1965 or so. I have never seen/heard about that, but you may be right. However, for computer busines (I'm kinda involved only since 1986) I've always and everywhere seen the explanation I provided above. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Enter any 12-digit prime number to continue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
From: Paul Johnson [EMAIL PROTECTED] On Tuesday 18 April 2006 05:31, Willie Wonka wrote: Maybe I'm dense, but; kb = kilobit KB = KiloByte mb = megabit MB = MegaByte 1 bit * 8 = 1 byte 1 Byte / 8 = 1 bit That's right, except it's kb or kB (for kilobits and kilobytes respectively), never KB or Kb. k is kilo, K is Karat. If I sent any private comments in reply to anything on the group, my sincerest apologies. The Reply To address evidently isn't set to the list, and hotmail loves to ignore the list address. Apparently, this is not a problem with the mail clients everyone *else* are using. Not that the @hotmail.com would be any indicator of my inability to use them or anything. That said ... What will happen when you run out of capital and lower case letters to identify your jumble of units? I mean, I know there's a GG-1, but would this mean, like, GigaGiga? And what if I said Gg? Would that be Gigagram? I mean, I know english is kinda strange, with # and ' and and stuff, but in some ways, it kinda' makes sense to avoid using letters for units of measurement. I guess we could mix them, too, though. k#, M#, and G#. Hmmm. Now it looks like BASIC. Blech. Love Friendship Blessed Be! Lynn Erika Kilroy _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
+++ Matus UHLAR - fantomas [21/04/06 08:54 +0200]: On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* Matus UHLAR - fantomas wrote: No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. On 19.04.06 12:09, Mike McCarty wrote: Nope. Both the K and the k have been used in electronics to mean times 1000 since I got involved in about 1965 or so. I have never seen/heard about that, but you may be right. However, for computer busines (I'm kinda involved only since 1986) I've always and everywhere seen the explanation I provided above. All very strange. I grew up with lowercase for small, uppercase for large: m milli- 10^-3 c centi- 10^-2 d deci-10^-1 D deca-10 H hecta- 10^2 K kilo-10^3 M mega-10^6 G giga-10^9 etc... It was simple in those days... before computers. But I wouldn't want to be without... Also before cereal packs started confusing calories and Kcal. Can we get any further OT I wonder? -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Matus UHLAR - fantomas wrote:
Paul Johnson wrote:
That's right, except it's kb or kB (for kilobits and kilobytes
respectively), never KB or Kb. k is kilo, K is Karat.
Paul just mistook prefixes and units...
mm is milimeter, where first 'm' means mili and second 'm' means
meter. One letter can have more meanings.
On 19.04.06 11:49, Mike McCarty wrote:
By convention, the k for kilo is permitted to be in either case.
once again, the convention was that small 'k' means 1000, while capital K
means 1024...
I can show you a meters tall stack of Electronics Magazines which
dispute that. Convention since I got involved (in about 1964 or so)
is k and K both mean 1000 when referring to electronics units.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Mike McCarty wrote: I can show you a meters tall stack of Electronics Magazines which dispute that. Convention since I got involved (in about 1964 or so) is k and K both mean 1000 when referring to electronics units. It's no good looking there for rigor: capitals for big numbers (but only over kilo); upper and lower case don't match; no Greek font means you have to mew. It's only English: what's most true is what's most used; makes life (and technical lists) more interesting though. Regards, Dave Whelan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
--- Willie Wonka wrote: [ This message is being forwarded to the list as well ] Date: Wed, 19 Apr 2006 19:04:32 -0700 (PDT) From: Willie Wonka [EMAIL PROTECTED] Subject: Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?) To: Mike McCarty [EMAIL PROTECTED] --- Mike McCarty [EMAIL PROTECTED] wrote: Willie Wonka wrote: [snip] Umm, it should be ATA, not IDE. IDE is a packaging issue, while ATA is an interface spec. Yeah, you're right, but that 'accident' happened LONG ago, and shoulld've been corrected then - and the IDE Acronym remains important to many...I did post that they were NOT good examples, but the DEBIAN-USER listserv robocop, seems to hold my posts for 9-12Hrs BEFORE actually posting them.sigh :-( Well, I used to work as a watchmaker, and I can't think of any context where KB stands together as written with K meaning karat. Note that carat and karat are both words, but they mean different things. The first is the name of the unit of weight for gem stones, the latter is the name for the unit of fineness of gold in 1/24 parts. Thanks - you've refreshed my memory; 12/18/24 *Karat* Gold -and- .007 ounces = 1 *Carat* in weight (How it's Made; TV Documentary on the History Channel :-)) There's NO need to repond to me *Off-list*, and I will gladly post a COPY of this therebut because of some inexplicable issues, you may NOT see it *On-List* until some 24hrs later, (some posts I made today, STILL have not shown up) - but anyway Regards __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Paul Johnson wrote: On Tuesday 18 April 2006 05:31, Willie Wonka wrote: Maybe I'm dense, but; kb = kilobit KB = KiloByte mb = megabit MB = MegaByte 1 bit * 8 = 1 byte 1 Byte / 8 = 1 bit That's right, except it's kb or kB (for kilobits and kilobytes respectively), never KB or Kb. k is kilo, K is Karat. That may be true somewhere but it's not a very strong standard. aptitude agrees with you but the Firefox downloader does not not do NIST or Wikipedia or the AECMA I learned that upper case metric prefixes were used for multiples of units where lower case letters were used for divisions of units. Paul Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Paul Johnson wrote: On Tuesday 18 April 2006 05:31, Willie Wonka wrote: Maybe I'm dense, but; kb = kilobit KB = KiloByte mb = megabit MB = MegaByte 1 bit * 8 = 1 byte ^^ I forgot to capitalize my 'B' in Byte above 1 Byte / 8 = 1 bit That's right, except it's kb or kB (for kilobits and kilobytes respectively), never KB or Kb. k is kilo, K is Karat. Ok - thanks - now only if everyone would remember and use these... What I more than eluded to earlier; concerning SATA specs and serial signaling data transfer rates...have I found a solution ? IOW - Is this how one would correctly display these rates ? 1500mbps = 1.5gbps = 187.5mBps = 1.875gBps ? As you can see the capitalized 'B' appears a tad ...'out of place'(?), but it's likely /very/ necessary, in order to maintain clarity. While I may over-annunciate and over-emphasize when referring to Bytes, instead of bits (via my use of GB/MB/KB vs. gb/mb/kb), it seems my silly method may be more effective - otherwise we're in for some serious rabid-rabbits taking over - with all those *Karats* (Carrots) hanging around, ready to be eaten :-) Contextually though, they are completely different - like oh say using the acronym *IDE* , which can be Integrated Device Electronics -or- Integrated Development Environment ((in most 'computer' circles) and completely dependent upon the context of it's use). oh, the heck with it, lol ;-) I've seen some well-known hardware review sites refer to SATA drive specs as *1.5GBPS* (and similarly, 3.0GBps for SATA II / SATA 2 spec.) BTW - if anyone's a Jeweler, would the 'K' (Karat) ever be used in combination with a 'B' ? (capital or lowercase)and I never could remember if Karat is with a 'K' or a 'C' :doh: __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On 18.04.06 05:31, Willie Wonka wrote: Matus UHLAR - fantomas wrote: On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. But this can't be applied for 'M' because big 'M' is 1 000 000, while small 'm' is 0.001 (1/1000). So what do you propose as a solution ?? solution? strictly differ between decadic and binary prefixes, so use k for 1000, M for 100, G for 10, while Ki for 1024, Mi for 1048576, Gi for 1073741824 so if a HDD manufacturer speaks about 20GB HDD, count it as 20 000 000 000 B, so you won't be surprised it is not 20 GiB. Maybe I'm dense, but; kb = kilobit = 1000 b KB = KiloByte = 1024 B mb = megabit nope, small 'm' snands for 'mili' which is 1/1 000 000 e.g. one millionth part. MB = MegaByte megaByte, actually 100B, but is ocasionally used 1 bit * 8 = 1 byte 1 Byte / 8 = 1 bit yes, usually. the Byte was first defined as the smallest amount of data a CPU can ordinadily work with. currently, it's being used as 8 bit, however there were compurers that used e.g. 9-bit Byte. Serial ATA (SATA) data transfer rate specification = 1500 *mbps* or *mb/sec* (megabits per second). 1500 / 8 = 187.5 *MBps* or *MB/sec* - as I again say, small 'm' means 'mili' so it's not correct Luckily, HDD manufacturers count with KB/KiB (1024B)'s, so 10GB HDD was counted as 1 000 000 KB - 1 024 000 000 Bytes. This was because HDD's use 512B sectors, and it's easier to divide number of sectors by 2 than to multiply it by 512. Luckily ? I think not Why would I want to divide sectors anyway. what I meant, was that it would be even worse if they multiplied number of sectors by 512 and divide by 1000 to get some more of fake capacity... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Two words: Windows survives. - Craig Mundie, Microsoft senior strategist So does syphillis. Good thing we have penicillin. - Matthew Alton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Wed, 2006-04-19 at 14:22 +0200, Matus UHLAR - fantomas wrote: mb = megabit nope, small 'm' snands for 'mili' which is 1/1 000 000 e.g. one millionth part. m = milli = 1 / 1 000 u (greek letter mu) = micro = 1 / 1 000 000 -- Matt Zagrabelny - [EMAIL PROTECTED] - (218) 726 8844 University of Minnesota Duluth Information Technology Systems Services PGP key 1024D/84E22DA2 2005-11-07 Fingerprint: 78F9 18B3 EF58 56F5 FC85 C5CA 53E7 887F 84E2 2DA2 He is not a fool who gives up what he cannot keep to gain what he cannot lose. -Jim Elliot signature.asc Description: This is a digitally signed message part
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Paul Johnson wrote:
On Tuesday 18 April 2006 05:31, Willie Wonka wrote:
Maybe I'm dense, but;
kb = kilobit
KB = KiloByte
mb = megabit
MB = MegaByte
1 bit * 8 = 1 byte
1 Byte / 8 = 1 bit
That's right, except it's kb or kB (for kilobits and kilobytes respectively),
never KB or Kb. k is kilo, K is Karat.
By convention, the k for kilo is permitted to be in either case.
The M for mega is *never* lower case, as that means milli.
So mb means millibit, which one wonders what that could be.
A byte is not universally 8 bits, by the way.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka wrote:
[snip]
Contextually though, they are completely different - like oh say using
the acronym *IDE* , which can be Integrated Device Electronics -or-
Integrated Development Environment ((in most 'computer' circles) and
completely dependent upon the context of it's use).
oh, the heck with it, lol ;-)
Umm, it should be ATA, not IDE. IDE is a packaging issue, while
ATA is an interface spec.
[snip]
BTW - if anyone's a Jeweler, would the 'K' (Karat) ever be used in
combination with a 'B' ? (capital or lowercase)and I never could
remember if Karat is with a 'K' or a 'C' :doh:
Well, I used to work as a watchmaker, and I can't think of any
context where KB stands together as written with K meaning
karat.
Note that carat and karat are both words, but they mean
different things. The first is the name of the unit of weight
for gem stones, the latter is the name for the unit of fineness
of gold in 1/24 parts.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Matus UHLAR - fantomas wrote:
On 16.04.06 22:56, Willie Wonka wrote:
Explained another way (hopefully);
If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes*
No. The big 'K' stands for 1024, 1000 is small 'k'.
The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'.
Nope. Both the K and the k have been used in electronics
to mean times 1000 since I got involved in about 1965 or so.
[snip]
Luckily, HDD manufacturers count with KB/KiB (1024B)'s, so 10GB HDD was
counted as 1 000 000 KB - 1 024 000 000 Bytes. This was because HDD's use
512B sectors, and it's easier to divide number of sectors by 2 than to
multiply it by 512.
HDD manufacturers do all kinds of things with numbers.
Mike
--
p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Mike McCarty [EMAIL PROTECTED] writes: Nope. Both the K and the k have been used in electronics to mean times 1000 since I got involved in about 1965 or so. That might be. But, SI standard only knows about k. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. But this can't be applied for 'M' because big 'M' is 1 000 000, while smal 'm' is 0.001 (1/1000). 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* Luckily, HDD manufacturers count with KB/KiB (1024B)'s, so 10GB HDD was counted as 1 000 000 KB - 1 024 000 000 Bytes. This was because HDD's use 512B sectors, and it's easier to divide number of sectors by 2 than to multiply it by 512. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Mon, Apr 17, 2006 at 07:32:50AM -0700, Willie Wonka wrote: Andrei Popescu wrote: Willie Wonka [EMAIL PROTECTED] wrote: 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' The cylinder/track/sector used to make sense in the ancient days of DOS floppy disks. The addressing technique was build into the hardware, and into the software. I can still remember programming with data structures containing cylinder/head/sector numbers. But hardware improved, eventually its capacity exceeded the old geometrical mode, so they had to fake it. Software still accepted the CHS model, so the hardware had to, too, even though it became increasingly uncoupled form the physical layout. Numbers like '63' became a codeword that indicated, ignore this number as meaningless in terms of disk geometry. Then came linear block addressing, which officially accepted the demise of the geometry as a programming model. -- hendrik ~$ sudo hdparm -I /dev/hda Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors:4128705 LBAuser 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Matus UHLAR - fantomas wrote: On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. But this can't be applied for 'M' because big 'M' is 1 000 000, while smal 'm' is 0.001 (1/1000). So what do you propose as a solution ?? Maybe I'm dense, but; kb = kilobit KB = KiloByte mb = megabit MB = MegaByte 1 bit * 8 = 1 byte 1 Byte / 8 = 1 bit This is even more of a hot button issue since the advent of SATA and PCI-Express and Serial signaling rates across interfaces. E.g.; Serial ATA (SATA) data transfer rate specification = 1500 *mbps* or *mb/sec* (megabits per second). 1500 / 8 = 187.5 *MBps* or *MB/sec* - but since 8/10b encoding is used, the actual data transfer rate drops 20% - so the nominal/useful rate ends up being 150 *MB/sec* now, if you look up - you'll notice 150MB and 1500mb (which are both correct) - and SATA II specs (while not yet set in stone) are 300MB and 3000mbps. This also appears incorrect since 3000mbps / 8 = 375MBps (not 300), but many people do NOT account for the 8/10b encoding conversion, so they end up writing ALL sorts of differing specs about Transfer rates (the big Tel-Co(s) are great at this game). 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* Luckily, HDD manufacturers count with KB/KiB (1024B)'s, so 10GB HDD was counted as 1 000 000 KB - 1 024 000 000 Bytes. This was because HDD's use 512B sectors, and it's easier to divide number of sectors by 2 than to multiply it by 512. Luckily ? I think not Why would I want to divide sectors anyway. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Matus UHLAR - fantomas [EMAIL PROTECTED] wrote: On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. But this can't be applied for 'M' because big 'M' is 1 000 000, while smal 'm' is 0.001 (1/1000). 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* Luckily, HDD manufacturers count with KB/KiB (1024B)'s, so 10GB HDD was counted as 1 000 000 KB - 1 024 000 000 Bytes. This was because HDD's use 512B sectors, and it's easier to divide number of sectors by 2 than to multiply it by 512. No they don't. This is what fdisk reports for my 20 GB HDD: Disk /dev/hda: 20.0 GB, 20003880960 bytes 240 heads, 63 sectors/track, 2584 cylinders Regards 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]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka [EMAIL PROTECTED] wrote: Matus UHLAR - fantomas wrote: On 16.04.06 22:56, Willie Wonka wrote: Explained another way (hopefully); If you bought a 1,000 Byte (1KB) HDD - you'd lose 24 *Bytes* No. The big 'K' stands for 1024, 1000 is small 'k'. The big 'K' was chosen exactly to differ 1024 from 1000 - small 'k'. But this can't be applied for 'M' because big 'M' is 1 000 000, while smal 'm' is 0.001 (1/1000). So what do you propose as a solution ?? Maybe I'm dense, but; kb = kilobit KB = KiloByte mb = megabit MB = MegaByte 1 bit * 8 = 1 byte 1 Byte / 8 = 1 bit AFAIK the only standard abbreviations are the clasic SI. 1k = 1000, 1M=1.000.000, and so on. I don't know of any other standard. Of course, this doesn't mean it doesn't exist :) 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]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Tuesday 18 April 2006 05:31, Willie Wonka wrote: Maybe I'm dense, but; kb = kilobit KB = KiloByte mb = megabit MB = MegaByte 1 bit * 8 = 1 byte 1 Byte / 8 = 1 bit That's right, except it's kb or kB (for kilobits and kilobytes respectively), never KB or Kb. k is kilo, K is Karat. -- Paul Johnson Email and IM (XMPP Google Talk): [EMAIL PROTECTED] Jabber: Because it's time to move forward http://ursine.ca/Ursine:Jabber pgpEUZdglzaqM.pgp Description: PGP signature
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Andrei Popescu wrote: Willie Wonka [EMAIL PROTECTED] wrote: 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) Hi; Nice to see/have *any* reply in such an askewed thread (it's my fault though for even posting in this thread - after so many other branches have grown out sideways into various areas :-)). I didn't realize how large a post I created either - not to mention the fact; one of my paragraphs seem to have spontaneously regenerated/duplicated itself. :-O Your calculation is correct, but I would think the other way about this issue. Manufacturers will sell HDD of 1 TB = 1000 GB which is aprox. 931 GiB. So you loose 69 GiB for every TB. I see you're using the 93.1% rule though... To me, this is an incorrect way to calculate, since the differences in sizes, between binary and decimal values, increases as the HDD sizes increasei.e.; the larger the HDD, the larger the discrepancy between base10 and base2 - hence; 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. 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 IMHOI 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 :-) 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. 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. 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,
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
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 IMHOI 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 = 20 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
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Andrei Popescu wrote: Willie Wonka [EMAIL PROTECTED] 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 = 20 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 LBAuser 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka [EMAIL PROTECTED] wrote: 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) Actually my drive is really 20GB # hdparm -I /dev/hda ... ... device size with M = 1024*1024: 19077 MBytes device size with M = 1000*1000: 20003 MBytes (20 GB) I appreciated this dialog/dialogue :-) All I can think of now, because I'm hungry is (donuts/doughnuts/dough-nuts). Regards Me too, but I'm not hungry, at least not now (1:10 AM) Regards 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]
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: [EMAIL PROTECTED] wrote: On Sat, Apr 15, 2006 at 12:27:35PM -0500, Ron Johnson wrote: On Sat, 2006-04-15 at 06:30 -0400, [EMAIL PROTECTED] 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, etcit'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
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Willie Wonka [EMAIL PROTECTED] wrote: 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) Your calculation is correct, but I would think the other way about this issue. Manufacturers will sell HDD of 1 TB = 1000 GB which is aprox. 931 GiB. So you loose 69 GiB for every TB. 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. 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. If you make the allocation units to big you lose space (slack), if you make them too small you might hit filesystem limitations, because the address space is limited. This is why MS had to switch from FAT16 to FAT32. Because a sector is 512 B an allocation unit can not be smaller then 512 B, and is always a multiple of 512 B. 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]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
CaT wrote: Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) Similar for 468872448. If it's decimal, what's that 1024 doing there and why the odd number 156290816 for a Kibibyte? Surely they should ALL be powers of 10? Seems a tad inconsistent to me... Besides... 1024 is decimal... 2^10!!! :þ -- Blessings Wulfmann Wulf Credo: Respect the elders. Teach the young. Co-operate with the pack. Play when you can. Hunt when you must. Rest in between. Share your affections. Voice your opinion. Leave your Mark.
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Sat, 15 Apr 2006 10:25:28 +0100 Wulfy [EMAIL PROTECTED] wrote: CaT wrote: Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) Similar for 468872448. If it's decimal, what's that 1024 doing there and why the odd number 156290816 for a Kibibyte? Surely they should ALL be powers of 10? Seems a tad inconsistent to me... Besides... 1024 is decimal... 2^10!!! :þ -- Blessings Wulfmann binary, because you use powers of 2: 1 kiB = 2^10 = 1024 1 MiB = 2^10 x 2^10 = 2^20 = 1048576 and so on decimal, because you use powers of 10: 1 kB = 10^3 = 1000 1 MB = 10^3 x 10^3 = 100 and so on HDD manufacturers advertise the decimal sizes of the unformated HDD, because they are bigger ;) Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein)
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Sat, Apr 15, 2006 at 10:25:28AM +0100, Wulfy wrote: CaT wrote: Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) Similar for 468872448. If it's decimal, what's that 1024 doing there and why the odd number 156290816 for a Kibibyte? Surely they should ALL be powers of 10? Seems a tad inconsistent to me... Besides... 1024 is decimal... 2^10!!! :? because the sizes are measured in blocks originally, and a block is 1024 bytes, which is one KiB but 1.024 KB. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Sat, 2006-04-15 at 06:30 -0400, [EMAIL PROTECTED] wrote: On Sat, Apr 15, 2006 at 10:25:28AM +0100, Wulfy wrote: CaT wrote: Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) Similar for 468872448. If it's decimal, what's that 1024 doing there and why the odd number 156290816 for a Kibibyte? Surely they should ALL be powers of 10? Seems a tad inconsistent to me... Besides... 1024 is decimal... 2^10!!! :? because the sizes are measured in blocks originally, and a block is 1024 bytes, which is one KiB but 1.024 KB. 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). -- - Ron Johnson, Jr. Jefferson, LA USA Early to bed, early to rise, work like hell and advertise. -Ted Turner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Sat, Apr 15, 2006 at 12:27:35PM -0500, Ron Johnson wrote: On Sat, 2006-04-15 at 06:30 -0400, [EMAIL PROTECTED] wrote: On Sat, Apr 15, 2006 at 10:25:28AM +0100, Wulfy wrote: CaT wrote: Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) Similar for 468872448. If it's decimal, what's that 1024 doing there and why the odd number 156290816 for a Kibibyte? Surely they should ALL be powers of 10? Seems a tad inconsistent to me... Besides... 1024 is decimal... 2^10!!! :? because the sizes are measured in blocks originally, and a block is 1024 bytes, which is one KiB but 1.024 KB. 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). 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. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
[EMAIL PROTECTED] wrote: On Sat, Apr 15, 2006 at 12:27:35PM -0500, Ron Johnson wrote: On Sat, 2006-04-15 at 06:30 -0400, [EMAIL PROTECTED] 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. 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). 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. Powers of two are fairly obvious from a hardware point of view. man mkfs Paul Scott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Sat, 2006-04-15 at 15:54 -0700, Paul Scott wrote: [EMAIL PROTECTED] wrote: On Sat, Apr 15, 2006 at 12:27:35PM -0500, Ron Johnson wrote: On Sat, 2006-04-15 at 06:30 -0400, [EMAIL PROTECTED] 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. 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). 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. Powers of two are fairly obvious from a hardware point of view. -- - Ron Johnson, Jr. Jefferson, LA USA Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible Calvin, regarding TV -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
Ron Johnson [EMAIL PROTECTED] writes: On Wed, 2006-04-12 at 12:32 -0400, Matthias Julius wrote: Yes, there is. As example here is part of the output of mdadm: Array Size : 468872448 (447.15 GiB 480.13 GB) Device Size : 156290816 (149.05 GiB 160.04 GB) ^^^^^ Note there is GiB (gibibyte) which is 1024 MiB (mebibyte) and there is GB (gigabyte) which is 1000 MB (megabyte). If GB is decimal, then why aren't the sizes 468.87 GB 156.29 GB Why should they be? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Thu, Apr 13, 2006 at 09:18:17AM -0400, Matthias Julius wrote: On Wed, 2006-04-12 at 12:32 -0400, Matthias Julius wrote: Yes, there is. As example here is part of the output of mdadm: Array Size : 468872448 (447.15 GiB 480.13 GB) Device Size : 156290816 (149.05 GiB 160.04 GB) ^^^^^ Note there is GiB (gibibyte) which is 1024 MiB (mebibyte) and there is GB (gigabyte) which is 1000 MB (megabyte). If GB is decimal, then why aren't the sizes 468.87 GB 156.29 GB Why should they be? Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) Similar for 468872448. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Friday 14 April 2006 03:02, CaT wrote: On Thu, Apr 13, 2006 at 09:18:17AM -0400, Matthias Julius wrote: On Wed, 2006-04-12 at 12:32 -0400, Matthias Julius wrote: Yes, there is. As example here is part of the output of mdadm: Array Size : 468872448 (447.15 GiB 480.13 GB) Device Size : 156290816 (149.05 GiB 160.04 GB) ^^^^^ Note there is GiB (gibibyte) which is 1024 MiB (mebibyte) and there is GB (gigabyte) which is 1000 MB (megabyte). If GB is decimal, then why aren't the sizes 468.87 GB 156.29 GB Why should they be? Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) You're getting your sizes confused, you either use base 2 or base 10, not both. 1024/1024/1024/1024 is the right equation. -- Paul Johnson Email and IM (XMPP Google Talk): [EMAIL PROTECTED] Jabber: Because it's time to move forward http://ursine.ca/Ursine:Jabber pgpPLJOjlJyyH.pgp Description: PGP signature
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Fri, 14 Apr 2006 08:06:53 -0700 Paul Johnson [EMAIL PROTECTED] wrote: On Friday 14 April 2006 03:02, CaT wrote: On Thu, Apr 13, 2006 at 09:18:17AM -0400, Matthias Julius wrote: On Wed, 2006-04-12 at 12:32 -0400, Matthias Julius wrote: Yes, there is. As example here is part of the output of mdadm: Array Size : 468872448 (447.15 GiB 480.13 GB) Device Size : 156290816 (149.05 GiB 160.04 GB) ^^^^^ Note there is GiB (gibibyte) which is 1024 MiB (mebibyte) and there is GB (gigabyte) which is 1000 MB (megabyte). If GB is decimal, then why aren't the sizes 468.87 GB 156.29 GB Why should they be? Because dividing by a multpile of 10 essentially simply moves the decimal point to the left. The thing that's not bleedingly obvious there though is that 156290816 is in kibibytes. :) So: 156290816 * 1024 / 1000 / 1000 / 1000 ~= 160.04 GB :) You're getting your sizes confused, you either use base 2 or base 10, not both. 1024/1024/1024/1024 is the right equation. It was just right. This is more in detail: 156290816(kiB) * 1024 = 160041795584 bytes 160041795584/1000/1000/1000 ~= 160.04 GB or 160041795584/1024/1024/1024 ~= 149.05 GiB 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]
Re: RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On 4/14/06, Andrei Popescu [EMAIL PROTECTED] wrote: On Wed, 2006-04-12 at 12:32 -0400, Matthias Julius wrote: Yes, there is. As example here is part of the output of mdadm: Array Size : 468872448 (447.15 GiB 480.13 GB) Device Size : 156290816 (149.05 GiB 160.04 GB) ^^^^^ Note there is GiB (gibibyte) which is 1024 MiB (mebibyte) and there is GB (gigabyte) which is 1000 MB (megabyte). It was just right. This is more in detail: 156290816(kiB) * 1024 = 160041795584 bytes 160041795584/1000/1000/1000 ~= 160.04 GB or 160041795584/1024/1024/1024 ~= 149.05 GiB This is an example of how just slightly better command output or logging could save many man-hours of confusion or explanation. Since the mdadm program displays the values in two human readable forms (GB and GiB), it could also print the first number as a raw count of bytes (with the suffix bytes) to make the size of the array entirely clear and precise to the user.
RAID Sizes (was Re: Why do people in the UK put a u in the word color?)
On Wed, 2006-04-12 at 12:32 -0400, Matthias Julius wrote: David R. Litwin [EMAIL PROTECTED] writes: To put it into perspective, what we think of the Metric system is what the rest of the world thinks of English measure. A gigabyte is 1024 MB, not 1000, dammit! Really? There is a metric byte-system? I've never heard of such a thing. I even live in Canada and use the metric system! Yes, there is. As example here is part of the output of mdadm: Array Size : 468872448 (447.15 GiB 480.13 GB) Device Size : 156290816 (149.05 GiB 160.04 GB) ^^^^^ Note there is GiB (gibibyte) which is 1024 MiB (mebibyte) and there is GB (gigabyte) which is 1000 MB (megabyte). If GB is decimal, then why aren't the sizes 468.87 GB 156.29 GB -- - Ron Johnson, Jr. Jefferson, LA USA Capital as such is not evil; it is its wrong use that is evil. Capital in some form or other will always be needed. Mohandas Karamchand Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
