That's nothing... I typed "The quick brown fox jumps over the lazy dog" into an e-mail message I was sending on my iPhone, and it suddenly morphed into a Zune..
I guess a similar technique works on the ARM processor also:-(
I propose the x86 instruction set be altered to add an additional byte to every instruction, a NUL byte or NUL word, so every instruction will have an additional 2 to 8 bytes of overhead, at least 1 must be set to all bits 0, and the following byte must be set to all bits 1.
Since the NUL byte cannot be expressed in a sentence and commonly causes I/O to terminate (i.e. delineates the end of the string), x86 code can then not be disguised as a sentence.
Also, the following byte being all bits 1, assures that the instruction cannot be transmitted over protocols that do not provide 8-bit support.
Further, the all-bits 1 sequence should be removed from ASCII and banned from use by any network protocol: to transmit such bits, you must encode in Base64.
Multithreaded database applications do not hit a drive with sequential 256K block requests.
They very well may hit the drives with 256K random block requests, especially when committing a large write.
To a great extent, this is dependent on the specific OS and the filesystem involved, how much caching is done, including read-ahead caching.
Your average SATA drive can push 60 random IOPs at 256K, not close to 1000.
With ZFS in particular, the DB writes are prone to occur in 128K blocks sequential, and the reads are prone to be random, even for a multi-threaded DB.
While reads are frequently 16 - 64K
And 100 MB/s isn't that impressive, when the transfer technology should be capable of 768 MB/s
due to the 6 gigabit SATA interface.
Until a power supply on the array blows up, taking both controllers, a critical control board, part of the backplane, or a bunch of the drives with it.
You think most databases in the wild are 10TB+ OLTP systems running Oracle?
I think the most common database apps are 5g - 50gb MS SQL Server and MySQL databases, used for a slew of applications.
And table scans are very common, especially when performing certain joins.
In many cases a table scan is much faster than an index scan in real-world databases due to I/O block sizes, and this is a decision that the query planner will make over time, reliant on statistics available to it.
In real-world databases, using indexes would be slower than simply scanning, for many common types of queries, especially when much of the dataset will be selected by the query, or have operations applied to it..
e.g. SELECT SUM(*) from mytable where id > 10;
If 90% of the rows have id>10, there is no point in starting with an index seek.
The X-25M is an 160gb HDD, half the capacity.
The IOPs of SSD drives are so large, that in fact, a 30 or 40% IOPs difference is basically irrelevent for DB apps; transfer throughputs for random reads/writes at various block sizes are the most telling factor.
Being able to quote 30000 IOPS is useless, if that number cannot be sustained with at least a 256K blocksize, commonly used for filesystems and database apps.
Small random reads/writes are rare in the most demanding real-world apps.
And the Collossus showed to be quite superior to the X-25M in this regard.
We can see quite plainly the OCZ drive
outperformed the X-25M on the file copy tests by a massive margin.
And in the average write transfer speed compared to the X-25M.
The X-25M plain wasn't good at all with large writes.
The OCZ Colossus' random write capabilities were just plain impressive as shown in YAPT Random writes test. 200 MB/s random writes, for 128Kb blocks/larger, VS 100 MB/s with the Intel X-25M
And even at 64K blocks, it was no worse than the X-25M
There's this thing called ANSI standard SUSHI (ANSI/NISO Z39.93-2007), also referred to as the sushi standard.
And as demontrated at the above URL, it has absolutely nothing to do with fish, or at least it's not supposed to be.
If I ask for SUSHI, and I get some type of fish instead, and they call that sushi, clearly some sort of fraud has occured.....
And perhaps using SUSHI can be hazardous to your health, but only really to the extent that all programming is hazardous to your health.
I was unable to apprehend the article's concept that you would order or ask someone to give you SUSHI and they'd give you a toxic fish instead of the specification.
Nor did I realize it was so easy for people to be confused into thinking that specifications such as Sushi are edible, or that people would actually be so oblivious as to confuse a piece of fish for a copy of a national standard...
Which are inconvenient but not toxic. The fish hasn't been shown to kill or cause long-term harm. But has unpleasant digestive system side effects in some people. If you experience any of those effects ever, stop eating the fish, but it's your problem not the fish's, and not a problem everyone has:)
I wouldn't suggest eating it, but it sounds as if the effects are short-term, not all people are necessarily effected, and primarily occur if the portion size is too large and not prepared in a way to reduce oils.
More like an unwanted effect than something truly toxic that would be likely to kill you or have a long-term health effect.
So limit the amount of sushi you eat, to a sane amount. No more than a 5 oz piece aday, for sure. Definitely don't eat Sushi multiple times a day, or multiple times in the same week.
In the case of Windows, you can remove the unwanted equipment from your computer and sell it.
Your perfectly within your rights (assured by the first-sale doctrine) to do that.
So long as you haven't accepted the agreement, and you still have the license material intact, you still have the legal right to sell it, and nothing legally prevents you.
But once you accept the EULA for Windows.. the EULA for OEM software won't allow you to transfer it to another machine.
It can be used only with hardware it was sold with. At some point, the final recipient who does accept the EULA will have to buy it with some piece of hardware, to be able to use it legally, e.g. you sell with some piece of hardware (such as a disk drive or motherboard).
The logic that you can pick the price of an item out of a package is wrong.
Do you think you should be able to buy a bundled package.. a complete computer from a vendor that was sold to you for $X price.. and return the Monitor or Keyboard, in exchange for a percentage of the price equivalent to the FMV of a monitor?
(Even though the 'monitor' wasn't an option, and its price is built into the bundle)
The manufacturer doesn't have to allow return of only one piece of a bundled package for its fair value. In fact... the fair market value of each item in the package when all the items are added together, may meet or exceed the price you were charged for the package.
You can no more rent a hotel room, and after you check into your room... demand to return the kitchen (i.e. have them close or lock it up), for a 30% refund (since your hotel rental has 3 rooms in it, kitchen, bathroom, bed). The cost of that item is already incurred by the retailer, and the relationship to the price of the package may be complex.
Parts of it may even be free or promotional.
In this case, however, the Windows EULA states that you are entitled to a refund if you refuse to accept. It doesn't provide for a restocking fee.
It would be a violation of the OEM EULA for a manufacturer to charge such a fee..
such a violation might imply that you are no longer bound by the agreement, if your response to not getting a refund is to use Windows, then it would seem that you are taking your self-help remedy in response for the retailer failing to follow the EULA, the EULA no longer properly applies to you, even if you click accept, due to the breach of the agreement by the other party.
Also, attempting to charge a restocking fee for refusing an unanticipated agreement, would probably result in litigation against the retailer, for deceptive/dishonest business practices.
However, the Windows EULA term also doesn't provide for separating Windows from the product.
My impression of the term was always... if you don't accept, you can return the entire package that Windows was bundled with, for a refund.
The EULA doesn't guarantee you can return Windows alone, or that you can get a certain price for it.
They are that far apart. SAS = 6 Gigabits/second transfer, SATA = 3 Gigabits/second transfer.
SAS supports multi-initiator, SATA does not.
SAS supports tagged command queuing, SATA supports only the sluggish native command queuing spec.
SAS devices support dual porting and multipath I/O allowing you to place devices in two different SAS domains for double I/O transfer per device and fault resilience, SATA does not have these options.
SAS devices have a unique id, WWN (SCSI ID), that can uniquely identify the device: SATA devices are identified only by port number, and this has scalability consequences.
A SAS channel can service a SAS domain with >16,000 devices using expanders, there is a great deal of expandability there. With SATA, one port = one drive.
SAS error-recovery and reporting is provided by the SCSI command set and is much richer than the SMART command set used by ATA devices.
The drive outperforms the mechanical drive in IOPs and block reads/writes which is what matters.
Databases actually tend to use larger block reads and writes, the drive would be perfect for most databases, that is, database load is just the type of load where this drive is better than other SSDs...
With suitable amount of system memory and host controller with reasonable cache, this drive would be phenomenal in table scan performance.
It's application loads that are heavy in small random reads and writes that the drive isn't that good for compared to some other high-end SSDs.
Still 5000 random IOPs in 1 3.5" package is nothing to sneeze at.
Most hard drives pull off a small fraction of that.
Yes, but if it was a PCI card, we couldn't plug these into external JBOD arrays that combine 24 drives and allows volumes/LUNs to be carved out and served up to various servers...
Actually, it'd be nice if they made it SAS instead of SATA.
WTH is with high-end hardware using the low-performance ATA standard instead of SCSI nowadays, anyways?
Running under VMware means there is less code running that is subject to attack (smaller attack surface), because there are fewer apps per guest, and the risk of a bug in VMware itself is approximately equal to the risk of a bug in your CPU microcode, due to the application of VT.
A perfect example of why computers should not allow humans to specify the password. Instead it should be randomly generated at time of manufacture, and the only password change operation allowed should be "generate a new random password"
That's where Windows 2008 MSCS, HAProxy, or Redhat cluster suite comes in.
For example, if you want a highly-available web service, you would have two VMware servers that you run a Webserver VM for on each server.
Then you would have a diskless load-balancer running HAProxy, to feet incoming web requests to a working web server.
For database services... you'd have a MySQL or MSSQL VM on each host, and a SAN or shared storage block filesystem with a GFS formatted LUN, and a Quorum disk (Linux) or Witness File share on a third physical host (for Windows 2008 MSCS), with clustering services configured so the SQL process is only active on the one host at a time, and only when quorum is met; if failure of another node is detected, a remaining node that can meet quorum will fence (KILL) the other VM, and then take over.
So in this manner, you can meet HA in a virtualized environment.
Although there are some considerations, like guest system clock accuracy, reliability of network connections to ensure an erroneous failure isn't detected during times of high load,
and supported configurations for OS vendors' clustering capabilities
It creates a configuration nightmare. Apps with conflicting configurations.
Changes required for one app may break other apps.
Also, many OSes don't scale well.
In a majority of cases you actually get greater total aggregate performance out of the hardware by divvying it up into multiple servers.
When your apps are not actually CPU-bound or I/O bound.
Linux is like this. For example, in running Apache.. after a certain number of requests, the OS uses the hardware inefficiently, and can't answer nearly as many requests as it should be able to. By dividing it into 4 virtual servers instead, for your 4 CPUs, you can multiply the number of requests that can be handled by 10 or 20 fold.
You may even think your CPU bound on Linux when you are not: load average may be high due to number of Apache processes that are contending with each other, and can create a false impression of high CPU or IO usage, when in fact, you have a bottleneck in the app/kernel's parallel processing capabilities.
Exchange is also like this.. better to scale out 2 virtual machines with 32gb a RAM and 4x3ghz CPUs dedicated to it each, than one server with 64gb RAM and 8x3ghz CPUs.
The former is a beefy server but doesn't have much advantage from adding the extra resources. The two servers virtualized on one box may have much better performance than 1 physical server, if you are using Intel Nehalem CPUs and properly configure your VMs (i.e. you actually do it right, and perform all recommended practices including LUN/guest partition block alignment, and don't just use default settings).
Switching an existing deployment from x86 to UltraSPARC is nuts. Also, SPARC is dying, it's extremely unlikely your new cluster will be SPARC.
Almost certainly you will pick x86, x86_64, or Itanium. Itanium is also a niche market, however, and it's unlikely your app will suddenly need it.
Better to in fact virtualize the fileserver. So you can run multiple things on the box.
Virtualization basically guarantees you can move the application with minimal work, when you scale up the storage infrastructure later.
If you ever get a SAN, attach FC, iSCSI LUNs with the files to the fileserver, or serve a VMDK with the data from the NAS, problem solved.
Let the SAN serve data to servers. Let servers serve data to users. Don't let users come within 100 feet of the SAN or other hard-to-upgrade device (security nightmare).
Slashdot Mirror
That's nothing... I typed "The quick brown fox jumps over the lazy dog" into an e-mail message I was sending on my iPhone, and it suddenly morphed into a Zune..
I guess a similar technique works on the ARM processor also :-(
I propose the x86 instruction set be altered to add an additional byte to every instruction, a NUL byte or NUL word, so every instruction will have an additional 2 to 8 bytes of overhead, at least 1 must be set to all bits 0, and the following byte must be set to all bits 1.
Since the NUL byte cannot be expressed in a sentence and commonly causes I/O to terminate (i.e. delineates the end of the string), x86 code can then not be disguised as a sentence.
Also, the following byte being all bits 1, assures that the instruction cannot be transmitted over protocols that do not provide 8-bit support.
Further, the all-bits 1 sequence should be removed from ASCII and banned from use by any network protocol: to transmit such bits, you must encode in Base64.
It is indeed a translator.
It doesn't translate assembler code.. it translates x86 machine code.
(Which also implies that it cannot be an assembler, since assemblers only accept Assembly code as input)
FAIL. It cannot be an assembler if the input is not assembly.
It's a translator.
Multithreaded database applications do not hit a drive with sequential 256K block requests.
They very well may hit the drives with 256K random block requests, especially when committing a large write. To a great extent, this is dependent on the specific OS and the filesystem involved, how much caching is done, including read-ahead caching.
Your average SATA drive can push 60 random IOPs at 256K, not close to 1000.
With ZFS in particular, the DB writes are prone to occur in 128K blocks sequential, and the reads are prone to be random, even for a multi-threaded DB.
While reads are frequently 16 - 64K
And 100 MB/s isn't that impressive, when the transfer technology should be capable of 768 MB/s due to the 6 gigabit SATA interface.
you shouldn't need a second array for HA
Until a power supply on the array blows up, taking both controllers, a critical control board, part of the backplane, or a bunch of the drives with it.
PPS. make that SELECT SUM((xvalue+yvalue)/2) from mytable where id > 10;
Even more important cases for table scans arise with GROUP BY queries, but lest I digress.
You think most databases in the wild are 10TB+ OLTP systems running Oracle?
I think the most common database apps are 5g - 50gb MS SQL Server and MySQL databases, used for a slew of applications.
And table scans are very common, especially when performing certain joins.
In many cases a table scan is much faster than an index scan in real-world databases due to I/O block sizes, and this is a decision that the query planner will make over time, reliant on statistics available to it.
In real-world databases, using indexes would be slower than simply scanning, for many common types of queries, especially when much of the dataset will be selected by the query, or have operations applied to it..
e.g. SELECT SUM(*) from mytable where id > 10;
If 90% of the rows have id>10, there is no point in starting with an index seek.
The X-25M is an 160gb HDD, half the capacity. The IOPs of SSD drives are so large, that in fact, a 30 or 40% IOPs difference is basically irrelevent for DB apps; transfer throughputs for random reads/writes at various block sizes are the most telling factor.
Being able to quote 30000 IOPS is useless, if that number cannot be sustained with at least a 256K blocksize, commonly used for filesystems and database apps. Small random reads/writes are rare in the most demanding real-world apps.
And the Collossus showed to be quite superior to the X-25M in this regard.
We can see quite plainly the OCZ drive outperformed the X-25M on the file copy tests by a massive margin. And in the average write transfer speed compared to the X-25M.
The X-25M plain wasn't good at all with large writes.
The OCZ Colossus' random write capabilities were just plain impressive as shown in YAPT Random writes test. 200 MB/s random writes, for 128Kb blocks/larger, VS 100 MB/s with the Intel X-25M
And even at 64K blocks, it was no worse than the X-25M
No... fricking tell them you had sushi yesterday. Or order a cooked dish from the place that sells sushi 2 of those days.
Your health and sanity trumps your vendor's wishes every time.
That's one picture (I hope) your boss would NOT want to see.
Ah, but this is where you're wrong..
There's this thing called ANSI standard SUSHI (ANSI/NISO Z39.93-2007), also referred to as the sushi standard.
And as demontrated at the above URL, it has absolutely nothing to do with fish, or at least it's not supposed to be. If I ask for SUSHI, and I get some type of fish instead, and they call that sushi, clearly some sort of fraud has occured.....
And perhaps using SUSHI can be hazardous to your health, but only really to the extent that all programming is hazardous to your health.
I was unable to apprehend the article's concept that you would order or ask someone to give you SUSHI and they'd give you a toxic fish instead of the specification.
Nor did I realize it was so easy for people to be confused into thinking that specifications such as Sushi are edible, or that people would actually be so oblivious as to confuse a piece of fish for a copy of a national standard...
For Escolar's effects.
Which are inconvenient but not toxic. The fish hasn't been shown to kill or cause long-term harm. But has unpleasant digestive system side effects in some people. If you experience any of those effects ever, stop eating the fish, but it's your problem not the fish's, and not a problem everyone has :)
I wouldn't suggest eating it, but it sounds as if the effects are short-term, not all people are necessarily effected, and primarily occur if the portion size is too large and not prepared in a way to reduce oils.
More like an unwanted effect than something truly toxic that would be likely to kill you or have a long-term health effect.
So limit the amount of sushi you eat, to a sane amount. No more than a 5 oz piece aday, for sure. Definitely don't eat Sushi multiple times a day, or multiple times in the same week.
In the case of Windows, you can remove the unwanted equipment from your computer and sell it. Your perfectly within your rights (assured by the first-sale doctrine) to do that.
So long as you haven't accepted the agreement, and you still have the license material intact, you still have the legal right to sell it, and nothing legally prevents you.
But once you accept the EULA for Windows.. the EULA for OEM software won't allow you to transfer it to another machine.
It can be used only with hardware it was sold with. At some point, the final recipient who does accept the EULA will have to buy it with some piece of hardware, to be able to use it legally, e.g. you sell with some piece of hardware (such as a disk drive or motherboard).
The logic that you can pick the price of an item out of a package is wrong. Do you think you should be able to buy a bundled package.. a complete computer from a vendor that was sold to you for $X price.. and return the Monitor or Keyboard, in exchange for a percentage of the price equivalent to the FMV of a monitor? (Even though the 'monitor' wasn't an option, and its price is built into the bundle)
The manufacturer doesn't have to allow return of only one piece of a bundled package for its fair value. In fact... the fair market value of each item in the package when all the items are added together, may meet or exceed the price you were charged for the package.
You can no more rent a hotel room, and after you check into your room... demand to return the kitchen (i.e. have them close or lock it up), for a 30% refund (since your hotel rental has 3 rooms in it, kitchen, bathroom, bed). The cost of that item is already incurred by the retailer, and the relationship to the price of the package may be complex. Parts of it may even be free or promotional.
In this case, however, the Windows EULA states that you are entitled to a refund if you refuse to accept. It doesn't provide for a restocking fee.
It would be a violation of the OEM EULA for a manufacturer to charge such a fee.. such a violation might imply that you are no longer bound by the agreement, if your response to not getting a refund is to use Windows, then it would seem that you are taking your self-help remedy in response for the retailer failing to follow the EULA, the EULA no longer properly applies to you, even if you click accept, due to the breach of the agreement by the other party.
Also, attempting to charge a restocking fee for refusing an unanticipated agreement, would probably result in litigation against the retailer, for deceptive/dishonest business practices.
However, the Windows EULA term also doesn't provide for separating Windows from the product. My impression of the term was always... if you don't accept, you can return the entire package that Windows was bundled with, for a refund.
The EULA doesn't guarantee you can return Windows alone, or that you can get a certain price for it.
They are that far apart. SAS = 6 Gigabits/second transfer, SATA = 3 Gigabits/second transfer.
SAS supports multi-initiator, SATA does not.
SAS supports tagged command queuing, SATA supports only the sluggish native command queuing spec.
SAS devices support dual porting and multipath I/O allowing you to place devices in two different SAS domains for double I/O transfer per device and fault resilience, SATA does not have these options.
SAS devices have a unique id, WWN (SCSI ID), that can uniquely identify the device: SATA devices are identified only by port number, and this has scalability consequences.
A SAS channel can service a SAS domain with >16,000 devices using expanders, there is a great deal of expandability there. With SATA, one port = one drive.
SAS error-recovery and reporting is provided by the SCSI command set and is much richer than the SMART command set used by ATA devices.
The drive outperforms the mechanical drive in IOPs and block reads/writes which is what matters.
Databases actually tend to use larger block reads and writes, the drive would be perfect for most databases, that is, database load is just the type of load where this drive is better than other SSDs...
With suitable amount of system memory and host controller with reasonable cache, this drive would be phenomenal in table scan performance.
It's application loads that are heavy in small random reads and writes that the drive isn't that good for compared to some other high-end SSDs.
Still 5000 random IOPs in 1 3.5" package is nothing to sneeze at.
Most hard drives pull off a small fraction of that.
Don't worry.. this is just pre-release... they probably got a 6-controller version with a RAID1+0 version for enhanced read speeds just waiting :)
What about 4gb and 8gb SSDs? There are some you can get for under $200. You can find a 2 or 4gb SSD for under $100, if you look hard enough.
Yes, but if it was a PCI card, we couldn't plug these into external JBOD arrays that combine 24 drives and allows volumes/LUNs to be carved out and served up to various servers... Actually, it'd be nice if they made it SAS instead of SATA.
WTH is with high-end hardware using the low-performance ATA standard instead of SCSI nowadays, anyways?
Running under VMware means there is less code running that is subject to attack (smaller attack surface), because there are fewer apps per guest, and the risk of a bug in VMware itself is approximately equal to the risk of a bug in your CPU microcode, due to the application of VT.
A perfect example of why computers should not allow humans to specify the password. Instead it should be randomly generated at time of manufacture, and the only password change operation allowed should be "generate a new random password"
That's where Windows 2008 MSCS, HAProxy, or Redhat cluster suite comes in.
For example, if you want a highly-available web service, you would have two VMware servers that you run a Webserver VM for on each server.
Then you would have a diskless load-balancer running HAProxy, to feet incoming web requests to a working web server.
For database services... you'd have a MySQL or MSSQL VM on each host, and a SAN or shared storage block filesystem with a GFS formatted LUN, and a Quorum disk (Linux) or Witness File share on a third physical host (for Windows 2008 MSCS), with clustering services configured so the SQL process is only active on the one host at a time, and only when quorum is met; if failure of another node is detected, a remaining node that can meet quorum will fence (KILL) the other VM, and then take over.
So in this manner, you can meet HA in a virtualized environment.
Although there are some considerations, like guest system clock accuracy, reliability of network connections to ensure an erroneous failure isn't detected during times of high load, and supported configurations for OS vendors' clustering capabilities
It creates a configuration nightmare. Apps with conflicting configurations.
Changes required for one app may break other apps.
Also, many OSes don't scale well.
In a majority of cases you actually get greater total aggregate performance out of the hardware by divvying it up into multiple servers. When your apps are not actually CPU-bound or I/O bound.
Linux is like this. For example, in running Apache.. after a certain number of requests, the OS uses the hardware inefficiently, and can't answer nearly as many requests as it should be able to. By dividing it into 4 virtual servers instead, for your 4 CPUs, you can multiply the number of requests that can be handled by 10 or 20 fold.
You may even think your CPU bound on Linux when you are not: load average may be high due to number of Apache processes that are contending with each other, and can create a false impression of high CPU or IO usage, when in fact, you have a bottleneck in the app/kernel's parallel processing capabilities.
Exchange is also like this.. better to scale out 2 virtual machines with 32gb a RAM and 4x3ghz CPUs dedicated to it each, than one server with 64gb RAM and 8x3ghz CPUs. The former is a beefy server but doesn't have much advantage from adding the extra resources. The two servers virtualized on one box may have much better performance than 1 physical server, if you are using Intel Nehalem CPUs and properly configure your VMs (i.e. you actually do it right, and perform all recommended practices including LUN/guest partition block alignment, and don't just use default settings).
Switching an existing deployment from x86 to UltraSPARC is nuts. Also, SPARC is dying, it's extremely unlikely your new cluster will be SPARC. Almost certainly you will pick x86, x86_64, or Itanium. Itanium is also a niche market, however, and it's unlikely your app will suddenly need it.
Better to in fact virtualize the fileserver. So you can run multiple things on the box. Virtualization basically guarantees you can move the application with minimal work, when you scale up the storage infrastructure later.
If you ever get a SAN, attach FC, iSCSI LUNs with the files to the fileserver, or serve a VMDK with the data from the NAS, problem solved. Let the SAN serve data to servers. Let servers serve data to users. Don't let users come within 100 feet of the SAN or other hard-to-upgrade device (security nightmare).