Linked by Will Senn on Tue 26th Apr 2005 20:14 UTC
Wow! With Solaris 10, Sun Microsystems has done a marvelous job of bringing Solaris fully into the x86 world. Gone are the days when Solaris only runs on Sun hardware or when it only runs well on Sun hardware. Solaris 10 comes with greatly expanded off-the-shelf x86 hardware compatibility and a license that is hard to beat. It's a binary right to use and Open Solaris, the open source version is soon to come. IT Managers that have been wanting to bring a stable, scalable Operating Environment into their network infrastructures, but who have been unwilling to commit to the Sun hardware platform, for various reasons, are now free, pun intended, to bring Solaris on board and to run it on the hardware of their choice. 
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Here's a question maybe you can answer for me. What is the recommended maxphys for an IDE system? I have asked this question before and got no response. According to this document, the default maxphys for x86 is 57,344:
You're correct that the default is 56k on x86 and 128k on SPARC. My suspicion is that it's set lower on x86 because of the limited amount of kernel VA that is available on x86 using a 32-bit kernel. This wouldn't be an issue on a amd64 64-bit kernel. I would also guess that if your machine has a lot of memory it would be fine to tweak the default, but I would test under a high I/O load to make sure you don't suddenly run out of memory batching up larger transactions.
After some looking, it appears that there's no official Sun position on tuning maxphys for IDE drives. For SCSI disks, the documents I've come across suggest 1mb, and no larger than 2mb. For vxvm or other redundant filesystems, it is reccomended that you try to optimize maxphys for the stripe-size of the underlying disk subsystem.
Another document mentioned that this is the size at which things will be split up; however, the device driver is free to break the data up into smaller chunks anyway. So, it's entirely possible that tuning this may have little effect on an IDE drive, which has to process each request in order. (Read: all decomposed into 512-byte chunks at the end of the day) The story may be different for a SATA drive, which does tagged queuing, but my suspicion is that you may have to benchmark the modification to see if it has actually given you any benefit.
There's also a caveat regarding soft partitions (on IDE disks) and Solaris 7 crashdumps, both of which are reported to be unhappy with maxphys being tuned.
This is one reason I despise tuneables, because instead of the OS figuring out how much memory you have and what the I/O transfer characteristics of the attached devices are, it makes you do some amount of estimating and testing and figure it out yourself. *grumble*
Keeping in mind that you are not supposed to modify any parameter other than the blocking factor in ata.conf, will setting the maxphys to something other than 57,344 actually help? Considering the vast majority of people installing Solaris are going to be doing it on IDE systems, this could potentially help them with poor performance
Having never attempted this myself, I'm not sure. I'll see if I can find a more conclusive answer, but constructing a sensible test case and benchmarking may be a more reliable indication of whether it helps or not.