- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Cluster size of large disks
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-17-2005 07:16 PM
тАО08-17-2005 07:16 PM
Re: Cluster size of large disks
Antonio Vigliotti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-17-2005 09:54 PM
тАО08-17-2005 09:54 PM
Re: Cluster size of large disks
7.3-2, I see that I can set the cluster size to what ever I want and then do a
BACKUP/IMAGE/NOINIT to preserve the cluster size. So I definately have to upgrade.
I seem to have you all intrigued as to why the cluster size is important. I'll try to find out why and let you know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-17-2005 10:44 PM
тАО08-17-2005 10:44 PM
Re: Cluster size of large disks
As everybody else has noted, the cluster size is, when all is said and done, likely irrelevant.
As to the genesis of the myth, I would speculate two things:
- the selection of the cluster size at some point may be linked with ancient disk geometry. At some point in the past, someone may have decided that it seemed a good idea to ensure that clusters aligned on disk boundaries (track, cylinder). Today, most people ignore that fact. This was not so in the past. Many other operating systems (e.g., IBM's OS/360 and CDC NOS) did in fact encourage this type of thinking. Provided it did not cause excessive "breakage", it isn't a bad idea. Breakage can be impressive, I have seen 20-30% values at times, a strong argument AGAINST large cluster sizes.
- somewhere along the line, someone made the presumption that cluster sizes related to RMS bucket sizes.
In short, before migrating disks or similar action, track down the source of this myth, and set it right.
If the applications firm does not give a solid explanation, consider calling in an HP or solid third party consultant to take a look at the question. It is not uncommon to find such a thing is an artifact of the testing configuration. A small review and some conference calls can literally save tens of thousands of dollars of budget spent on unneeded system management exercises (Yes, to be honest, I have resolved several of these types of situations in the past, but I digress).
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-17-2005 10:46 PM
тАО08-17-2005 10:46 PM
Re: Cluster size of large disks
As to a short term solution, I would recommend a good look at the use of LD.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-17-2005 11:51 PM
тАО08-17-2005 11:51 PM
Re: Cluster size of large disks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-18-2005 01:13 AM
тАО08-18-2005 01:13 AM
Re: Cluster size of large disks
I'm happy you upgrade you os version. I'm also intrigued by this choice; usually system administrators don't love upgrade theyr machine to avoid compatibility trouble. So the reason of keep cluster size to 51 is very very strong!
If you need help for upgrade, post: we are here!
Antonio Vigliotti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-18-2005 07:45 PM
тАО08-18-2005 07:45 PM
Re: Cluster size of large disks
>application that uses RMS and I've
>been told that the cluster size must
>be 51 or lower.
There can be good reasons!
What is meant by "RMS" in this case? It may mean "Record Management System" - the VMS meaning - but who knows it has something to do with memory: "Reusable Memory Storage", perhaps? Just a guess. In that case, it can very well be feasable to limit the clustersize on disk, where is is possible to read whole clusters of data directly into memory - bypassing VMS's RMS. Maximum clustersize of 51 means a 25,5K buffer.
Just a question on this: does the application require LOGIO of PHYIO privilege? That would be a signal of this behaviour.
Why you should need to, and not use VMS's own facilities is another matter. Maybe the program ws originally written for Unix?
Anyway: you will need to upgrade. Given the nature of the program, I would test it with a higher version of VMS. It is very well possible that it won't work when it is linked against the system!
Willem
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-19-2005 12:35 AM
тАО08-19-2005 12:35 AM
Re: Cluster size of large disks
A somewhat more likely answer is that the application was written in a way that attempted to do, or thought that it was doing, some sort of optimised IO but perhaps had only limited internal storage. If the application is old, a clustersize of 51 might have seemed future-proof at the time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-22-2005 05:28 AM
тАО08-22-2005 05:28 AM
Re: Cluster size of large disks
I'm confused -- comments about the irrelevance of cluster size compared to sector size -- if you choose a cluster size that is not an integer multiple of the sector size, what happens to the pieces that are left over?
My impression from past descriptions of how the drive gets broken up into useable hunks of media leaves me with the impression that randomly picking a cluster size leads to wasted space or inneficient use.
Robert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-22-2005 05:51 AM
тАО08-22-2005 05:51 AM
Re: Cluster size of large disks
Cluster size is independent of the numbers of sectors on a track. Clusters follow one another, if a cluster does not fit on the track, it continues into the next track (or cylinder, if the this occurs on the last track in the cylinder).
At first glance, this may seem inefficient, but the reality is that the benefit of multiblock allocations outweighs the negative effects of the occasional cluster that spans a physical boundary.
In many cases, at least in the past, the number of blocks was a composite number (product of two or more numbers), thus it was possible, without wastage, to keep a cluster completely on a track. I have seen more than a few cases where the numbers of sectors per track are constant and a prime number (e.g., a number divisible only by one and itself). In that case, the only cluster factors that would not yield track crossing would be 1 (which would be inefficient to allocate space, creating a high degree of fragmentation) or a cluster size equal to the track size (which would yield a tremendous loss of space due to "breakage", the unused, and unallocatable space at the end of the file).
The main performamnce loss is not from spanning tracks or cylinders (of which only cylinders is truly significant), but the overheads from highly fragmented allocations and multiple file headers.
Of course, all of these effects are harder to observe when there are caches at different levels in the hierarchy obscuring what one is trying to measure.
- Bob Gezelter, http://www.rlgsc.com