I suspect this is the system drive, where the OS will be installed. They are way faster than the Samsung, and can be configured for smaller block sizes.
Since it is Windows, you want to keep the OS on separate space since you know it is going to need reloading fairly often as viruses strike and new versions filter out.
The other RAID1 is probably working disk space, and will probably have some rather large blocking factors.
The RAID5 is probably planned for longer term bulk storage since it can be a tad slower than Raid1.
Windows Server 2008 Standard was installed, so the Four quad-core Opteron processors (appearing as 16 processors) will yield about the same performance as four single core processors.
Windows simply can't make effective use of that many processors. Oh, it will keep them busy, mostly chatting among themselves.
Anything over 4 on a windows platform is mostly a waste unless you go to the trouble of setting affinity of specific cores to specific virtual machines. (Which windows does not make trivial).
It is not unusual for treaty negotiations to be secret. This is more common than you seem to think.
These are working sessions, and getting a zillion people ranting and raving about a casual word or phrase here or there is counter productive.
When submitted to The Senate for approval there will be no secret codicils attached and the written word will be available to all. Write you Senator and get on the list to be notified when the issue comes before them.
Poor choice of denial reasons? Perhaps. But don't go all conspiracy nut on the issue till you see the work product.
The writers of the Constitution worked mostly in secret too.
On way to test if your argument makes sense is to extend it to absurdity.
What if the FS NEVER wrote anything until a fsync was called? All applications would then have to add these calls.
The net affect would be uncontrolled write management at the application level with no hope of IO management or optimization at the FS/OS level.
Is this what you propose? Is this technically correct? Be careful what you wish for.
If this was done, the FS would (sooner or later) have to ignore fsync totally and re-assert control of commits in order to achieve any reasonable performance.
So you see, I believe you are recommending something that is not in the best interests of the OS or the users in the long run. (However technically correct it might be at the moment). This functionality really does belong at the OS/FS level. I could go further and say it would be nice if it could be done at the hardware level. If disk drives could manage this by themselves it would be great. A write would get immediately sent to the disk, and it would cache as needed but never more than it could write with stored power after feed power fails.
And I'm running ReiserFS 3 for a while longer. I live in an area with crappy power and I've had many power failures on machines with and without UPSs, and I've never lost any data.
>The only reason this has become a big blow-up issue with ext4 is that while other filesystems >generally would sync the data shortly anyways, ext4 does not. Everyone has been relying on bad >assumptions about filesystem behavior and getting by on the fact that "usually" the situation was >resolved "somewhat quickly".
If everyone has been relying on the FS to work a certain way, why should you be surprised when everyone objects when it no longer functions that way?
Further, why should you defend the introduction of that much more risk (3000%) into a system that has always trumpeted reliability over speed?
The speed gained will be minimal. Saving 5 seconds of writes up is dramatically better than saving 150 seconds up.
Absolutely no gain will be achieved by this change. All the speed gains claimed for EXT4 were based on systems designed for EXT3, and as soon as every programmer runs out and puts in sync calls everywhere any speed gains in EXT4 will disappear.
Further, disk activity will increase, as sync requests come wili-nili from every application running on the box.
It is utterly stupid to foist what everyone expects be a low level function of a FS onto end-user software. (I've tried to avoid inflammatory words, and Stupid is the nicest I could come up with.)
Its a file system risk issue, and it affects everything running on the bos.
The EXT4 developers have decided its ok to increase the risk window by 3000% and risk a crash for a minute and 20 seconds in an attempt to gain a little performance. (Damn little performance).
With EXT3 the risk window was 5 seconds. Now its 150 seconds.
Its ridiculous to move what should be a low-level data integrity function out of the File System and inflict it on user-land code.
Its worse than than a KDE problem. It goes to the heart of Linux/Unix which have always been dependent on a multitude of small text files.
Anytime you suggest users re-write their entire code base to get around a bug you've created your professional pride should well up, grab you by the wattles and slap you till you spit.
With my slashdot ID half of yours I'd be careful about calling anyone "son".
Being a server is even MORE reason this is an inappropriate use of SSDs. Servrs should be adequately sized and powered such that they can cache their workload and never have to reboot.
The reason they are on the motherboard is because they have exceeded peripheral bus speed. Of course, so have many hard drives.
Keeping them as hard drive replacements will force new bus technology, which in the long run will be more useful than SSD on the mobo, which will be obsolete the moment it reaches the end of the assembly line.
So the old new thing resurfaces.... Persistent ram drives have arrived. Should we be dredging up our old DOS disks again?
Why put this on the MoBo? Why BUY this on the MoBo?
Have we not been thru enough new-product cycles to learn NEVER NEVER NEVER buy an integrated version of new technology?
How many modems lurking on motherboards were abandoned in the race from 300 baud to 56k? How many on-board video chip-sets are doing nothing at all, having been replaced by generation after generation of add-on video?
In 8 years, this might make sense. After the industry has stabilized with regard to technology, and size, and price of SSD. (but I doubt it). It certainly makes no sense today.
PDF now supports buttons, Javascript and a whole slew of other features that for the most part are not typically used. In fact, anyone who wants to use those features probably shouldn't be using PDF at all since only the Adobe reader supports them!
Quite true. Most use of Acrobat is in pursuit of a document that could reliably be expected to display and print the same on my machine as on yours. Adding these features detracts from its primary purpose.
I understand the desire for One Reader to Rule them ALL, but various call-home features and interactive content manipulation still was a wrong approach for a package with the original goal of faithful unalterable reproduction.
Fill in forms are supported by many reader compatible clones. Even this feature is suspect. How can one be sure when filling in an IRS fill-in form that acrobat is not transmitting tax data to some third party.
If you break your contract, you are sued for THAT, not violation of some law.
Theft is a criminal law. It should be pursued in criminal court. If you can't prove theft without breaking and entering, why should the courts treat you any better than the thief?
Slashdot Mirror
I suspect this is the system drive, where the OS will be installed. They are way faster than the Samsung, and can be configured for smaller block sizes.
Since it is Windows, you want to keep the OS on separate space since you know it is going to need reloading fairly often as viruses strike and new versions filter out.
The other RAID1 is probably working disk space, and will probably have some rather large blocking factors.
The RAID5 is probably planned for longer term bulk storage since it can be a tad slower than Raid1.
We be guessing...
Windows Server 2008 Standard was installed, so the Four quad-core Opteron processors (appearing as 16 processors) will yield about the same performance as four single core processors.
Windows simply can't make effective use of that many processors. Oh, it will keep them busy, mostly chatting among themselves.
Anything over 4 on a windows platform is mostly a waste unless you go to the trouble of setting affinity of specific cores to specific virtual machines. (Which windows does not make trivial).
Mod parent insightful.
The whole thread has taken on the tenor of a convention of conspiracy nutters by this one gratuitous innuendo.
It is the norm for treaty negotiations to be held in private.
It is not unusual for treaty negotiations to be secret. This is more common than you seem to think.
These are working sessions, and getting a zillion people ranting and raving about a casual word or phrase here or there is counter productive.
When submitted to The Senate for approval there will be no secret codicils attached and the written word will be available to all. Write you Senator and get on the list to be notified when the issue comes before them.
Poor choice of denial reasons? Perhaps. But don't go all conspiracy nut on the issue till you see the work product.
The writers of the Constitution worked mostly in secret too.
A certain man sitting in the white house may have a different view, especially in conjunction with the Civil Rights acts passed in the 60s.
Who modded parent insightful?
Numbers indicate nothing more than sequential release numbers.
You must be really distressed at Microsoft's race from Windows 3.1 to Windows 95, to Windows 2000, only to plummet back down to Windows 7.
Wait, maybe there is some significance to these numbers after all.
> (Besides which, the FAT patent has been thrown out in Germany.)
Citation needed.
Besides, Tom Tom is Dutch, not Deutsch.
>I don't see why those folks would want to sue TomTom.
How is this germane?
Microsoft has already sued TomTom.
You seem to be arguing from a premise you have yet to state.
This is especially ironic when their
stated purpose on their masthead is to rid the internet of ads.
I'm not so sure that is totally a good idea.
On way to test if your argument makes sense is to extend it to absurdity.
What if the FS NEVER wrote anything until a fsync was called?
All applications would then have to add these calls.
The net affect would be uncontrolled write management at the application level with no hope of IO management or optimization at the FS/OS level.
Is this what you propose? Is this technically correct? Be careful what you wish for.
If this was done, the FS would (sooner or later) have to ignore fsync totally and re-assert control of commits in order to achieve any reasonable performance.
So you see, I believe you are recommending something that is not in the best interests of the OS or the users in the long run. (However technically correct it might be at the moment). This functionality really does belong at the OS/FS level. I could go further and say it would be nice if it could be done at the hardware level. If disk drives could manage this by themselves it would be great. A write would get immediately sent to the disk, and it would cache as needed but never more than it could write with stored power after feed power fails.
All True.
And I'm running ReiserFS 3 for a while longer. I live in an area with crappy power and
I've had many power failures on machines with and without UPSs, and I've never lost any
data.
More than I care to pull thru 12-2 with ground.
The largest single circuit in most US homes seldom exceeds 9600
watts for an electric range.
25,000 watts is typical for the entrance rating of many modern US homes.
Go stick you hand across the legs of your main breaker and come
back and tell me if you still think its not a "large amount of power".
(Note: don't do this. Really.)
Sure, as long as you can find a 25000 watt outlet.
> deliver 25,000 watts, or enough power for about 20 vacuum cleaners."
What could possibly go wrong with that!!??
>The only reason this has become a big blow-up issue with ext4 is that while other filesystems
>generally would sync the data shortly anyways, ext4 does not. Everyone has been relying on bad
>assumptions about filesystem behavior and getting by on the fact that "usually" the situation was
>resolved "somewhat quickly".
If everyone has been relying on the FS to work a certain way, why should you be surprised when everyone objects when it no longer functions that way?
Further, why should you defend the introduction of that much more risk (3000%) into a system that has always trumpeted reliability over speed?
The speed gained will be minimal. Saving 5 seconds of writes up is dramatically better than saving 150 seconds up.
Absolutely no gain will be achieved by this change. All the speed gains claimed for EXT4 were based on systems designed for EXT3, and as soon as every programmer runs out and puts in sync calls everywhere any speed gains in EXT4 will disappear.
Further, disk activity will increase, as sync requests come wili-nili from every application running on the box.
It is utterly stupid to foist what everyone expects be a low level function of a FS onto end-user software. (I've tried to avoid inflammatory words, and Stupid is the nicest I could come up with.)
Its not a KDE issue. Its not a Gnome issue.
Its a file system risk issue, and it affects everything running on the bos.
The EXT4 developers have decided its ok to increase the risk window by 3000% and
risk a crash for a minute and 20 seconds in an attempt to gain a little
performance. (Damn little performance).
With EXT3 the risk window was 5 seconds. Now its 150 seconds.
Its ridiculous to move what should be a low-level data integrity function
out of the File System and inflict it on user-land code.
Its worse than than a KDE problem. It goes to the heart of Linux/Unix which
have always been dependent on a multitude of small text files.
Anytime you suggest users re-write their entire code base to get around
a bug you've created your professional pride should well up, grab you by
the wattles and slap you till you spit.
> I don't think they make 2-million-terabyte DDR3 sticks, yet...
But you know of someone using that much swap?
That makes sense, except the swap part.
Throw and equivalent amount of money at REAL RAM, such that your machine never swaps and everything will run much better.
With my slashdot ID half of yours I'd be careful about calling anyone "son".
Being a server is even MORE reason this is an inappropriate use of SSDs.
Servrs should be adequately sized and powered such that they can cache their
workload and never have to reboot.
I'm not so impressed.
The reason they are on the motherboard is because they have exceeded peripheral bus speed. Of course, so have many hard drives.
Keeping them as hard drive replacements will force new bus technology, which in the long run will be more useful than SSD on the mobo, which will be obsolete the moment it reaches the end of the assembly line.
So the old new thing resurfaces....
Persistent ram drives have arrived. Should we be dredging up our old DOS disks again?
Why put this on the MoBo?
Why BUY this on the MoBo?
Have we not been thru enough new-product cycles to learn NEVER NEVER NEVER buy an integrated version of new technology?
How many modems lurking on motherboards were abandoned in the race from 300 baud to 56k? How many on-board video chip-sets are doing nothing at all, having been replaced by generation after generation of add-on video?
In 8 years, this might make sense. After the industry has stabilized with regard to technology, and size, and price of SSD. (but I doubt it). It certainly makes no sense today.
PDF now supports buttons, Javascript and a whole slew of other features that for the most part are not typically used. In fact, anyone who wants to use those features probably shouldn't be using PDF at all since only the Adobe reader supports them!
Quite true.
Most use of Acrobat is in pursuit of a document that could reliably be expected to display and print the same on my machine as on yours. Adding these features detracts from its primary purpose.
I understand the desire for One Reader to Rule them ALL, but various call-home features and interactive content manipulation still was a wrong approach for a package with the original goal of faithful unalterable reproduction.
Fill in forms are supported by many reader compatible clones. Even this feature is suspect. How can one be sure when filling in an IRS fill-in form that acrobat is not transmitting tax data to some third party.
Next time try to post a coherent argument.
If you break your contract, you are sued for THAT, not violation of some law.
Theft is a criminal law. It should be pursued in criminal court. If you can't prove theft without breaking and entering, why should the courts treat you any better than the thief?
PGP keys only help with email.
Far better to move the entire web to ONLY ssl based servers, (after fixing ssl of course).