I'm sure suse is better than redhat, but RH has the 'market' in the US and oracle picked RH as the basis for OEL, not SUSE. Of course, its all 'linux' (i know, its not) but that is another issue for another day.
For multipathing, I was mostly talking about FC networks. That said, we also use it a lot for our IP networks. It is easy to setup on solaris and windows, but not linux. We've had "fully redundant" cisco switches go down due to a hardware failure before. So the idea of pulling everything back to a single switch is not a good idea. For $10k (list) extra, we just get two chassis and put a single supervisor in each one. This way an entire chassis can fail and nobody notices (in theory).
As for zones vs a hypervisor, that is an example of having several tools to fit the job. One is a screwdriver, the other is a hammer. When I want a copy of the base OS, zones are much nicer. They get patched with the base OS, they dont take much disk (150m with sparse root zones) and the performance hit is not even measurable. ESX/Xen/Etc are the other end: you have to fully manage them as another instance, they take up a lot more disk, and performance issues abound (depending on what you are doing)
And we are looking at brandz... just what we need, to run a linux zone on a sun box... It does look attractive and I'm going to give it a try:-)
As for the strace vs truss debate, I left that out. strace is still a subset of truss, but kmdb and dtrace go even further.
Linux just works? Yeah, maybe for a small system running a simple app stack.
I had to setup an oracle cluster: Thanks to Oracle's support policies, we could not use Solaris x86. Nor could we use RHEL5 (no Oracle 9i support), so RHEL4.6 it was. Should be easy, right? Well tested "enterprise" class linux that can do everything the big boys can do.... We took the hardware we were going to use for solaris and switched it to linux. A pair of Sun x4600M2's, 128G of ram, 4 Dual core AMD's. Sun fully supports linux on this box and RedHat lists it on their HCL. Should be easy.
The basic OS install was more or less easy, once we battled through the serial port redirection setup (guess most linux users never used a serial port before. After all, why bother when the box sits under your desk). I stil like serial ports over video for one major reason: issue resolution (when bad things happen, having that panic string saved by a console server can really save the day)
Ok, so the system was kickstarted and now it is time to set it up for use as an oracle DB. This is a production system, and we need lots of space (4TB) and High Availability. This means redundant connections to everything, mirroring and clustering.
Issue #1: multipathing drivers for the SAN. With solaris, you just plug the thing into the san and all of the storage that the host has access to just showed up. Multipathing was instant and I didnt have to do jack. I could see what devices mapped to which physical array with a simple command. I didnt have to guess which array/dev/sde came from vs/dev/sdf. When you have 20 luns mapped to the same host from two different arrays, its kinda important to know which drives come from which array and what the corresponding lun numbers are. That said, most linux admins I've talked to didnt have a clue about what I was talking about since they never had a san.
Issue #2: dynamically add luns: With solaris, you just change the mapping on the array and the host picks it up and auto creates the dev links. That was easy. On Linux? you've got to be kidding me... You get to echo some crazy strings into several spots in/proc and watch the fun start.
issue #3: IP Multipathing. With solaris, dladmin is used to create a bond (if it is going to the same switch and the switch supports bonding) or use the built in ip multipathing to do an active/failover setup if you are going to multiple switches. Very well documented and very easy to do. With linux... yeah, bonding is a fun task. Need to go to multiple switches? no such luck, you are screwed. I eventually used VCS to take over the systems main IP and uses its IPMultipathing agent to do the job for me. VCS on solaris just hands the task off to mpathd since the OS already does it for you.
Issue #4: zones: dont get me started. I dont want to run another entire OS, I just want name space isolation and chroot is so primative it is not even funny. Zones gives me everything I want with minimal overhead. It would have been nice to have since there are a few oracle products that dont play nicely with clusters (*Warehouse Builder*) because they imbed the host name everywhere. We could put it under Xen, but this is an app that moves huge amounts of data around, not exactly a good candidate for virtualization. Zones let us get around Oracle's brain dead use of the hostname, no such luck with linux.
Issue #5: 3rd party drivers vs the new kernel patch. If I install a 3rd party device driver in solaris and upgrade the kernel, I dont have to rebuild/reinstall the driver. Linux (even redhat 4.x with their "back port") forces me to rebuild/reinstall every damn time. Its great if the driver is standard with the kernel, but if you need something outside of that (lsi multipathing drivers to get around #1 and 10G NIC drivers in my case) and you are screwed. No wonder up2date ignores all of the kernel* rpm's by default.
Issue #6: Whats the system doing? Solaris: `mdb -k` and dtrace. Linux: still trying
For an entry level class, you need to start with the classic: UNIX System Administration Handbook (3rd Edition, 2000) by Evi Nemeth, et al. If you want to focus on linux, you can go with Linux Administration Handbook (2nd Edition, 2006) by the same authors.
Once you learn the basics, you need to pick a flavor and dive in with more "up to date" stuff. Something that covers zones, smf and zfs for solaris folks. I'm sure there are new features to linux, but I cant think of any at the OS level that dont vary widely by distro:-) (dont get me started, my biggest annoyance with "linux" is that everybody follows their own "standard" for how to configure the system.)
Unix is 30+ years old and the basics still have not changed in a very, very long time. Its like complaining that a programing class is still using a 10+ year old book to explain looping and variable scoping.
I remember going through this with cisco the first time when they offered the 16 port or 32 port (2Gb) line cards, depending on what your access patterns were.
Most corporate san and network environments are bursty in nature. Clients pull a bunch of data and then think about it for a long time. Not many go full bore all day long. If this is the access pattern, then the MDS systems are fine since the chances of everybody trying to pull 4Gb at the same time is nil.
If, however, you are running a huge supercomputer site that must moves huge amounts of data around all the time as fast as possible... well, lets just say that the MDS is not what you want (unless you want a 132 port switch that takes up half a rack and doubles as a space heater)
I'm sure the folks at cisco will eventually have local switching. They offer DFC's for their ethernet products that do just that, so they have the technology.
I hope they do, the thing I hate doing the most is running all of the cables to the servers and storage. I know larger shops have 'people' who do this for them, but I'm not lucky enough to have a team of lackies to do the grunt work for me.:-)
Of course, only cisco offers 528 4G ports on a single chassis (as long as you cable stuff to avoid oversubscribing the backplane. Again, in theory this can be done but in practice one just needs to be a bit more careful).
And lord help me if I ever manage an environemnt that requires that many san ports. I have enough to do now as it is.:-)
I have to make the decision with what is available now based on what my requirements are and what I estimate them to be over the next 3 to 4 years.
In other words, my choices today were gig-e and 10G-E iSCSI, 4Gb and then 10Gb FC. Anything else was not an option since it simply does not exist outside of the lab (or at a resonable cost).
At this time, 4Gb FC made the most sense for our storage network. It is well understood, everybody supports it and the things "just work". I didnt see any major storage vendors offering 10G-E iSCSI arrays just yet. Of course, those Force10 switches sure do look nice:-)
I did pick up a a pair of 10Gb-E cards for our netbackup server since right now it is saturating the Gig-E network that we have for hours at a time trying to pull in data from all of the clients (fun with D2D2T backup solutions) (and for those wondering, off host backups are not an option for a bunch of individual app servers using internal storage) Of course, once the data is on the NBU server, it sends it to the array via 4Gb FC at a rate of 600MB/s. And then there is the part when it needs to move the data from the array to the LTO tape drives (a single lto-3 can move at 160MB/s, and they dont support iSCSI).
I hope that in 4 years or so, I can stop running so many damn cables to the servers and get away with a pair of 10Gb or faster . Until then, I'm stuck running 2 fiber FC cables and 4 copper gig-e's (two public, 2 heartbeat for the cluster) to most of our major systems and ESX boxes.
The 9134's look a lot like the Qlogic 5600's. They both have the same issue: Stacking two will oversubscribe the 10Gb FC interconnects. I know that there are ways to avoid this in theory, but luck always has it that I never have a port available where I need it for optinal performance. Thus things like the 4900 are so nice in that it is next to impossible to screw up:-)
That said, I'm happy to see that cisco finally got their power consumption under control with the 9134's. The older models sucked so much power that it was not even funny (Like a lot of folks, I'm limited on 3 things in my datacenter right now: space, power and cooling)
I did entertain quotes for a 9506 from the cisco folks. But when I compared the physical size, power requirements and cost (2x as much for 64 blocking ports), it did not make sense in my environment. The 9509 was just way too big to put anywhere after our network team droped in a pair of 6509's at each site and took most of the remaining power and space that we had. The cisco folks never even offered the 9134 as an option.
As for the Nexus vs Sun magnum, Cisco's bread and butter is ethernet, so that made sense. Sun just went for whatever gave them the best performance, and the fact that the HPC world was already used to Infinitiband made sense for them. That said, sun moves 110Tb/s in their switch vs Cisco's "System designed for investment protection with a 15 Tbps highly scalable fabric". Ok, so the cisco one is a bit smaller, but still, its not that much smaller:-)
Our original SAN consisted of four MSS 9216's with the 32 port blades for a total of 48 ports per switch. Two at each site (stretched fabric, 3k of dark fiber between the two sites, dual fabric, bla, bla, bla) Every server has two ports and thus full redundancy in the event of a switch/cable/whatever failure. (ever try and bond two ethernet ports between two switches?).
To replace the aging MDS switches we went with four Brocade 4900's. We have what I would call a medium sized environment, so the larger brocade switches did not make sense, but then again neither did the little things like the Brocade 200E. We have some hosts who will push 500+MB/s of traffic through our SAN, so trying to bond a ton of ethernet ports together did not make sense (think of the cables). Of course, bonding to a single switch is easy, ever try bonding between two physically different switches for redundancy? (to save money, our 6509's only have 1 sup, so we need switch diversity). Storage multipathing is easy with a dual port 4Gb hba. One could argue that a dual port or a 10G-E card allows for failover but removes the need for bonding. Of course, guess which one is cheaper:-)
The nice thing about the 4900's vs the cisco MDS switches are as follows; 1) Smaller (2RU for 64 ports) 2) No oversubscription (64 ports, 4Gb any to any) 3) Less power. (Not even close) 4) Hitless firmware upgrades (cisco sorta has this with the MDS 9500, at 10x the cost) 5) Ooooh, shiny box:-)
At the same time our network folks were purchasing some 10G line cards for their Cat 6509's. Lets just say that the 8 port card with optics cost more than my 64 port 4900 with optics. They got 160Gb of bandwidth (assuming you never leave the card when it quickly falls to 40Gb), I got 512Gb.
Just for kicks I also looked at their costs for the 48 port gig-e line cards. Loking at just the cost of the cisco line cards (6748's) and ignoring the cost of the chassis and supervisor, my cost per Gb was just a touch under theirs (and mine included the whole chassis). Of course, 256 ports of gig-E takes up a lot more space, more cables and I still have the bonding issue for redundancy.
Hope they fix the pricing issue, because I the FC network I just put in cost less per Gb than a 1 gig-E network. When compared to the cost per Gb of a 10G-E netowrk, the entire thing cost less than the optics on the 10G stuff, let alone the actual switch costs.
I'm also noticing that most if not all of my systems never even tap the bandwidth available on a pair of 4Gb FC ports, let alone 10Gb. I'm sure there are folks out there who need it, but it aint us.
Of course, our corporate standard is Cisco, so I'm sure that had something to do with the high cost of the ethernet equipment;-)
Sun may have a point. In app based benchmarks, the new T2+ based systems hold their own against IBM's Power 6.
In this particular case, the Sun system has two sockets (8 cores per socket) which run at 1.4GHz vs a 4 socket (dual core per socket) IBM running at 4.7 (I didnt find a nice benchmark for the new 5.0's) . If you add up the MHz, IBM has an almost 2:1 lead (37.6 vs 22.4) and yet they score the same on the benchmark.
Note that the article is also wrong on some of the numbers. Sun's T2 runs at 1.4, not 2.4.
> as others have pointed out you're completely and utterly wrong.
Several other folks have told me the following: the sniping software gives ebay their maximum bid so it is just like using the maximum bid option, but prevents nibblers from driving the price up.
The evidence (in the form of bidding histories for closed auctions) shows that the software is often not exactly doing as many have suggested. I may be off on the 'rounds' part as far as modern sniping software goes (I do remember seeing software that did just that way back in the dawn of time, like before 2000 when this 'internet' thing was just starting to take off), but it goes not appear to ever directly give ebay the users actual maximum bid as they claim.
When folks first started yelling that I was totally off base, and that the software was actually placing the snipers actual maximum bid into the ebay system, I was a bis suspicious. Their explanation sounded wrong, as it provided little advantage over the normal process of directly telling ebay the maximum you wanted to pay. So, I quickly scanned a few dozen auctions and tried to determine the bidding pattern of last minute bidders. If the software was acting as I suspected it would, there should be an obvious pattern. If it acted like everybody was telling me it would, there would be a different pattern.
Overall, I speculated that with sniping software, a last minute bid would not raise the bid price by more than 2x the increment. If there was an outstanding autobid for more than this last second 'snipe', I would then see that users who had previously placed auto bid jump past that person by the min bid amount.
Based on looking at the bid histories, this became clear: if an existing autobidder still was willing to go much further, then the last second snipe didnt do more than bump up the final price by 2x the increment (snipers bid then the automatically generated counter). If there was no existing autobid still in play, then the snipe would succeed in winning the auction at the current price plus the increment. (if the existing autobid was more or less at its cap, then the sniper could still win if they gave their bid a small bit of 'headroom', but this was rare).
If the software worked the way everybody is telling me it does, I would see a situation where the last second bids would be significantly jump more than the minimum bid increment as it zoomed in on the lower of the two maxes plus the increment.
For example (yes, this is overly simplistic):
We have two bidders for some rare widgets: User A has told ebay directly that they are willing to pay up to $50 for the widget. User B is using 3rd party sniping software and has instructed it to go up to $40.
The auction has 30 seconds to go and is at $20. Min increment is $1.
As a general rule, this is what I'm seeing: With a few (30 or so) seconds left, User B would place a bid for $21. The system would then proxy bid for User A at $22. The auction would end. User A wins the auction for $22.
This is what would _should_ happen if the software is doing what everybody is telling me it does: With a few (30 or so) seconds left, User B would place a bid for $21 with a max bid of $40 User A would then get an autobid for $41 (B + the increment) The auction would end. User A wins the auction for $41.
Since it appears the sniping software makes a last second check to see what it should bid, it prevents the bids from skyrocketing at the last second. This saves the snipe software user money, so they use the software. (otherwise they would just do what user A did and be done with it)
It appears that the sniping software may not go round and round (as another person has noted, this would kill ebays servers, but I'm sure it was done at one time for obvious reasons. My guess is that they alter their api every time they detect 'overly aggressive' sniping software).
What the current crop of software appears to do is poll ebay once with less than a minute lef
yes, the sniping software uses the autobidding as its target rather than the auction directly. Its a level of indirection that I left out to make the original explination simpler. (otherwise it got really convoluted).
And I have noted that each one has a different algorighm (last second proxy bid vs multiple increasing proxy bids).
But here is the big question: If it only places 1 bid and folks have pointed out, and that bid is your actual max... then what is the advantage (other than avoiding buyers remorese for the sniper) over just entering your max bid directly in the ebay system directly when you first note the item?
I never see a last second bid for more than a single increment over the existing bid. If there were multiple snipers, you would expect to see a larger jump since both entered their 'max' bids and the system would take the lower of the two plus the increment. This is not a pattern I've ever seen. Its as if at the last second multiple folks using sniping software enter a max bid that is more or less equal to the current minimum bid and then the rest get ignored. The first one in wins. This strategy differs from what you and others have indicated as 'the way it works'. (where the proxy bid software would go with a larger final increment).
Now, I never said that sniping was bad for the winner (it can even be good for the looser if they dont know how to control their emotions). But overall, it is not good for the seller.
According to you, there is never a need for a 3rd party bid sniper since they all just use ebays proxy bid path and punch in the max bid? Given the very large number of bid sniping software packages out there, this is obviously not the case.
"In most cases your bid will be adjusted one bidding increment above the previous high bidder. Bidnapper uses the proxy bidding system to bid just enough to make you the winner, up to your maximum bid."
Now, they are using ebays proxy bid to make the bids for them, but then it becomes an auction via ever increasing 'max bid' proxy bids rather than the bids on the direct auction items. Last one in with a higher 'max bid' wins. This may or may not be the actual max bid number you entered in the software. If it can avoid telling ebay that number, then it saves you money. Otherwise you can just tell ebay that number directly and bypass the bid sniping software.
Bidding via the proxy helps them get around the latency issue, but it still does not start off with your 'max' price right off the bat. And that is the key.
The theory stays the same, try and slide in the lowest possible bid right at the end. The target just got moved a bit to the side.
As I pointed out, sniping can be good for the bidder (esp if there is not enough time to do enough rounds to hit your max price).
Now, if the sniping software starts out too soon, then two snipers will have enough time to do enough rounds to hit one persons max. If this is the case, no real harm, no foul.
But... if they wait till about 10 seconds before the auction ends.... well, then there may not enough time to do the requisit number of rounds.
From the sellers perspective, it is not good, as it keeps the price below what the buyers are willing to pay.
From the loosing buyers perspective, it is not good since they didnt have enough time to submit a new bid.
From the winners side (you), it is wonderful since you got it below your cost.
things that throw monkey wrenches into the works (from the buyers perspective) are items like starting the process too early, going up against the user with a large auto-bid amount (you always loose, maybe just as well) and choosing too large of a bid increment (rather than ramping up $20 you ramp up $100 in 30 seconds).
buyers remorse and overbidding are the bidders problems, not the sellers. As for misspelled items, that is a totally different discussion for another time.
Overall, I avoid ebay. I have enough crap in my life and dont need any more, I dont care how cheap it is. (cuz the more stuff you have, the bigger the house you need. Then you fill it up with more stuff, and before ya know it, you are stuck in a george carlin comedy routine)
You are confusing sniping with the proxy/autobid process.
If one person selects proxy bid (in other words, they tell ebay to auto bid up to a given point) then all works up to the max bid process (or at least up to the point where the sniper runs out of time).
But if two folks are using sniping software (outside of ebay's control), then this is what happens:
10 seconds before the auction ends, the software for one user checks the current bid (say $10) and then submits a new bid with the minimum increment ($1) up to their max. This is not $100, but $11 (yes, you can configure the software to use higher increments to avoid the issue of getting a bid rejected because another sniper already put in for $2 rather than $1, but that is a different discussion for a different time)
The next user comes in and does the same thing, again incrementing by the minimum.
Depending on how soon before auction end the stuff starts, they only have a chance to get 3 or 4 of these exchanges in before the timer goes off and the bid ends.
Now, if you had one bid sniper vs the autobidder, again, each resulting in an automatic 'bid minimum' increase, the sniper would only have a chance to up the bid 3 or 4 times, depending on server response time and how soon before the end they started. So in our hypothetical case, the bids may get up to $20 or so if there is time to do 5-6 rounds (bid, check current price, resubmit new bid with minimum increment). The autobidder will win only because the ebay software will respond instantly (latency of 0).
Assuming a latency of 0, then yes, the sniper and the autobidder will end up with the same result as no sniper and everybody using autobidders. Of course, only in a physics class can we assume a latency of 0.:-)
On the buyers side, it rewards the person with the best timing. On the sellers side, it keeps the price lower that it should be.
We are not talking about 'max bid' entries where two interested folks tell EBay what their max price is and it automatically gives it to the higher of the two at a price just above the loosers price. That is more or less OK by everybody's measure.
We are talking about software run on the clients system (or a proxy system) where the max bids are secret. The packages then try and out-time each other at the very end. In this case, the auction goes not to the person who is willing to pay more, but to the person who manages to slip their bid in at the last second.
Example: Bob and Jane both use EBays max bid option and put in a max bid of $100, but Bob entered his bid first. If they both used ebay's max bid, the auction would go to bob for $100. Simple enough.
Enter the bid software. The auction is listed at $10 starting price. Neither users software mades a move until the last second, slipping in a bid for $11. The first one in wins, and if there is not enough time to put in a counter bid, the selling price is $11. (in reality, the software often puts in a bid 30 seconds or so too soon just in case the clock is off, which gives a chance for 2 or 3 rounds of counter bidding till the time is up).
To the buyer, this is great. They were willing to pay $100 but got it for $11. To the seller this is horrid, they had two buyers willing to pay up to $100. To the looser this is also not optimal, since they would have been happy to pay up to $100.
It no longer becomes an auction, it becomes a lottery. Add in a 5 minute auto-extend and sniping becomes impossible.
While it is true that the data can be recovered after multiple passes, what most folks forget to mention is the level of effort required to recover such data.
Think hanging chads, but on a much larger scale.
You get to pull the disks, and start walking them with an electron microsocope looking for the 'residual' images. Then you get to make a guess as to the 'bit' being a 1 or a 0. Then you get to start assembling a filesystem on top of all of that.
Yes, it is possible, but it would take a very, very long time.
Generally speaking, overwriting the data _once_ is enough to tormet your local law enforcement agency. The level of effort required is just too much for them to deal with the issue given the other things that they need to do. (rumor has it that in the old days they could just modify the firmware to shift the drive heads over a touch, but that trick does not appear to work as much with newer drives since there is not much space between tracks anymore)
The reason that the Military/NSA/FBI/CIA want to actually destroy the disks is because even though it is _difficult_, it is still _possible_ to recover the data.
Please note that for this to work, you must overwrite the actual sectors on the disk (aka "wipe"), not just blow away the metadata (aka "delete")
It all depends on what your definition of "exercise" is.
For me, a 30 minute walk is not exercise. Its a walk. Compared to just sitting there or doing normal activities (getting up for a cup of coffee at the office), it probably has no huge impact.
Now, a 2 hour run/power walk up Barr trail to Barr Camp (6 miles, 4,000ft gain, one way)... That's exercise. (yeah, I know people who can do it in about an hour.)
That said, from personal experience, I did not loose weight until my activity level hit a certain level. In my case, I lost 15lb (7kilo) in 6 weeks by going from 15 miles per week of running to 30+ per week. It seemed that I needed to hit a certain threshold before my system would drop the weight. As long as I stayed above 30 miles per week I was loosing weight.
Of course, I also ate a "sensible" diet, ate 6x a day and made sure I was never hungry.
Thus, to follow my miracle weight loss program, you need to do the following:
1) Eat "clean": Avoid junk foods 2) Eat often: 6x a day 3) Eat enough: the body will sacrifice muscle and keep the fat if you starve yourself. 4) The main one: lots of intense exercise. HR in the 70-90% range. Use a hear rate monitor if you need to. Do it 5x a week for at least 40 minutes each time. Try and get in one 2+ hour 'easy' session once a week. Cycle the 'hard days'(90% for 30 min) with 'easy days' (45 min for 70%). But intensity is the key.
Yeah, its that last one that folks dont like. (Note to weightlifters: you can do the same thing in the gym by moving huge amounts of volume and do it with intensity. )
This easy to follow program will work wonders for you*.
(* consult your dr before starting. May not work in all parts of the world. Not approved for use in the state of california, etc, etc, etc).
The linked to press release for TMS systems are not a single drive. They are a half rack sized array. Dont try and put one in your desktop anytime soon. Their systems have been in use for years by folks who need speed at any cost.
Now, the BitMicro drives... those look interesting. I wonder if I can slot them into my StorageTek 6140:-)
The case you give is more likely in a 'regular' district. You are a democrat writing about an issue of interest to only a democrat and you happen to be writing to a republican congressman since you are in a 'red' state and thus in the minority (lets say 48% to 52%). They will know that you didnt vote for them and may blow you off. If, however, you have one of each, you can cherry pick which one to send the letter to based on the one that is more likely to care about your issue.
Compare this to the 1:1 ratio, and you can see the advantages of being able to route the letter to the elected official most likely to care about your case.
It also has some interesting games from the point of how many politicians to field. Lets say only the top 2 will be elected. Does your party field 2 candidates in the hopes of getting both but at the risk of loosing both (if the other party does the same) or do you only put up 1 and guarantee a spot? 3rd party candidates can also wreak havoc with this sort of setup (which is a good thing in my view)
of course, if you are using raid-z/mirroring, trust the system and dont have anywhere to plug a new drive in, you could get away with pulling the old drive, dumping in a new drive and running `zpool replace ` on the updated drive (new_device defaults to old_device if it is not specified).
If you charge customers for using more than X, then it is hard to tell them that their service is "unlimited". (you would then open yourself to being sued for false advertising)
Now, if the ISP would just admit to how much they are willing to sell you (think cell phones), then maybe this will work.
I'm sure suse is better than redhat, but RH has the 'market' in the US and oracle picked RH as the basis for OEL, not SUSE. Of course, its all 'linux' (i know, its not) but that is another issue for another day.
:-)
For multipathing, I was mostly talking about FC networks. That said, we also use it a lot for our IP networks. It is easy to setup on solaris and windows, but not linux. We've had "fully redundant" cisco switches go down due to a hardware failure before. So the idea of pulling everything back to a single switch is not a good idea. For $10k (list) extra, we just get two chassis and put a single supervisor in each one. This way an entire chassis can fail and nobody notices (in theory).
As for zones vs a hypervisor, that is an example of having several tools to fit the job. One is a screwdriver, the other is a hammer. When I want a copy of the base OS, zones are much nicer. They get patched with the base OS, they dont take much disk (150m with sparse root zones) and the performance hit is not even measurable. ESX/Xen/Etc are the other end: you have to fully manage them as another instance, they take up a lot more disk, and performance issues abound (depending on what you are doing)
And we are looking at brandz... just what we need, to run a linux zone on a sun box... It does look attractive and I'm going to give it a try
As for the strace vs truss debate, I left that out. strace is still a subset of truss, but kmdb and dtrace go even further.
Linux just works? Yeah, maybe for a small system running a simple app stack.
/dev/sde came from vs /dev/sdf. When you have 20 luns mapped to the same host from two different arrays, its kinda important to know which drives come from which array and what the corresponding lun numbers are. That said, most linux admins I've talked to didnt have a clue about what I was talking about since they never had a san.
/proc and watch the fun start.
I had to setup an oracle cluster: Thanks to Oracle's support policies, we could not use Solaris x86. Nor could we use RHEL5 (no Oracle 9i support), so RHEL4.6 it was. Should be easy, right? Well tested "enterprise" class linux that can do everything the big boys can do.... We took the hardware we were going to use for solaris and switched it to linux. A pair of Sun x4600M2's, 128G of ram, 4 Dual core AMD's. Sun fully supports linux on this box and RedHat lists it on their HCL. Should be easy.
The basic OS install was more or less easy, once we battled through the serial port redirection setup (guess most linux users never used a serial port before. After all, why bother when the box sits under your desk). I stil like serial ports over video for one major reason: issue resolution (when bad things happen, having that panic string saved by a console server can really save the day)
Ok, so the system was kickstarted and now it is time to set it up for use as an oracle DB. This is a production system, and we need lots of space (4TB) and High Availability. This means redundant connections to everything, mirroring and clustering.
Issue #1: multipathing drivers for the SAN. With solaris, you just plug the thing into the san and all of the storage that the host has access to just showed up. Multipathing was instant and I didnt have to do jack. I could see what devices mapped to which physical array with a simple command. I didnt have to guess which array
Issue #2: dynamically add luns: With solaris, you just change the mapping on the array and the host picks it up and auto creates the dev links. That was easy. On Linux? you've got to be kidding me... You get to echo some crazy strings into several spots in
issue #3: IP Multipathing. With solaris, dladmin is used to create a bond (if it is going to the same switch and the switch supports bonding) or use the built in ip multipathing to do an active/failover setup if you are going to multiple switches. Very well documented and very easy to do. With linux... yeah, bonding is a fun task. Need to go to multiple switches? no such luck, you are screwed. I eventually used VCS to take over the systems main IP and uses its IPMultipathing agent to do the job for me. VCS on solaris just hands the task off to mpathd since the OS already does it for you.
Issue #4: zones: dont get me started. I dont want to run another entire OS, I just want name space isolation and chroot is so primative it is not even funny. Zones gives me everything I want with minimal overhead. It would have been nice to have since there are a few oracle products that dont play nicely with clusters (*Warehouse Builder*) because they imbed the host name everywhere. We could put it under Xen, but this is an app that moves huge amounts of data around, not exactly a good candidate for virtualization. Zones let us get around Oracle's brain dead use of the hostname, no such luck with linux.
Issue #5: 3rd party drivers vs the new kernel patch. If I install a 3rd party device driver in solaris and upgrade the kernel, I dont have to rebuild/reinstall the driver. Linux (even redhat 4.x with their "back port") forces me to rebuild/reinstall every damn time. Its great if the driver is standard with the kernel, but if you need something outside of that (lsi multipathing drivers to get around #1 and 10G NIC drivers in my case) and you are screwed. No wonder up2date ignores all of the kernel* rpm's by default.
Issue #6: Whats the system doing? Solaris: `mdb -k` and dtrace. Linux: still trying
Define "too old".
:-) (dont get me started, my biggest annoyance with "linux" is that everybody follows their own "standard" for how to configure the system.)
For an entry level class, you need to start with the classic: UNIX System Administration Handbook (3rd Edition, 2000) by Evi Nemeth, et al. If you want to focus on linux, you can go with Linux Administration Handbook (2nd Edition, 2006) by the same authors.
Once you learn the basics, you need to pick a flavor and dive in with more "up to date" stuff. Something that covers zones, smf and zfs for solaris folks. I'm sure there are new features to linux, but I cant think of any at the OS level that dont vary widely by distro
Unix is 30+ years old and the basics still have not changed in a very, very long time. Its like complaining that a programing class is still using a 10+ year old book to explain looping and variable scoping.
I remember going through this with cisco the first time when they offered the 16 port or 32 port (2Gb) line cards, depending on what your access patterns were.
Most corporate san and network environments are bursty in nature. Clients pull a bunch of data and then think about it for a long time. Not many go full bore all day long. If this is the access pattern, then the MDS systems are fine since the chances of everybody trying to pull 4Gb at the same time is nil.
If, however, you are running a huge supercomputer site that must moves huge amounts of data around all the time as fast as possible... well, lets just say that the MDS is not what you want (unless you want a 132 port switch that takes up half a rack and doubles as a space heater)
I'm sure the folks at cisco will eventually have local switching. They offer DFC's for their ethernet products that do just that, so they have the technology.
I hope they do, the thing I hate doing the most is running all of the cables to the servers and storage. I know larger shops have 'people' who do this for them, but I'm not lucky enough to have a team of lackies to do the grunt work for me. :-)
The 9132's run SAN-OS and offer all of the features one would expec, so I think they actuall did it themselves this time.
:-)
I dont know what the old McData's were like in terms of power. Brocade was proud of their 1W / Gb power envelope (4w per port). The new 9132's look like they are close to that. For what is worth, brocade has a power calculator for the 9513 vs thier 4800 at http://www.brocade.com/products/directors/power_draw_density_calculator.jsp (the numbers look close to real world, so it is a good start). The new Brocade DCX pulls about the same power. More marketing dirt can be found here: http://www.brocade.com/products/competitive/directors.jsp and http://www.brocade.com/products/competitive/references.jsp (I'm sure cisco has a similar page for brocade equipment)
Of course, only cisco offers 528 4G ports on a single chassis (as long as you cable stuff to avoid oversubscribing the backplane. Again, in theory this can be done but in practice one just needs to be a bit more careful).
And lord help me if I ever manage an environemnt that requires that many san ports. I have enough to do now as it is.
I have to make the decision with what is available now based on what my requirements are and what I estimate them to be over the next 3 to 4 years.
:-)
In other words, my choices today were gig-e and 10G-E iSCSI, 4Gb and then 10Gb FC. Anything else was not an option since it simply does not exist outside of the lab (or at a resonable cost).
At this time, 4Gb FC made the most sense for our storage network. It is well understood, everybody supports it and the things "just work". I didnt see any major storage vendors offering 10G-E iSCSI arrays just yet. Of course, those Force10 switches sure do look nice
I did pick up a a pair of 10Gb-E cards for our netbackup server since right now it is saturating the Gig-E network that we have for hours at a time trying to pull in data from all of the clients (fun with D2D2T backup solutions) (and for those wondering, off host backups are not an option for a bunch of individual app servers using internal storage) Of course, once the data is on the NBU server, it sends it to the array via 4Gb FC at a rate of 600MB/s. And then there is the part when it needs to move the data from the array to the LTO tape drives (a single lto-3 can move at 160MB/s, and they dont support iSCSI).
I hope that in 4 years or so, I can stop running so many damn cables to the servers and get away with a pair of 10Gb or faster . Until then, I'm stuck running 2 fiber FC cables and 4 copper gig-e's (two public, 2 heartbeat for the cluster) to most of our major systems and ESX boxes.
The 9134's look a lot like the Qlogic 5600's. They both have the same issue: Stacking two will oversubscribe the 10Gb FC interconnects. I know that there are ways to avoid this in theory, but luck always has it that I never have a port available where I need it for optinal performance. Thus things like the 4900 are so nice in that it is next to impossible to screw up :-)
:-)
That said, I'm happy to see that cisco finally got their power consumption under control with the 9134's. The older models sucked so much power that it was not even funny (Like a lot of folks, I'm limited on 3 things in my datacenter right now: space, power and cooling)
I did entertain quotes for a 9506 from the cisco folks. But when I compared the physical size, power requirements and cost (2x as much for 64 blocking ports), it did not make sense in my environment. The 9509 was just way too big to put anywhere after our network team droped in a pair of 6509's at each site and took most of the remaining power and space that we had. The cisco folks never even offered the 9134 as an option.
As for the Nexus vs Sun magnum, Cisco's bread and butter is ethernet, so that made sense. Sun just went for whatever gave them the best performance, and the fact that the HPC world was already used to Infinitiband made sense for them. That said, sun moves 110Tb/s in their switch vs Cisco's "System designed for investment protection with a 15 Tbps highly scalable fabric". Ok, so the cisco one is a bit smaller, but still, its not that much smaller
I guess that is why we run 50/125 multimode everywhere. the 62.5 just didnt cut it anymore for higher bandwidth applications :-)
Maybe you are thinking about 9micron singlemode fiber?
Our original SAN consisted of four MSS 9216's with the 32 port blades for a total of 48 ports per switch. Two at each site (stretched fabric, 3k of dark fiber between the two sites, dual fabric, bla, bla, bla) Every server has two ports and thus full redundancy in the event of a switch/cable/whatever failure. (ever try and bond two ethernet ports between two switches?).
:-)
:-)
To replace the aging MDS switches we went with four Brocade 4900's. We have what I would call a medium sized environment, so the larger brocade switches did not make sense, but then again neither did the little things like the Brocade 200E. We have some hosts who will push 500+MB/s of traffic through our SAN, so trying to bond a ton of ethernet ports together did not make sense (think of the cables). Of course, bonding to a single switch is easy, ever try bonding between two physically different switches for redundancy? (to save money, our 6509's only have 1 sup, so we need switch diversity). Storage multipathing is easy with a dual port 4Gb hba. One could argue that a dual port or a 10G-E card allows for failover but removes the need for bonding. Of course, guess which one is cheaper
The nice thing about the 4900's vs the cisco MDS switches are as follows;
1) Smaller (2RU for 64 ports)
2) No oversubscription (64 ports, 4Gb any to any)
3) Less power. (Not even close)
4) Hitless firmware upgrades (cisco sorta has this with the MDS 9500, at 10x the cost)
5) Ooooh, shiny box
At the same time our network folks were purchasing some 10G line cards for their Cat 6509's. Lets just say that the 8 port card with optics cost more than my 64 port 4900 with optics. They got 160Gb of bandwidth (assuming you never leave the card when it quickly falls to 40Gb), I got 512Gb.
Just for kicks I also looked at their costs for the 48 port gig-e line cards. Loking at just the cost of the cisco line cards (6748's) and ignoring the cost of the chassis and supervisor, my cost per Gb was just a touch under theirs (and mine included the whole chassis). Of course, 256 ports of gig-E takes up a lot more space, more cables and I still have the bonding issue for redundancy.
I'm sure some day we will see it all merge together. Whitness the Magnum switch from Sun: http://www.sun.com/products/networking/datacenter/ds3456/
Until then, I'm sticking with ethernet for IP and FC for storage.
Hope they fix the pricing issue, because I the FC network I just put in cost less per Gb than a 1 gig-E network. When compared to the cost per Gb of a 10G-E netowrk, the entire thing cost less than the optics on the 10G stuff, let alone the actual switch costs.
;-)
I'm also noticing that most if not all of my systems never even tap the bandwidth available on a pair of 4Gb FC ports, let alone 10Gb. I'm sure there are folks out there who need it, but it aint us.
Of course, our corporate standard is Cisco, so I'm sure that had something to do with the high cost of the ethernet equipment
In this particular case, the Sun system has two sockets (8 cores per socket) which run at 1.4GHz vs a 4 socket (dual core per socket) IBM running at 4.7 (I didnt find a nice benchmark for the new 5.0's) . If you add up the MHz, IBM has an almost 2:1 lead (37.6 vs 22.4) and yet they score the same on the benchmark.
Note that the article is also wrong on some of the numbers. Sun's T2 runs at 1.4, not 2.4.
> as others have pointed out you're completely and utterly wrong.
Several other folks have told me the following: the sniping software gives ebay their maximum bid so it is just like using the maximum bid option, but prevents nibblers from driving the price up.
The evidence (in the form of bidding histories for closed auctions) shows that the software is often not exactly doing as many have suggested. I may be off on the 'rounds' part as far as modern sniping software goes (I do remember seeing software that did just that way back in the dawn of time, like before 2000 when this 'internet' thing was just starting to take off), but it goes not appear to ever directly give ebay the users actual maximum bid as they claim.
When folks first started yelling that I was totally off base, and that the software was actually placing the snipers actual maximum bid into the ebay system, I was a bis suspicious. Their explanation sounded wrong, as it provided little advantage over the normal process of directly telling ebay the maximum you wanted to pay. So, I quickly scanned a few dozen auctions and tried to determine the bidding pattern of last minute bidders. If the software was acting as I suspected it would, there should be an obvious pattern. If it acted like everybody was telling me it would, there would be a different pattern.
Overall, I speculated that with sniping software, a last minute bid would not raise the bid price by more than 2x the increment. If there was an outstanding autobid for more than this last second 'snipe', I would then see that users who had previously placed auto bid jump past that person by the min bid amount.
Based on looking at the bid histories, this became clear: if an existing autobidder still was willing to go much further, then the last second snipe didnt do more than bump up the final price by 2x the increment (snipers bid then the automatically generated counter). If there was no existing autobid still in play, then the snipe would succeed in winning the auction at the current price plus the increment. (if the existing autobid was more or less at its cap, then the sniper could still win if they gave their bid a small bit of 'headroom', but this was rare).
If the software worked the way everybody is telling me it does, I would see a situation where the last second bids would be significantly jump more than the minimum bid increment as it zoomed in on the lower of the two maxes plus the increment.
For example (yes, this is overly simplistic):
We have two bidders for some rare widgets: User A has told ebay directly that they are willing to pay up to $50 for the widget. User B is using 3rd party sniping software and has instructed it to go up to $40.
The auction has 30 seconds to go and is at $20. Min increment is $1.
As a general rule, this is what I'm seeing:
With a few (30 or so) seconds left, User B would place a bid for $21.
The system would then proxy bid for User A at $22.
The auction would end. User A wins the auction for $22.
This is what would _should_ happen if the software is doing what everybody is telling me it does:
With a few (30 or so) seconds left, User B would place a bid for $21 with a max bid of $40
User A would then get an autobid for $41 (B + the increment)
The auction would end. User A wins the auction for $41.
Since it appears the sniping software makes a last second check to see what it should bid, it prevents the bids from skyrocketing at the last second. This saves the snipe software user money, so they use the software. (otherwise they would just do what user A did and be done with it)
It appears that the sniping software may not go round and round (as another person has noted, this would kill ebays servers, but I'm sure it was done at one time for obvious reasons. My guess is that they alter their api every time they detect 'overly aggressive' sniping software).
What the current crop of software appears to do is poll ebay once with less than a minute lef
yes, the sniping software uses the autobidding as its target rather than the auction directly. Its a level of indirection that I left out to make the original explination simpler. (otherwise it got really convoluted).
And I have noted that each one has a different algorighm (last second proxy bid vs multiple increasing proxy bids).
But here is the big question: If it only places 1 bid and folks have pointed out, and that bid is your actual max... then what is the advantage (other than avoiding buyers remorese for the sniper) over just entering your max bid directly in the ebay system directly when you first note the item?
I never see a last second bid for more than a single increment over the existing bid. If there were multiple snipers, you would expect to see a larger jump since both entered their 'max' bids and the system would take the lower of the two plus the increment. This is not a pattern I've ever seen. Its as if at the last second multiple folks using sniping software enter a max bid that is more or less equal to the current minimum bid and then the rest get ignored. The first one in wins. This strategy differs from what you and others have indicated as 'the way it works'. (where the proxy bid software would go with a larger final increment).
Now, I never said that sniping was bad for the winner (it can even be good for the looser if they dont know how to control their emotions). But overall, it is not good for the seller.
According to you, there is never a need for a 3rd party bid sniper since they all just use ebays proxy bid path and punch in the max bid? Given the very large number of bid sniping software packages out there, this is obviously not the case.
Look at software packages like bidsnapper. Carefully read between the lines from their faq at http://www.bidnapper.com/faqs.php3
"In most cases your bid will be adjusted one bidding increment above the previous high bidder. Bidnapper uses the proxy bidding system to bid just enough to make you the winner, up to your maximum bid."
Now, they are using ebays proxy bid to make the bids for them, but then it becomes an auction via ever increasing 'max bid' proxy bids rather than the bids on the direct auction items. Last one in with a higher 'max bid' wins. This may or may not be the actual max bid number you entered in the software. If it can avoid telling ebay that number, then it saves you money. Otherwise you can just tell ebay that number directly and bypass the bid sniping software.
Bidding via the proxy helps them get around the latency issue, but it still does not start off with your 'max' price right off the bat. And that is the key.
The theory stays the same, try and slide in the lowest possible bid right at the end. The target just got moved a bit to the side.
As I pointed out, sniping can be good for the bidder (esp if there is not enough time to do enough rounds to hit your max price).
Now, if the sniping software starts out too soon, then two snipers will have enough time to do enough rounds to hit one persons max. If this is the case, no real harm, no foul.
But... if they wait till about 10 seconds before the auction ends.... well, then there may not enough time to do the requisit number of rounds.
From the sellers perspective, it is not good, as it keeps the price below what the buyers are willing to pay.
From the loosing buyers perspective, it is not good since they didnt have enough time to submit a new bid.
From the winners side (you), it is wonderful since you got it below your cost.
things that throw monkey wrenches into the works (from the buyers perspective) are items like starting the process too early, going up against the user with a large auto-bid amount (you always loose, maybe just as well) and choosing too large of a bid increment (rather than ramping up $20 you ramp up $100 in 30 seconds).
buyers remorse and overbidding are the bidders problems, not the sellers. As for misspelled items, that is a totally different discussion for another time.
Overall, I avoid ebay. I have enough crap in my life and dont need any more, I dont care how cheap it is. (cuz the more stuff you have, the bigger the house you need. Then you fill it up with more stuff, and before ya know it, you are stuck in a george carlin comedy routine)
You are confusing sniping with the proxy/autobid process.
:-)
If one person selects proxy bid (in other words, they tell ebay to auto bid up to a given point) then all works up to the max bid process (or at least up to the point where the sniper runs out of time).
But if two folks are using sniping software (outside of ebay's control), then this is what happens:
10 seconds before the auction ends, the software for one user checks the current bid (say $10) and then submits a new bid with the minimum increment ($1) up to their max. This is not $100, but $11 (yes, you can configure the software to use higher increments to avoid the issue of getting a bid rejected because another sniper already put in for $2 rather than $1, but that is a different discussion for a different time)
The next user comes in and does the same thing, again incrementing by the minimum.
Depending on how soon before auction end the stuff starts, they only have a chance to get 3 or 4 of these exchanges in before the timer goes off and the bid ends.
Now, if you had one bid sniper vs the autobidder, again, each resulting in an automatic 'bid minimum' increase, the sniper would only have a chance to up the bid 3 or 4 times, depending on server response time and how soon before the end they started. So in our hypothetical case, the bids may get up to $20 or so if there is time to do 5-6 rounds (bid, check current price, resubmit new bid with minimum increment). The autobidder will win only because the ebay software will respond instantly (latency of 0).
Assuming a latency of 0, then yes, the sniper and the autobidder will end up with the same result as no sniper and everybody using autobidders. Of course, only in a physics class can we assume a latency of 0.
Here is the issue with sniping:
On the buyers side, it rewards the person with the best timing. On the sellers side, it keeps the price lower that it should be.
We are not talking about 'max bid' entries where two interested folks tell EBay what their max price is and it automatically gives it to the higher of the two at a price just above the loosers price. That is more or less OK by everybody's measure.
We are talking about software run on the clients system (or a proxy system) where the max bids are secret. The packages then try and out-time each other at the very end. In this case, the auction goes not to the person who is willing to pay more, but to the person who manages to slip their bid in at the last second.
Example: Bob and Jane both use EBays max bid option and put in a max bid of $100, but Bob entered his bid first. If they both used ebay's max bid, the auction would go to bob for $100. Simple enough.
Enter the bid software. The auction is listed at $10 starting price. Neither users software mades a move until the last second, slipping in a bid for $11. The first one in wins, and if there is not enough time to put in a counter bid, the selling price is $11. (in reality, the software often puts in a bid 30 seconds or so too soon just in case the clock is off, which gives a chance for 2 or 3 rounds of counter bidding till the time is up).
To the buyer, this is great. They were willing to pay $100 but got it for $11. To the seller this is horrid, they had two buyers willing to pay up to $100. To the looser this is also not optimal, since they would have been happy to pay up to $100.
It no longer becomes an auction, it becomes a lottery. Add in a 5 minute auto-extend and sniping becomes impossible.
When dealing with the military, you also have to factor in the difficulty level of the instructions.
:-)
Which is easier:
Run this application, selecting the entire drive, following these procedures, bla, bla, bla
_or_
Smash drive into little bits
Now, you also have to take the 'fun' factor into it while you are at it. Smashing the drive is a lot more fun
While it is true that the data can be recovered after multiple passes, what most folks forget to mention is the level of effort required to recover such data.
Think hanging chads, but on a much larger scale.
You get to pull the disks, and start walking them with an electron microsocope looking for the 'residual' images. Then you get to make a guess as to the 'bit' being a 1 or a 0. Then you get to start assembling a filesystem on top of all of that.
Yes, it is possible, but it would take a very, very long time.
Generally speaking, overwriting the data _once_ is enough to tormet your local law enforcement agency. The level of effort required is just too much for them to deal with the issue given the other things that they need to do. (rumor has it that in the old days they could just modify the firmware to shift the drive heads over a touch, but that trick does not appear to work as much with newer drives since there is not much space between tracks anymore)
The reason that the Military/NSA/FBI/CIA want to actually destroy the disks is because even though it is _difficult_, it is still _possible_ to recover the data.
Please note that for this to work, you must overwrite the actual sectors on the disk (aka "wipe"), not just blow away the metadata (aka "delete")
It all depends on what your definition of "exercise" is.
For me, a 30 minute walk is not exercise. Its a walk. Compared to just sitting there or doing normal activities (getting up for a cup of coffee at the office), it probably has no huge impact.
Now, a 2 hour run/power walk up Barr trail to Barr Camp (6 miles, 4,000ft gain, one way)... That's exercise. (yeah, I know people who can do it in about an hour.)
That said, from personal experience, I did not loose weight until my activity level hit a certain level. In my case, I lost 15lb (7kilo) in 6 weeks by going from 15 miles per week of running to 30+ per week. It seemed that I needed to hit a certain threshold before my system would drop the weight. As long as I stayed above 30 miles per week I was loosing weight.
Of course, I also ate a "sensible" diet, ate 6x a day and made sure I was never hungry.
Thus, to follow my miracle weight loss program, you need to do the following:
1) Eat "clean": Avoid junk foods
2) Eat often: 6x a day
3) Eat enough: the body will sacrifice muscle and keep the fat if you starve yourself.
4) The main one: lots of intense exercise. HR in the 70-90% range. Use a hear rate monitor if you need to. Do it 5x a week for at least 40 minutes each time. Try and get in one 2+ hour 'easy' session once a week. Cycle the 'hard days'(90% for 30 min) with 'easy days' (45 min for 70%). But intensity is the key.
Yeah, its that last one that folks dont like. (Note to weightlifters: you can do the same thing in the gym by moving huge amounts of volume and do it with intensity. )
This easy to follow program will work wonders for you*.
(* consult your dr before starting. May not work in all parts of the world. Not approved for use in the state of california, etc, etc, etc).
The linked to press release for TMS systems are not a single drive. They are a half rack sized array. Dont try and put one in your desktop anytime soon.
:-)
Their systems have been in use for years by folks who need speed at any cost.
Now, the BitMicro drives... those look interesting. I wonder if I can slot them into my StorageTek 6140
The case you give is more likely in a 'regular' district. You are a democrat writing about an issue of interest to only a democrat and you happen to be writing to a republican congressman since you are in a 'red' state and thus in the minority (lets say 48% to 52%). They will know that you didnt vote for them and may blow you off. If, however, you have one of each, you can cherry pick which one to send the letter to based on the one that is more likely to care about your issue.
Compare this to the 1:1 ratio, and you can see the advantages of being able to route the letter to the elected official most likely to care about your case.
It also has some interesting games from the point of how many politicians to field. Lets say only the top 2 will be elected. Does your party field 2 candidates in the hopes of getting both but at the risk of loosing both (if the other party does the same) or do you only put up 1 and guarantee a spot? 3rd party candidates can also wreak havoc with this sort of setup (which is a good thing in my view)
zpool replace [-f] pool old_device [new_device]
of course, if you are using raid-z/mirroring, trust the system and dont have anywhere to plug a new drive in, you could get away with pulling the old drive, dumping in a new drive and running `zpool replace ` on the updated drive (new_device defaults to old_device if it is not specified).
If you charge customers for using more than X, then it is hard to tell them that their service is "unlimited". (you would then open yourself to being sued for false advertising)
Now, if the ISP would just admit to how much they are willing to sell you (think cell phones), then maybe this will work.