Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
How many hard disks can be attached to a Macintosh System?
- Thread starter naveen
- Start date
- Sort by reaction score
To all intents and purposes it's infinite! You are basically limited by what the busses will support. So on a PowerMac G5 (for example) you have space (and SATA channels) for 2 disks. In addition you can attack discs to the USB and FireWire buses. A USB bus can support up to 127 devices, all of which can be disks (assuming you have a boat load of hubs). iirc each port is on it's own bus so you can hang 127 disks off each USB port. Of course this would be a bad idea as all the disks would share the bandwidth. I'm not sure what the single bus limit for FireWire is, but I think it's similar to USB.
The FireWire bus limit is 63, with an additional limit of 16 devices in one daisy chain.robbieduncan said:
take the G5, you get 2 SATA bays (max 400GB/disk for now) you can add 2 SATA drives with for instance the G5jam (lose the first of the PCI slots) then you can add disks onto the USB2.0 ports (combined with hubs and so...) then you have both the FW400 & 800 ports... kill them to the fullest... get another PCI USB/FW card-> lose one more slot & add a lot more drives... if you're not broke then, get a fibrechannel card and an Xserve Raid ... ok by now you schould be broke, have a lot of storage, so ow we come to the final question: will you need this much drives/storage??? will you be able to max out your mac and still be in the need of more storage???
I think this was a silly question ;-)
-edit-
hmm
just been thinking: take the G5 put 2 SATA 400GB drives inside, buy 3 5,6TB Xserve Raids + the pcicards (17,6TB so far)
then we will max out the FW ports (2x FW400 + 1xFW800) someone mentioned: 16 devices/port = 48, ok we buy 48 1,6TB BiggerDisks (another 76,8TB)
then we have our USB2 channel (we don't care about speed decrease, its all about how much ;-) ) with the number stated here (being 127) and get a lot of hubs :-S and buy 1TB triple interface Bigger disks (127 of them -> 127TB)
well we end up with 221,4 TB hmm I think that's enough ;-)
-edit-
-edit2-
when buying FW hubs... we can increase the total of drives to 189 (302,4TB) so theoretically we now come to 430,2 TB
so I can state: you will never out max your Mac, so don't worry, enough expansion here ;-)
-edit2-
I think this was a silly question ;-)
-edit-
hmm
just been thinking: take the G5 put 2 SATA 400GB drives inside, buy 3 5,6TB Xserve Raids + the pcicards (17,6TB so far)
then we will max out the FW ports (2x FW400 + 1xFW800) someone mentioned: 16 devices/port = 48, ok we buy 48 1,6TB BiggerDisks (another 76,8TB)
then we have our USB2 channel (we don't care about speed decrease, its all about how much ;-) ) with the number stated here (being 127) and get a lot of hubs :-S and buy 1TB triple interface Bigger disks (127 of them -> 127TB)
well we end up with 221,4 TB hmm I think that's enough ;-)
-edit-
-edit2-
when buying FW hubs... we can increase the total of drives to 189 (302,4TB) so theoretically we now come to 430,2 TB
so I can state: you will never out max your Mac, so don't worry, enough expansion here ;-)
-edit2-
It's not 16 per port, it's 16 per chain. That means that devices before a branch in the daisy chain count towards the limit for all chains connected to them, whereas devices after a branch count only toward that branch's 16 device limit. This means that a configuration like this would be perfectly legal:Jo-Kun said:
Code:
CPU
|
1--2--3--4--5--6--7--8--9--10-11-12-13-14-15-16
| | | | | | | | | |
62 53 45 38 32 27 23 20 18 17
| | | | | | | | |
63 54 46 39 33 28 24 21 19
| | | | | | |
55 47 40 34 29 25 22
| | | | | |
56 48 41 35 30 26
| | | | |
57 49 42 36 31
| | | |
58 50 43 37
| | |
59 51 44
| |
60 52
|
61
Hector said:
Yup, each one with its own drive controller...
Basically, you can keep on going...and going... and going... until the filesystem cannot encode any more but that is somewhere around 16 TB I think, or maybe 32 TB... a hell of a lot of songs in iTunes!
If the space on the desk isn't too big...
How Big is your wallet?
Let's see, three free PCI-X slots means 3 Fibre Channel cards (@ $499 = $1500)
With 3 5.6TB XServe Raid Units (@ $12,999 = $39,000).
So for about $45000 you can add 16,800 GB on 42 drives to your computer in a compact space using these...
At which point it would probably be a good idea to be running Mac OS X Server with XSan on some XServes for redundancy.
How Big is your wallet?
Let's see, three free PCI-X slots means 3 Fibre Channel cards (@ $499 = $1500)
With 3 5.6TB XServe Raid Units (@ $12,999 = $39,000).
So for about $45000 you can add 16,800 GB on 42 drives to your computer in a compact space using these...
At which point it would probably be a good idea to be running Mac OS X Server with XSan on some XServes for redundancy.
trailblazer said:dont forget all the space you'd loose to formatting
no DO forget, its nicer when bragging about your way to expensive system of storage you will not be needing ;-)
and with this much storage I think you'll better buy one of these server racks to reduce space of your external storage system, and don't worry if you want to spend your money on FW/USB drives, you can convert LaCie's D2 series into a rackmount solution ;-)
Odd question, amusing answers. I wonder if there's a limit to the number of logical volumes OSX can address? I assume there is, though it's no doubt quite high. I know the max size for an individual HFS+volume is somewhere in the exabyte range (8EB?), so that's another limit to consider if you're getting theoretical.
Manufacturers calculate 1GB = 1,000,000,000 bytes, where for some archaic reason most major OSes calculate 1GB = 1024bytes/KB X 1024KB/MB X 1024MB/GB = 1,073,741,824 bytes. These "OS Gigabytes" are also sometimes called Gibibytes.
So a 120GB drive has 120 / 1.073 = 111.75GB of space according to the OS.
Actually, do forget, because it's not that much; unless I'm quite mistaken, most of the space "lost" between quoted capacity (say, 120GB) and formatted capacity (say, 112GB) is not due to the format, which only takes a few MB, but the fact that the OS calculates drive size in a different way than the drive manufacturerers.trailblazer said:dont forget all the space you'd loose to formatting
Manufacturers calculate 1GB = 1,000,000,000 bytes, where for some archaic reason most major OSes calculate 1GB = 1024bytes/KB X 1024KB/MB X 1024MB/GB = 1,073,741,824 bytes. These "OS Gigabytes" are also sometimes called Gibibytes.
So a 120GB drive has 120 / 1.073 = 111.75GB of space according to the OS.
Makosuke said:
I thought it was because the OS had to draw the "lines in the empty parking lot so the cars would know where to park". (My own metaphor)
So in a 120 GB drive it needed about 8 GB for the formatted directory. Please clear this up because I hate when I believe a lie for so long!
If you see that "Gibibytes" are derived from binary (since 2^10=1024, and 1024 is as close to 1000 as you can get in exact powers of 2), then "OS Gigabytes" aren't archaic at all - rather, they're represented that way because computers don't know what base 10 (our decimal system) is - all they know is base 2 (binary, or 0's and 1's).Makosuke said:
EDIT:
Les Kern:
Computers count everything in binary terms (0's and 1's); we use decimal terms (0 through 9). Therefore, rough equivalents like 1000=1024 have been made to "simplify" things for those of us who don't understand binary. Unfortunately, those "rough equivalents" are the same reason why formatted capacity and quoted capacity differ so much - those little inaccuracies in the equivalencies add up as the scale increases.
Here's an analysis of the inaccuracy of the rough equivalency 1000=1024 at different scales:
At a scale of 1 (bytes), the equivalency is not applicable.
At 1000 (kilobytes), it over-estimates by 24 bytes.
At 1,000,000 (megabytes), it over-estimates by 48,576 bytes.
At 1,000,000,000 (gigabytes), it over-estimates by 73,741,824 bytes.
At 1,000,000,000,000 (terabytes), it over-estimates by 99,511,627,776 bytes.
All of these error values need to be multiplied by the size of the disk in question (and converted to the appropriate scale). To convert bytes to kilobytes, divide by 1024. Bytes to megabytes: divide by 1024^2. Bytes to gigabytes: divide by 1024^3. Bytes to terabytes: divide by 1024^4.
These error values were computed using the following method:
Scale values (SV):
0=bytes 1=kilobytes 2=megabytes 3=gigabytes 4=terabytes etc.
1024^SV - 1000^SV
At a scale of 1 (bytes), the equivalency is not applicable.
At 1000 (kilobytes), it over-estimates by 24 bytes.
At 1,000,000 (megabytes), it over-estimates by 48,576 bytes.
At 1,000,000,000 (gigabytes), it over-estimates by 73,741,824 bytes.
At 1,000,000,000,000 (terabytes), it over-estimates by 99,511,627,776 bytes.
All of these error values need to be multiplied by the size of the disk in question (and converted to the appropriate scale). To convert bytes to kilobytes, divide by 1024. Bytes to megabytes: divide by 1024^2. Bytes to gigabytes: divide by 1024^3. Bytes to terabytes: divide by 1024^4.
These error values were computed using the following method:
Scale values (SV):
0=bytes 1=kilobytes 2=megabytes 3=gigabytes 4=terabytes etc.
1024^SV - 1000^SV
I'm sorry but it's true that 1GB HD style = 0.93GB OS style and it's correct as they say in this thread that the OS uses gibibytes (giga binary bytes) which is 2^30 = 1.0737 GB.Les Kern said:
The OS also has to draw lines in the empty parking lot, but that is only half the reason why harddrives "lose" so much capacity when viewed by an OS.