But the worst part is that the "failure of imagination" wasn't the reason that 9/11 happened. It was the failure to prevent people from smuggling weapons onto planes and hijacking them that allowed 9/11 to happen, and those are threats that have been around for a very long time.
I disagree. None of the weapons used in the 9/11 attacks were particularly ferocious. IMHO it *was* "lack of imagination" that ended up causing it since no-one really thought they'd end up being flown into a building - because while people are (or were) blowing themselves up fairly regularly in the Middle East, the Middle East is a long way away from the average domestic flyer's thoughts.
Indeed, even without any additional security steps, 9/11 would be highly unlikely to ever happen again. No air crew or group of passengers is ever going to let a bunch of hijackers take control of a plane again without some serious resistance.
Ah, so I should fill all my drive bays with the cheapest drives I can get and add then all to the RAID-Z array. Then I have maximum expansion ability later on.
Well, for best performance your RAIDZ array shouldn't be more than about 8 drives (and generally speaking, RAID5 arrays shouldn't be much larger than that). But that's probably not your primary interest in a home server.
Also remember that you need to replace all the drives at once - you won't be able to take advantage of any bigger drives until *all* the smaller ones have been removed from the array. This might be important to keep in mind from a financial perspective when sizing your arrays - replaced 12 - 16 drives in one hit could be expensive.
If it does NOT imply that, then what are they talking about? How can it heal itself without parity information to rebuild your data?
They are talking about replacing *all* the drives in the array with larger ones.
For example, you have a 4*500G, 2TB (raw) RAIDZ array.
You replace the first 500G disk with a 750G disk and wait for it to rebuild ("resilver").
You replace the second 500G disk with a 750G disk and wait for it to rebuild.
You replace the third 500G disk with a 750G disk and wait for it to rebuild.
You replace the fourth 500G disk with a 750G disk and wait for it to rebuild.
At the end of this process, you have a 4*750G = 3TB (raw) RAIDZ array (ie: you've gained ca. 750G of usable space).
In other words, you can't *extend* an existing RAIDZ/RAIDZ2 array with an additional disk, but you can *replace* all the existing disks with bigger ones and eventually (once they're all replaced) be able to access the additional space. Then you can create another RAIDZ with the old drives.
Do note, however, that you can extend a "RAID10", simply by adding more pairs of mirrored disks. Ie: 4*500G (2TB raw) RAID10, add two 750G disks, 3.5TB (raw) RAID10.
One thing I've read is you cannot increase a RAID Z "drive" easily by adding another disk. Is this true?
Yes, although they're working on it because it's pretty high on many people's wishlists. It's a non-trivial problem, however, since all the data and parity has to be redistributed across the entire set of disks (including the new one).
ZFS supports RAID5 (RAIDZ) and RAID6 (RAIDZ2), but it's pretty much assumed that in production you'll use RAID1 (mirrors). Growing an existing mirrored array is easy - just add another pair of disks.
I disagree. Do you have any numbers to back this up?
Yes. I've benchmarked with our own hardware fairly extensively and found software RAID to be faster in every case - which is why we have a bunch of "storage boxes" with expensive 8 - 16 port RAID controllers doing nothing more than exporting individual drives (although were I to do it again today this wouldn't happen, since there are now a few "dumb" 8-port SATA controllers out there). There are also numerous hardware vs software RAID5 benchmarks on the 'net as well.
For things like RAID 5, hardware is far better than software. First of all, RAID 5 is very heavily dependent on bitwise operations (speciafically XOR). Modern general purpose CPU's are indeed very fast, but have never been as good as certain specific tasks (like XOR) as purpose-built chips.
Even a lowly x00Mhz P3 can do RAID5 checksumming at 1000MB/sec or more - far faster than even a high-end, double-digit-disk-count 15k SAS drive array is going to sustain during writes (and especially random writes). Modern machines (eg: Core-based Xeons) are up around the 5000 - 6000MB/sec range. The processing "overhead" of RAID5 is insignificant on any remotely modern machine and the RAID5 bottleneck isn't caused by it anyway. It's caused by having to do roughly twice as much physical I/O (operations orders of magnitude slower than any checksumming calculations, even on machines a decade old) as other types of RAID. This is one of the reasons ZFS's RAIDZ is much faster than traditional RAID5 - it avoids much of the additional physical I/O.
Again, when using RAID 5, software is far slower than hardware, especially for transaction access.
No, it's not. There are situations where it might be, but they are generally related to overall hardware limitations (eg: hanging a dozen disks off a single 32 bit PCI bus), rather than anything inherent to the concept.
Further, if you're doing any kind of caching, you won't get battery-backed cache without a hardware solution.
Better to spend the money on a UPS to protect the whole system.
Then again, if someone is just trying to do RAID 1, you may be right. However, have you considered that the home server might want to boot to a RAID array? Does your OS support that in software?
Most OSes will boot from at least a RAID1 array, some from more exotic types. Linux is probably the most difficult to setup to do so, but it's not difficult once you know how.
It could replace low end nas, but what the poster is describing, basically IS low end nas.
Well, his DIY frankenbox certainly is, but I'd argue that a US$50k off-the-shelf solution qualifies as "mid range". For that sort of dough you should be into the territory of multiple, redundant everything, FC backend (even if it's only iSCSI on the front), significant expandability potential (50 - 100TB+) and that inescapable feeling of violation from paying $thousands for trivial software features that should be standard, like LUN masking.
You're driving in the middle lane, maximum alowed speed. A lunatic driver comes up over the speed limit from behind, tries to overtake but looses control, hits the guard rail and bounces back onto the road towards you. You put the board to the floor and get out of the situation.
Bad call. You should brake - moreover you should already be braking before the vehicle has started to re-enter traffic after deflecting off the guardrail.
A car decides to overtake the car in front of it, but doesn't look and doesn't see you in the lane next to it. You end up with 3 cars on 2 lanes. You speed up and the situation normalises.
Again, braking is almost certainly the better choice.
Braking in both cases is certainly not a garantee to get you out of danger. Speeding up is.
No, it's not - quite the opposite, if anything. Your car will slow down a lot (*a lot*) faster than it will speed up - especially at highway speeds. In both scenarios braking will almost certainly get you out of immediate danger more quickly than accelerating will. Not to mention accelerating reduces your car's maneuverability, your ability to control it and (significantly) increases its lethality.
I will concede that if you're in something with a power-to-weight ratio similar to a litre-class sportsbike, accelerating to get past might be a safe course of action. But even then it'd be iffy (and hardly any cars have anything close to that level of performance) because it would depend on the gear you were in (and I say that as someone who has spent quality time on a friend's GSXR1000 - although I'd never buy one myself).
That same database when run on a locally attached Ultra-160 SCSI drive (yesteryear's technology) absolutely smokes the iSCSI setup we tested.
It's unfortunate you've had a bad experience with iSCSI, but IMHO your experience isn't inherent to, or indicative of, the technology.
In conclusion, I've come to the determination that iSCSI is basically an academic curiosity that was created just because somebody thought it was cool to encapsulate the SCSI protocol in IP packets, and with only a light traffic load, such as a home network or a (very) small business network, [...]
iSCSI - even a single GBe link - has loads of bandwidth for typical usage patterns. 100MB/sec is a *lot* of data to be reading and writing consistently and you need a fairly beefy disk array to exceed it, outside of sequential data streaming applications.
For a database, 100MB/sec is a *lot* of work. Heck, even for typical fileserver usage, it's a lot. This is before getting into bonded links - something like an x4100 has 4 GBe links onboard - bonded together you're into 4Gb FC territory (athough it won't be as fast, it's in the ballpark).
[...] and over only gigabit ethernet, the performance is adequate, but why not just use simple and cheap attached big hard drives to your server instead? That is much less complicated.
Off the top of my head:
* Unless you're in a streaming situation, you'll need a lot of fast disks attached to exceed even a single GBe iSCSI link.
* Your data is tied to that server.
* Moving to some sort of clustering configuration with a shared storage architecture is significantly more difficult.
* Upgrading the IO capabilities of your single server can be difficult, if not impossible (eg: 2U server already stacked out with 6 15k drives, or 1U server that maxes out at two drives). Upgrading the IO capabilities of something on the other end of an iSCSI link is significantly easier. This princople applies to both performance and raw space (eg: we have an "archiving" server with ~10TB of iSCSI-attached storage. Increasing that by, say, another 6TB via iSCSI is trivial, because it's just a matter of plugging another array into the LAN. If all that space was internal, increasing it would be much more difficult.)
iSCSI is going to own the low-end and mid-range SAN infrastructure market within 5 years. Even at single GBe link speeds, performance is adequate for most applications and gig ethernet infrastructure is _vastly_ cheaper than FC infrastructure - especially since it lets you piggyback your non-storage traffic over the same physical connections.
Maybe with 10 gig ethernet, the performance bottleneck might be less of an impact, but I have no 10 gig hardware to play with.
Unless you're in a relatively uncommon scenario, it's unlikely the single-GBe iSCSI link was the bottleneck.
Show me how you build a Raid 50 of 32 sata or ide drives.
Get yourself a nice big rackmount case and some 8 or 16 port SATA controllers.
also show me a SINGLE sata or ide drive that can touch the data io rates of a u320 scsi drive with 15K spindle speeds.
Of course, the number of single drives you can buy for the cost of that single 15k drive will likely make a reasonable showing...
Low end consumer drive cant do the high end stuff. Dont even try to convince anyone of this. guess what, those uses are not anywher near strange for big companies. witha giant SQL db you want... no you NEED the fastest drives you can get your hands on and that is SCSI or Fiberchannel.
This is technically true, however, "low end consumer" drives can certain beat the performance of what *used* to be "high end" until relatively recently, and are quite adequate for significant proportions of the market.
Individually, 7.2k SATA drives are quite a bit slower than 15k SAS/FC drives. But get a dozen or two of those SATA spindles in an array, and you've got some (relative to cost) serious performance.
Potentially it will obselete low-end NAS/SAN hardware (eg: Dell/EMC AX150i, StoreVault S500) in the next couple of years, for companies who are prepared to expend the additional people time in rolling their own and managing it (a not insignificant cost - easily making up $thousands or more a year). There's a lot of value in being able to take an array out of a box, plug it in, go to a web interface and click a few buttons, then forget it exists.
However, your DIY project isn't going to come close to the performance, reliability and scalability of even an off the shelf mid-range SAN/NAS device using FC drives, multiple redundant controllers and power supplies - even if the front end is iSCSI.
Not to mention the manageability and support aspects. When you're in a position to drop $50k on a storage solution, you're in a position to be losing major money when something breaks, which is where that 24x7x2hr support contract comes into play, and hunting around on forums or running down to the corner store for some hardware components just isn't an option.
ZFS also still has some reliability aspects to work out - eg: hot spares. Plus there isn't a non-OpenSolaris release that offers iSCSI target support yet AFAIK.
I've looked into this sort of thing myself, for both home and work - and while it's quite sufficient for my needs at home, IMHO it needs 1 - 2 years to mature before it's going to be a serious alternative in the low-end NAS space.
I disagree. First, if you're running Debian then there is very little that isn't in the repository. The only things I use that aren't available through aptitude are some very specialized niche programs developed by academics to solve very particular problems. Most of these are in Java, and so the installation process is identical on Linux and MS.
How about commercial software ? You think if Microsoft releases Office for Linux you'll be able to download it with apt ?
Second, you assume that even if something isn't in the repository for a Linux distro it would already have a point-and-click installer for MSWindows.
Yes. It's a more than reasonable assumption. Even the worst case scenario is only likely to be a zipfile with an.exe file in it.
Also, as I mentioned elsewhere, actually figuring out what a piece of software is called so you can do 'apt-get install foo' can also be a significant hurdle.
You're missing most of the point here, which is not about failure and backups and recovery: it's about independence and flexibility.
In that case, how is the Registry any different ?
As I said, we *should* be able to pick up an app with its configuration and all our customizations and simply move it around, whether that's within the same OS and FS or to another system entirely. We *should* also be able to do that with UI and GUI customizations to the OS and OS utilities, as well.
You can. It's called a user profile, which stores a copy of the user's Registry Hive, which is where applications *should* be storing their per-user settings.
It's precisely because of this Registry stupidity that utilities like PC Magazine's COA and Vertisoft's RemoveIt (which actually had awesome app archiving and migration abilities) came into existence. In the absence of the Registry they wouldn't have even been necessary. They have no Linux equivalents at all.
The problem here is not the Registry, it is the broken applications. The Registry, in an dof itself, is not causing the problems you are describing.
You've been so blinded by the 30-foot-diameter Registry tree blocking your path that you've been completely missing the entire forest of possibilities beyond it.
I say the same thing about people who think the best solution to configuration and runtime data is text files.
It's NOT easy, damned near impossible, if the OS is Windows NT/2K/XP/2003 and isn't bootable. Even if the file system and structure is fine and the Registry hive files are otherwise accessible, there's no means known to me that would allow extracting data from them.
Other posters have already covered the technical aspects of this adequately. However, I will add that the proper solution to your example is backups, not major disaster recovery. Major disaster recovery is one of the few (if not only) situations I will agree flat text files have an advantage - but I temper that concession by pointing out having to exercise that sort of DR is indicative of a more serious problem and is not, in and of itself, a compelling argument.
You're on an uphill on-ramp to an elevated freeway which is under construction, which means there are no shoulders whatsoever. There is fast traffic on the freeway and behind you, and you have to speed up from 0 to 50 mph before you can merge safely. Your engine gives out in the middle of the ramp. By the time you reach the freeway, your speed has dropped to a crawl. The ramp is curved, so drivers starting the ascent can't see you. Wherever you go, you're creating a huge hazard.
So you stop on the ramp and hold everyone up. Inconvenient ? Yes. Cause a minor nose-to-tail crash ? Possibly. Life-threatening ? Not even close.
I'm not sure what to tell you - have you ever tried to steer or brake a heavy vehicle without hydraulics at speed? It's a very dangerous situation. You simply can't steer or brake properly, and that becomes deadly if you need to stop in anything other than a straight line with no obstacles.
I have had to stop such a vehicle. No, it's not easy, and yes, I ended up in a minor crash (although with the experience gained, were the same thing to happen today I would likely escape unscathed). But I still wouldn't put an incident like that - outside of exceptional and extraordinary circumstances - in the same class as nearly any scenario involving complete loss of braking and/or steering. Had I lost either of those capabilities in that situation, I (or someone else) probably would have died.
Look, I'm not trying to say there's no way losing engine power can cause a crash, nor that an unpowered car is equally as capable as a powered car. I'm trying to point out that in just about every scenario, a complete loss of engine power is nowhere near as serious a problem as a complete loss of steering or braking ability. Brakes and steering are far, far more critical systems in a vehicle than the engine, because those are the only two ways you have to reduce or control a vehicle's most lethal feature - it's kinetic energy.
The child of academics, raised in a liberal household and educated in the liberal arts, Brooks has written a book that concludes religious conservatives donate far more money than secular liberals to all sorts of charitable activities, irrespective of income.
The book presumably (hopefully) contains more specifics, but the claim as it stands here is too vague to be meaningful.
What do they mean by "donate" ? How are they measuring "more" ? What's the benchmark ? How are they identifying a "conservative" vs a "liberal". Are there more (or less) restrictions on the things that "conservatives" are prepared to donate to (stereotypical example: "planned parenthood" centre that refuses to offer abortion as an option vs one that does). Etc.
When will we elect politicians who are not so easily bribed and who will break up MS's abusive monopoly and restore competition to the desktop OS market?
First we need some competitors.
When will people educate themselves and vote the bums out? When will there be a level playing field for desktop OS's so vendors have to rely upon competing for our dollars by giving us the features we want and need instead of relying upon the fact that users are locked in?
Maybe you need to tell your vendor what features you want, if you want to see them implemented.
We have a solution. It's called capabilities, and it's implemented on Linux through an Open Source system called SElinux, developed by the NSA and released to the public. It's available for a number of Linux implementations, including Ubuntu (although no implementation of SElinux seems to have a decent userland/interface.)
The end user can make modifications to enable additional access. Hence, it's not a solution, but effectively just another layer of "are you sure" dialog boxes.
(Not to mention the problems around configuring it.)
When will we see a REAL solution to these problems, and stop implementing obscure security work-arounds that eat more resources than the applications themselves? Anyone?
A technical solution ? Never, because the *problem* largely isn't a technical one.
Sure. In the same sense that a directory full of configuration files is "monolithic".
(Not to mention the whole "it's monolithic" argument is completely arbitrary. Do databases suck because they are "monolithic" ?)
The app config data that gets stored in it is not easily backed-up WITH the app and separate from everything else, whether to archive or migrate to another system.
It's pretty easy to dump some keys from the Registry if you need to.
There are plenty of other reasons, but you seem experienced enough to already know what they are.
Sure. I just don't see how text files are any better, or even as good, unless you're stuck in a "it must be like UNIX" mindset - and if you are, you shouldn't be using Windows, because Windows ain't UNIX.
You sound like your knowledge of and experience with, the Registry, hasn't been refreshed since Windows 95.
Slashdot Mirror
But the worst part is that the "failure of imagination" wasn't the reason that 9/11 happened. It was the failure to prevent people from smuggling weapons onto planes and hijacking them that allowed 9/11 to happen, and those are threats that have been around for a very long time.
I disagree. None of the weapons used in the 9/11 attacks were particularly ferocious. IMHO it *was* "lack of imagination" that ended up causing it since no-one really thought they'd end up being flown into a building - because while people are (or were) blowing themselves up fairly regularly in the Middle East, the Middle East is a long way away from the average domestic flyer's thoughts.
Indeed, even without any additional security steps, 9/11 would be highly unlikely to ever happen again. No air crew or group of passengers is ever going to let a bunch of hijackers take control of a plane again without some serious resistance.
Ah, so I should fill all my drive bays with the cheapest drives I can get and add then all to the RAID-Z array. Then I have maximum expansion ability later on.
Well, for best performance your RAIDZ array shouldn't be more than about 8 drives (and generally speaking, RAID5 arrays shouldn't be much larger than that). But that's probably not your primary interest in a home server.
Also remember that you need to replace all the drives at once - you won't be able to take advantage of any bigger drives until *all* the smaller ones have been removed from the array. This might be important to keep in mind from a financial perspective when sizing your arrays - replaced 12 - 16 drives in one hit could be expensive.
If it does NOT imply that, then what are they talking about? How can it heal itself without parity information to rebuild your data?
They are talking about replacing *all* the drives in the array with larger ones.
For example, you have a 4*500G, 2TB (raw) RAIDZ array.
You replace the first 500G disk with a 750G disk and wait for it to rebuild ("resilver").
You replace the second 500G disk with a 750G disk and wait for it to rebuild.
You replace the third 500G disk with a 750G disk and wait for it to rebuild.
You replace the fourth 500G disk with a 750G disk and wait for it to rebuild.
At the end of this process, you have a 4*750G = 3TB (raw) RAIDZ array (ie: you've gained ca. 750G of usable space).
In other words, you can't *extend* an existing RAIDZ/RAIDZ2 array with an additional disk, but you can *replace* all the existing disks with bigger ones and eventually (once they're all replaced) be able to access the additional space. Then you can create another RAIDZ with the old drives.
Do note, however, that you can extend a "RAID10", simply by adding more pairs of mirrored disks. Ie: 4*500G (2TB raw) RAID10, add two 750G disks, 3.5TB (raw) RAID10.
Software-only iscsi on Linux is a recipe for massive data corruption.
Details ? I've shuffled a lot of data through some machines using IET and the software initiator in RHEL without any problems.
One thing I've read is you cannot increase a RAID Z "drive" easily by adding another disk. Is this true?
Yes, although they're working on it because it's pretty high on many people's wishlists. It's a non-trivial problem, however, since all the data and parity has to be redistributed across the entire set of disks (including the new one).
ZFS supports RAID5 (RAIDZ) and RAID6 (RAIDZ2), but it's pretty much assumed that in production you'll use RAID1 (mirrors). Growing an existing mirrored array is easy - just add another pair of disks.
But I never understood the difference between a SAN and a NAS when the configuration gains any complexity beyond a textbook example.
A NAS is something you access via the network (CIFS/SMB, NFS, etc).
A SAN is something you access as a block device (/dev/sda, etc).
I disagree. Do you have any numbers to back this up?
Yes. I've benchmarked with our own hardware fairly extensively and found software RAID to be faster in every case - which is why we have a bunch of "storage boxes" with expensive 8 - 16 port RAID controllers doing nothing more than exporting individual drives (although were I to do it again today this wouldn't happen, since there are now a few "dumb" 8-port SATA controllers out there). There are also numerous hardware vs software RAID5 benchmarks on the 'net as well.
For things like RAID 5, hardware is far better than software. First of all, RAID 5 is very heavily dependent on bitwise operations (speciafically XOR). Modern general purpose CPU's are indeed very fast, but have never been as good as certain specific tasks (like XOR) as purpose-built chips.
Even a lowly x00Mhz P3 can do RAID5 checksumming at 1000MB/sec or more - far faster than even a high-end, double-digit-disk-count 15k SAS drive array is going to sustain during writes (and especially random writes). Modern machines (eg: Core-based Xeons) are up around the 5000 - 6000MB/sec range. The processing "overhead" of RAID5 is insignificant on any remotely modern machine and the RAID5 bottleneck isn't caused by it anyway. It's caused by having to do roughly twice as much physical I/O (operations orders of magnitude slower than any checksumming calculations, even on machines a decade old) as other types of RAID. This is one of the reasons ZFS's RAIDZ is much faster than traditional RAID5 - it avoids much of the additional physical I/O.
Again, when using RAID 5, software is far slower than hardware, especially for transaction access.
No, it's not. There are situations where it might be, but they are generally related to overall hardware limitations (eg: hanging a dozen disks off a single 32 bit PCI bus), rather than anything inherent to the concept.
Further, if you're doing any kind of caching, you won't get battery-backed cache without a hardware solution.
Better to spend the money on a UPS to protect the whole system.
Then again, if someone is just trying to do RAID 1, you may be right. However, have you considered that the home server might want to boot to a RAID array? Does your OS support that in software?
Most OSes will boot from at least a RAID1 array, some from more exotic types. Linux is probably the most difficult to setup to do so, but it's not difficult once you know how.
It could replace low end nas, but what the poster is describing, basically IS low end nas.
Well, his DIY frankenbox certainly is, but I'd argue that a US$50k off-the-shelf solution qualifies as "mid range". For that sort of dough you should be into the territory of multiple, redundant everything, FC backend (even if it's only iSCSI on the front), significant expandability potential (50 - 100TB+) and that inescapable feeling of violation from paying $thousands for trivial software features that should be standard, like LUN masking.
Assuming a reasonably modern machine, software RAID will be at least as fast - if not faster - than hardware RAID.
I cannot conceive of any reason whatsoever why anyone would spend money for a hardware RAID controller in a home server context.
You're driving in the middle lane, maximum alowed speed. A lunatic driver comes up over the speed limit from behind, tries to overtake but looses control, hits the guard rail and bounces back onto the road towards you. You put the board to the floor and get out of the situation.
Bad call. You should brake - moreover you should already be braking before the vehicle has started to re-enter traffic after deflecting off the guardrail.
A car decides to overtake the car in front of it, but doesn't look and doesn't see you in the lane next to it. You end up with 3 cars on 2 lanes. You speed up and the situation normalises.
Again, braking is almost certainly the better choice.
Braking in both cases is certainly not a garantee to get you out of danger. Speeding up is.
No, it's not - quite the opposite, if anything. Your car will slow down a lot (*a lot*) faster than it will speed up - especially at highway speeds. In both scenarios braking will almost certainly get you out of immediate danger more quickly than accelerating will. Not to mention accelerating reduces your car's maneuverability, your ability to control it and (significantly) increases its lethality.
I will concede that if you're in something with a power-to-weight ratio similar to a litre-class sportsbike, accelerating to get past might be a safe course of action. But even then it'd be iffy (and hardly any cars have anything close to that level of performance) because it would depend on the gear you were in (and I say that as someone who has spent quality time on a friend's GSXR1000 - although I'd never buy one myself).
That same database when run on a locally attached Ultra-160 SCSI drive (yesteryear's technology) absolutely smokes the iSCSI setup we tested.
It's unfortunate you've had a bad experience with iSCSI, but IMHO your experience isn't inherent to, or indicative of, the technology.
In conclusion, I've come to the determination that iSCSI is basically an academic curiosity that was created just because somebody thought it was cool to encapsulate the SCSI protocol in IP packets, and with only a light traffic load, such as a home network or a (very) small business network, [...]
iSCSI - even a single GBe link - has loads of bandwidth for typical usage patterns. 100MB/sec is a *lot* of data to be reading and writing consistently and you need a fairly beefy disk array to exceed it, outside of sequential data streaming applications.
For a database, 100MB/sec is a *lot* of work. Heck, even for typical fileserver usage, it's a lot. This is before getting into bonded links - something like an x4100 has 4 GBe links onboard - bonded together you're into 4Gb FC territory (athough it won't be as fast, it's in the ballpark).
[...] and over only gigabit ethernet, the performance is adequate, but why not just use simple and cheap attached big hard drives to your server instead? That is much less complicated.
Off the top of my head:
* Unless you're in a streaming situation, you'll need a lot of fast disks attached to exceed even a single GBe iSCSI link.
* Your data is tied to that server.
* Moving to some sort of clustering configuration with a shared storage architecture is significantly more difficult.
* Upgrading the IO capabilities of your single server can be difficult, if not impossible (eg: 2U server already stacked out with 6 15k drives, or 1U server that maxes out at two drives). Upgrading the IO capabilities of something on the other end of an iSCSI link is significantly easier. This princople applies to both performance and raw space (eg: we have an "archiving" server with ~10TB of iSCSI-attached storage. Increasing that by, say, another 6TB via iSCSI is trivial, because it's just a matter of plugging another array into the LAN. If all that space was internal, increasing it would be much more difficult.)
iSCSI is going to own the low-end and mid-range SAN infrastructure market within 5 years. Even at single GBe link speeds, performance is adequate for most applications and gig ethernet infrastructure is _vastly_ cheaper than FC infrastructure - especially since it lets you piggyback your non-storage traffic over the same physical connections.
Maybe with 10 gig ethernet, the performance bottleneck might be less of an impact, but I have no 10 gig hardware to play with.
Unless you're in a relatively uncommon scenario, it's unlikely the single-GBe iSCSI link was the bottleneck.
Show me how you build a Raid 50 of 32 sata or ide drives.
Get yourself a nice big rackmount case and some 8 or 16 port SATA controllers.
also show me a SINGLE sata or ide drive that can touch the data io rates of a u320 scsi drive with 15K spindle speeds.
Of course, the number of single drives you can buy for the cost of that single 15k drive will likely make a reasonable showing...
Low end consumer drive cant do the high end stuff. Dont even try to convince anyone of this. guess what, those uses are not anywher near strange for big companies. witha giant SQL db you want... no you NEED the fastest drives you can get your hands on and that is SCSI or Fiberchannel.
This is technically true, however, "low end consumer" drives can certain beat the performance of what *used* to be "high end" until relatively recently, and are quite adequate for significant proportions of the market.
Individually, 7.2k SATA drives are quite a bit slower than 15k SAS/FC drives. But get a dozen or two of those SATA spindles in an array, and you've got some (relative to cost) serious performance.
Potentially it will obselete low-end NAS/SAN hardware (eg: Dell/EMC AX150i, StoreVault S500) in the next couple of years, for companies who are prepared to expend the additional people time in rolling their own and managing it (a not insignificant cost - easily making up $thousands or more a year). There's a lot of value in being able to take an array out of a box, plug it in, go to a web interface and click a few buttons, then forget it exists.
However, your DIY project isn't going to come close to the performance, reliability and scalability of even an off the shelf mid-range SAN/NAS device using FC drives, multiple redundant controllers and power supplies - even if the front end is iSCSI.
Not to mention the manageability and support aspects. When you're in a position to drop $50k on a storage solution, you're in a position to be losing major money when something breaks, which is where that 24x7x2hr support contract comes into play, and hunting around on forums or running down to the corner store for some hardware components just isn't an option.
ZFS also still has some reliability aspects to work out - eg: hot spares. Plus there isn't a non-OpenSolaris release that offers iSCSI target support yet AFAIK.
I've looked into this sort of thing myself, for both home and work - and while it's quite sufficient for my needs at home, IMHO it needs 1 - 2 years to mature before it's going to be a serious alternative in the low-end NAS space.
Sure, if you can find them. Copying text files is much less messy.
Maybe. If you can find them, that is.
If your software is not in the repos it's as good as it is on Windows, that is, it's up to the developers to figure something out.
The difference is that the developers seem to "figure something out" on Windows much more workably than they do on Linux.
I disagree. First, if you're running Debian then there is very little that isn't in the repository. The only things I use that aren't available through aptitude are some very specialized niche programs developed by academics to solve very particular problems. Most of these are in Java, and so the installation process is identical on Linux and MS.
How about commercial software ? You think if Microsoft releases Office for Linux you'll be able to download it with apt ?
Second, you assume that even if something isn't in the repository for a Linux distro it would already have a point-and-click installer for MSWindows.
Yes. It's a more than reasonable assumption. Even the worst case scenario is only likely to be a zipfile with an .exe file in it.
Also, as I mentioned elsewhere, actually figuring out what a piece of software is called so you can do 'apt-get install foo' can also be a significant hurdle.
You're missing most of the point here, which is not about failure and backups and recovery: it's about independence and flexibility.
In that case, how is the Registry any different ?
As I said, we *should* be able to pick up an app with its configuration and all our customizations and simply move it around, whether that's within the same OS and FS or to another system entirely. We *should* also be able to do that with UI and GUI customizations to the OS and OS utilities, as well.
You can. It's called a user profile, which stores a copy of the user's Registry Hive, which is where applications *should* be storing their per-user settings.
It's precisely because of this Registry stupidity that utilities like PC Magazine's COA and Vertisoft's RemoveIt (which actually had awesome app archiving and migration abilities) came into existence. In the absence of the Registry they wouldn't have even been necessary. They have no Linux equivalents at all.
The problem here is not the Registry, it is the broken applications. The Registry, in an dof itself, is not causing the problems you are describing.
You've been so blinded by the 30-foot-diameter Registry tree blocking your path that you've been completely missing the entire forest of possibilities beyond it.
I say the same thing about people who think the best solution to configuration and runtime data is text files.
It's NOT easy, damned near impossible, if the OS is Windows NT/2K/XP/2003 and isn't bootable. Even if the file system and structure is fine and the Registry hive files are otherwise accessible, there's no means known to me that would allow extracting data from them.
Other posters have already covered the technical aspects of this adequately. However, I will add that the proper solution to your example is backups, not major disaster recovery. Major disaster recovery is one of the few (if not only) situations I will agree flat text files have an advantage - but I temper that concession by pointing out having to exercise that sort of DR is indicative of a more serious problem and is not, in and of itself, a compelling argument.
You're on an uphill on-ramp to an elevated freeway which is under construction, which means there are no shoulders whatsoever. There is fast traffic on the freeway and behind you, and you have to speed up from 0 to 50 mph before you can merge safely. Your engine gives out in the middle of the ramp. By the time you reach the freeway, your speed has dropped to a crawl. The ramp is curved, so drivers starting the ascent can't see you. Wherever you go, you're creating a huge hazard.
So you stop on the ramp and hold everyone up. Inconvenient ? Yes. Cause a minor nose-to-tail crash ? Possibly. Life-threatening ? Not even close.
I'm not sure what to tell you - have you ever tried to steer or brake a heavy vehicle without hydraulics at speed? It's a very dangerous situation. You simply can't steer or brake properly, and that becomes deadly if you need to stop in anything other than a straight line with no obstacles.
I have had to stop such a vehicle. No, it's not easy, and yes, I ended up in a minor crash (although with the experience gained, were the same thing to happen today I would likely escape unscathed). But I still wouldn't put an incident like that - outside of exceptional and extraordinary circumstances - in the same class as nearly any scenario involving complete loss of braking and/or steering. Had I lost either of those capabilities in that situation, I (or someone else) probably would have died.
Look, I'm not trying to say there's no way losing engine power can cause a crash, nor that an unpowered car is equally as capable as a powered car. I'm trying to point out that in just about every scenario, a complete loss of engine power is nowhere near as serious a problem as a complete loss of steering or braking ability. Brakes and steering are far, far more critical systems in a vehicle than the engine, because those are the only two ways you have to reduce or control a vehicle's most lethal feature - it's kinetic energy.
The child of academics, raised in a liberal household and educated in the liberal arts, Brooks has written a book that concludes religious conservatives donate far more money than secular liberals to all sorts of charitable activities, irrespective of income.
The book presumably (hopefully) contains more specifics, but the claim as it stands here is too vague to be meaningful.
What do they mean by "donate" ? How are they measuring "more" ? What's the benchmark ? How are they identifying a "conservative" vs a "liberal". Are there more (or less) restrictions on the things that "conservatives" are prepared to donate to (stereotypical example: "planned parenthood" centre that refuses to offer abortion as an option vs one that does). Etc.
When will we elect politicians who are not so easily bribed and who will break up MS's abusive monopoly and restore competition to the desktop OS market?
First we need some competitors.
When will people educate themselves and vote the bums out? When will there be a level playing field for desktop OS's so vendors have to rely upon competing for our dollars by giving us the features we want and need instead of relying upon the fact that users are locked in?
Maybe you need to tell your vendor what features you want, if you want to see them implemented.
We have a solution. It's called capabilities, and it's implemented on Linux through an Open Source system called SElinux, developed by the NSA and released to the public. It's available for a number of Linux implementations, including Ubuntu (although no implementation of SElinux seems to have a decent userland/interface.)
The end user can make modifications to enable additional access. Hence, it's not a solution, but effectively just another layer of "are you sure" dialog boxes.
(Not to mention the problems around configuring it.)
When will we see a REAL solution to these problems, and stop implementing obscure security work-arounds that eat more resources than the applications themselves? Anyone?
A technical solution ? Never, because the *problem* largely isn't a technical one.
Not always bad driving by the person using the power te escape though. There are other people on the road as well
Still waiting for examples.
The Registry is monolithic, for one thing.
Sure. In the same sense that a directory full of configuration files is "monolithic".
(Not to mention the whole "it's monolithic" argument is completely arbitrary. Do databases suck because they are "monolithic" ?)
The app config data that gets stored in it is not easily backed-up WITH the app and separate from everything else, whether to archive or migrate to another system.
It's pretty easy to dump some keys from the Registry if you need to.
There are plenty of other reasons, but you seem experienced enough to already know what they are.
Sure. I just don't see how text files are any better, or even as good, unless you're stuck in a "it must be like UNIX" mindset - and if you are, you shouldn't be using Windows, because Windows ain't UNIX.
You sound like your knowledge of and experience with, the Registry, hasn't been refreshed since Windows 95.