Ah, my bad--I hadn't realized mdadm had the -G (grow) option. Durr to me, I should rtfm more closely next time;) Using mdadm -G would be a much simpler option than hacking together a complex LVM setup.
With Linux you can create a RAID5 md device, say/dev/md0, then run LVM on top of that (pvcreate/dev/md0 ; vgcreate MyVgName/dev/md0) and use that to carve out your storage. The key here is to create partitions on each drive, eg filling up the entire disk, and create your raid5 with those.
If you buy 1TB drives further down the road, here's what you do- With each disk, create a partition identical in size to the partitions on the smaller disks, then allocate the rest of the space to a second partition. Join the first partition of the disk to the existing RAID set. Let it rebuild. Swap the next drive, etc. etc. Then once you've done this switcharoo to all the drives, create another raid set using the 2nd partition on your new disks--call it/dev/md1. So now you have/dev/md0, pointing to the first 500GB of each disk, and/dev/md1, pointing to the 2nd 500GB of each disk.
Take that/dev/md1 and graft it onto your LVM volume group. (pvcreate/dev/md1 ; vgextend MyVgName/dev/md1). Now your LVM VG just doubled in size, and you can use all that new space. Whatever you do though, do NOT create any "striped" logical volumes (the "-i2" option to lvcreate; LVM's Poor Man's RAID0, basically) because you will suffer terrible performance, since you'll be striping across different volumes on the same physical spindles (a big no-no for any striped configuration). But if you use the extra space by creating new filesystems or growing existing ones, you shouldn't see any trouble.
Just be sure that any replacement drives you have to buy... you must partition them out similarly. I'd recommend pulling back on the partition sizes a bit, maybe 5%, to account for any size differences between the drives you bought right now and some replacement drives you may purchase later on which might be slightly lower in capacity (different drive manufacturers often have differing exact capacities).
Another curious idea I have, though... is what happens if you use SATA-II disks, but only use 1/2 of the disk (the half closest to the outer tracks). A 500GB SATA-II disk would yield 250GB if you only used half the disk, but since your seek times are now cut in half, how does the performance stack up against a similarly-sized ~300GB 10K SCSI/FC/SAS disk? If they're similar (would really like to see this proven out...), one could make the argument that you can get by with lots of inexpensive SATA disks, but only half of them in use, at least during peak usage times. The other half of the disk could be reserved for off-peak bulk I/O, such as backups.
You wouldn't use 'fewer' disks that are faster, you'd use more disks since the faster disks would be smaller than the SATA disks. They don't make 10,000 RPM 500GB disks yet. They do, however, make 300GB disks at 10,000 RPM.
A 48-disk SATA-II (500GB) solution may give you 20TB. A similar amount of capacity (20TB) using 300GB 10K-rpm FC disks would require around 80 disks. The cost would obviously be much higher--each disk is much pricier than the SATA-II disks, on top of the fact that you need 66% more spindles. But the access density would be around 2.5-3x higher for the 300GB FC solution compared to the SATA solution. So for the same amount of capacity, you can slam it ~2-3x harder.
(the math, using some 'generous' numbers for the IOPS: assuming a 500GB SATA-II 7200rpm disk can do ~75 IOPS, a 300GB FC 10K RPM drive can do ~120 IOPS... 48*75 = 3600 IOPS in total for the SATA solution, 80*120 = 9600 IOPS in total for the FC solution)
Now, is it worth it? Depends on the application. For lots of databases using the same storage concurrently, you bet it'll be worth it--might even want to step things up to the 146GB 15K disks, requiring double the spindles of the 300GB FC solution (160 spindles) but possibly 8x the throughput of the SATA solution.
For backups, or streaming media... the SATA solution may very well be good enough.
"but a HELL of a lot more expensive, and not worth paying more than double per gig."
If capacity is what you're after, then you are right--bulky 7200 rpm drives are the way to go, whether it's SATA or low-cost FC or whatnot. If you need "access density"--a blanket term referring to the available random IOPS per unit of disk space--then you need to shell out the bucks for 10+K RPM disks, eg SCSI/SAS/FC (which also provide features like Tagged Command Queueing to improve IOPS). It's great that you have 20TB of storage, but what if you have dozens of database servers concurrently slamming different parts of that 20TB with wildly random I/O?
A sensible storage design will consider the priorities of access density vs. storage capacity, and integrate cost into the whole equation.
On another note, though, there are the WD Raptor drives-- 10K RPM SATA-II disks which utilize SATA-II's NCQ (similar to TCQ). That is a nice option, shame they're the only player in town for 10K RPM SATA...
Can most people detect when they're getting a cold? I always notice, just before the cold symptoms begin, a distinct baseline smell in my nose which does not come from the environment around me--it's always there no matter where I am or what I'm smelling. I also notice a different scent when I experience sunburn, and a different one yet when I have a bacterial infection (major cut, sinuses, etc.)
You mean, American car companies insist on that. Japanese cars usually don't work that way and I see tons of them driven around here, myself included (USA).
I know Linux software RAID1 lets you do this. In addition, don't you get a little extra benefit from this in the form of further improvements in multithreaded reads? (ability to service up to 3 read requests simultaneously, although it doesn't help you at all for writes...)
In terms of fossil fuel emissions, gas furnaces are far more efficient than electricity for this reason alone- http://en.wikipedia.org/wiki/Coal
Note the 30% efficiency number. We'll round it up to 33.333...% for this discussion.
For every 1 BTU of electric heat you generate in your house, 2x that same amount gets dumped out into the atmosphere by your friendly neighborhood Coal-fired power plant. Nuclear is just as bad if not worse in some cases, only it doesn't produce fossil fuel (CO2/CO/etc.) emissions, just heat.
Whereas with a gas furnace, for every bit of fossil fuel exhaust emitted (albeit this does NOT include energy expended in transporting the gas...), almost all of it goes towards heating your house, not heating the atmosphere.
"essentially filled with concrete" is open for interpretation--it was filled but he didn't specify if it was filled to the top. You could probably get by with filling it 1/8th the way or less.
Ubuntu 6.06 LTS installed 64-bit firefox by default, which disallowed me from using flash. I had to go through a procedure (found off ubuntuforums.org) to install 32-bit firefox (involved editing some Pango-related file)
Yeah, this is a much better idea. That 'average draw', although high, could work out more favorably for the power companies because it would give them a stable power generation requirement, rather than wasting power or shutting off the turbines when there is no demand.
Are engines 50% efficient? I've always heard the figure that most car engines never exceed ~20-25% efficiency, and usually lie below 20%... which would provide more favorably for the electric car's calculations (ie it won't need as much power as you computed above) but still wouldn't make it practical enough.
Could you explain the math here? I did the math some time ago and came up with roughly the same figure as the OP... ie gasoline is only STARTING to approach electricity's price-per-kWH, before it was lower.
Of course, the problem with that is people will charge their car at full current draw from the circuit breaker, which is not an "even swap" since most houses don't max out the circuit breaker at any time during the day...
Combine that with the rising cost of solar technology (Germany and Japan are fueling high demand there), and you have a flop of a plan.
He's saying charge your car using the utility power grid, but power your house with solar panels -- "Then, it essentially takes their house off the grid and puts the car on the grid at an even swap." (wasn't too obvious the first time I read it)
I guess with batteries that can provide adequate range with acceptable size and mass, the question is the recharge... there's just nothing quite like pumping a few gallons of liquid compared to having a car sit there plugged into the wall for 5 hours.
The experience I had with another user was that the sound drivers in Windows sucked whereas they sounded much clearer in Linux under ALSA (w/ OSS emulation). Windows was causing all sorts of issues (excessive echo, some god-awful interference-like noise, frequent breaking up, etc.) which were partially solved by a driver upgrade, but completely solved by using Linux. Granted the sound chipset was some cheap onboard Realtek AC97 thing...
Skype supports multiple platforms (Windows, Linux, MacOS X, PocketPC w/ WiFi). I use it under Linux (using the version one step back from the latest, since the latest has bugs) and it works beautifully. Plus it uses some form of technique (a P2P network) to get around firewall limitations as much as possible. As I understand it, the CODECs it uses (probably along with the network stack) are provided by http://www.globalipsound.com/ (in a PC-to-PC skype call it says the "ISAC" codec is being used-- http://www.globalipsound.com/datasheets/iSAC.pdf)
They have the SkypeOut/SkypeIn service which allows you to make outgoing calls, and SkypeIn allows you to own a telephone number in a number of different countries (USA, UK, France, Hong Kong, Denmark, Finland, Sweden, Poland currently) which link to your account. When you're using these I don't think Skype uses the ISAC codec, it uses something with crappier quality.
(note: I don't work for them, I've just been a happy customer for the past few months, especially with the Linux support.)
Wrong again. Try "ia64" for Intel's first 64-bit architecture, Itanium, aka Itanic, which is a niche product used more for business (and a royal pain in the arse, if I may say so).
Try "x86_64" for AMD's 64-bit architecture (although AMD is pushing "AMD64" as the name I believe?) Intel's new 64-bit in these EM64t chips is a compatibility with AMD64 (aka x86_64).
Slashdot Mirror
Ah, my bad--I hadn't realized mdadm had the -G (grow) option. Durr to me, I should rtfm more closely next time ;) Using mdadm -G would be a much simpler option than hacking together a complex LVM setup.
With Linux you can create a RAID5 md device, say /dev/md0, then run LVM on top of that (pvcreate /dev/md0 ; vgcreate MyVgName /dev/md0) and use that to carve out your storage. The key here is to create partitions on each drive, eg filling up the entire disk, and create your raid5 with those.
/dev/md1. So now you have /dev/md0, pointing to the first 500GB of each disk, and /dev/md1, pointing to the 2nd 500GB of each disk.
/dev/md1 and graft it onto your LVM volume group. (pvcreate /dev/md1 ; vgextend MyVgName /dev/md1). Now your LVM VG just doubled in size, and you can use all that new space. Whatever you do though, do NOT create any "striped" logical volumes (the "-i2" option to lvcreate; LVM's Poor Man's RAID0, basically) because you will suffer terrible performance, since you'll be striping across different volumes on the same physical spindles (a big no-no for any striped configuration). But if you use the extra space by creating new filesystems or growing existing ones, you shouldn't see any trouble.
If you buy 1TB drives further down the road, here's what you do- With each disk, create a partition identical in size to the partitions on the smaller disks, then allocate the rest of the space to a second partition.
Join the first partition of the disk to the existing RAID set. Let it rebuild. Swap the next drive, etc. etc. Then once you've done this switcharoo to all the drives, create another raid set using the 2nd partition on your new disks--call it
Take that
Just be sure that any replacement drives you have to buy... you must partition them out similarly. I'd recommend pulling back on the partition sizes a bit, maybe 5%, to account for any size differences between the drives you bought right now and some replacement drives you may purchase later on which might be slightly lower in capacity (different drive manufacturers often have differing exact capacities).
Another curious idea I have, though... is what happens if you use SATA-II disks, but only use 1/2 of the disk (the half closest to the outer tracks). A 500GB SATA-II disk would yield 250GB if you only used half the disk, but since your seek times are now cut in half, how does the performance stack up against a similarly-sized ~300GB 10K SCSI/FC/SAS disk? If they're similar (would really like to see this proven out...), one could make the argument that you can get by with lots of inexpensive SATA disks, but only half of them in use, at least during peak usage times. The other half of the disk could be reserved for off-peak bulk I/O, such as backups.
You wouldn't use 'fewer' disks that are faster, you'd use more disks since the faster disks would be smaller than the SATA disks. They don't make 10,000 RPM 500GB disks yet. They do, however, make 300GB disks at 10,000 RPM.
A 48-disk SATA-II (500GB) solution may give you 20TB. A similar amount of capacity (20TB) using 300GB 10K-rpm FC disks would require around 80 disks. The cost would obviously be much higher--each disk is much pricier than the SATA-II disks, on top of the fact that you need 66% more spindles. But the access density would be around 2.5-3x higher for the 300GB FC solution compared to the SATA solution. So for the same amount of capacity, you can slam it ~2-3x harder.
(the math, using some 'generous' numbers for the IOPS: assuming a 500GB SATA-II 7200rpm disk can do ~75 IOPS, a 300GB FC 10K RPM drive can do ~120 IOPS... 48*75 = 3600 IOPS in total for the SATA solution, 80*120 = 9600 IOPS in total for the FC solution)
Now, is it worth it? Depends on the application. For lots of databases using the same storage concurrently, you bet it'll be worth it--might even want to step things up to the 146GB 15K disks, requiring double the spindles of the 300GB FC solution (160 spindles) but possibly 8x the throughput of the SATA solution.
For backups, or streaming media... the SATA solution may very well be good enough.
"but a HELL of a lot more expensive, and not worth paying more than double per gig."
If capacity is what you're after, then you are right--bulky 7200 rpm drives are the way to go, whether it's SATA or low-cost FC or whatnot.
If you need "access density"--a blanket term referring to the available random IOPS per unit of disk space--then you need to shell out the bucks for 10+K RPM disks, eg SCSI/SAS/FC (which also provide features like Tagged Command Queueing to improve IOPS). It's great that you have 20TB of storage, but what if you have dozens of database servers concurrently slamming different parts of that 20TB with wildly random I/O?
A sensible storage design will consider the priorities of access density vs. storage capacity, and integrate cost into the whole equation.
On another note, though, there are the WD Raptor drives-- 10K RPM SATA-II disks which utilize SATA-II's NCQ (similar to TCQ). That is a nice option, shame they're the only player in town for 10K RPM SATA...
Can most people detect when they're getting a cold? I always notice, just before the cold symptoms begin, a distinct baseline smell in my nose which does not come from the environment around me--it's always there no matter where I am or what I'm smelling. I also notice a different scent when I experience sunburn, and a different one yet when I have a bacterial infection (major cut, sinuses, etc.)
You mean, American car companies insist on that. Japanese cars usually don't work that way and I see tons of them driven around here, myself included (USA).
I know Linux software RAID1 lets you do this. In addition, don't you get a little extra benefit from this in the form of further improvements in multithreaded reads? (ability to service up to 3 read requests simultaneously, although it doesn't help you at all for writes...)
In terms of fossil fuel emissions, gas furnaces are far more efficient than electricity for this reason alone-
http://en.wikipedia.org/wiki/Coal
Note the 30% efficiency number. We'll round it up to 33.333...% for this discussion.
For every 1 BTU of electric heat you generate in your house, 2x that same amount gets dumped out into the atmosphere by your friendly neighborhood Coal-fired power plant. Nuclear is just as bad if not worse in some cases, only it doesn't produce fossil fuel (CO2/CO/etc.) emissions, just heat.
Whereas with a gas furnace, for every bit of fossil fuel exhaust emitted (albeit this does NOT include energy expended in transporting the gas...), almost all of it goes towards heating your house, not heating the atmosphere.
"essentially filled with concrete" is open for interpretation--it was filled but he didn't specify if it was filled to the top. You could probably get by with filling it 1/8th the way or less.
Can't you grow an XFS online already? In fact, that's the only way you can grow an XFS filesystem... with it mounted.
Ubuntu 6.06 LTS installed 64-bit firefox by default, which disallowed me from using flash. I had to go through a procedure (found off ubuntuforums.org) to install 32-bit firefox (involved editing some Pango-related file)
Yeah, this is a much better idea. That 'average draw', although high, could work out more favorably for the power companies because it would give them a stable power generation requirement, rather than wasting power or shutting off the turbines when there is no demand.
Imagine the size of a megawatt-hour capacitor!
Are engines 50% efficient? I've always heard the figure that most car engines never exceed ~20-25% efficiency, and usually lie below 20%... which would provide more favorably for the electric car's calculations (ie it won't need as much power as you computed above) but still wouldn't make it practical enough.
Could you explain the math here? I did the math some time ago and came up with roughly the same figure as the OP... ie gasoline is only STARTING to approach electricity's price-per-kWH, before it was lower.
The second challenge there would be a power infrastructure capable of supporting many thousands of fast recharges like that.
How do they know you're in Europe? Certainly not by your profile, right?
Of course, the problem with that is people will charge their car at full current draw from the circuit breaker, which is not an "even swap" since most houses don't max out the circuit breaker at any time during the day...
Combine that with the rising cost of solar technology (Germany and Japan are fueling high demand there), and you have a flop of a plan.
He's saying charge your car using the utility power grid, but power your house with solar panels -- "Then, it essentially takes their house off the grid and puts the car on the grid at an even swap."
(wasn't too obvious the first time I read it)
How about something like this?
http://www.europositron.com/en/index.html
Seems promising, if a bit vapor at the moment.
I guess with batteries that can provide adequate range with acceptable size and mass, the question is the recharge... there's just nothing quite like pumping a few gallons of liquid compared to having a car sit there plugged into the wall for 5 hours.
This has been my experience as well. Skype works really well for me (under Linux) and the quality is unprecedented.
The experience I had with another user was that the sound drivers in Windows sucked whereas they sounded much clearer in Linux under ALSA (w/ OSS emulation). Windows was causing all sorts of issues (excessive echo, some god-awful interference-like noise, frequent breaking up, etc.) which were partially solved by a driver upgrade, but completely solved by using Linux. Granted the sound chipset was some cheap onboard Realtek AC97 thing...
Skype supports multiple platforms (Windows, Linux, MacOS X, PocketPC w/ WiFi). I use it under Linux (using the version one step back from the latest, since the latest has bugs) and it works beautifully. Plus it uses some form of technique (a P2P network) to get around firewall limitations as much as possible. As I understand it, the CODECs it uses (probably along with the network stack) are provided by http://www.globalipsound.com/ (in a PC-to-PC skype call it says the "ISAC" codec is being used-- http://www.globalipsound.com/datasheets/iSAC.pdf)
They have the SkypeOut/SkypeIn service which allows you to make outgoing calls, and SkypeIn allows you to own a telephone number in a number of different countries (USA, UK, France, Hong Kong, Denmark, Finland, Sweden, Poland currently) which link to your account. When you're using these I don't think Skype uses the ISAC codec, it uses something with crappier quality.
(note: I don't work for them, I've just been a happy customer for the past few months, especially with the Linux support.)
Wrong again. Try "ia64" for Intel's first 64-bit architecture, Itanium, aka Itanic, which is a niche product used more for business (and a royal pain in the arse, if I may say so).
Try "x86_64" for AMD's 64-bit architecture (although AMD is pushing "AMD64" as the name I believe?)
Intel's new 64-bit in these EM64t chips is a compatibility with AMD64 (aka x86_64).
Yes, I believe they taught this in an oceanography course I took in college.