|
Re: File Device Class and File System Fragmentation with JFS2
2005-12-09 10:02:27
Hi Allen and Andy,
>>> Here is my thinking. From what
I gather about scratch volumes, they are
>>> opened, filled with what data they are recieving, and closed
- but not
>>> allocated full size.
Yep, that's correct with FILE vols -
I'm watching it happen right now here on one of my servers.
Perhaps there might be another variable
here in the fragmentation discussion which depends upon how you plan to
use you FILE storage pool - long-term/indefinite storage or simply transitory
use before migrating off to tape where the scratch vols will be automatically
deleted and the filesystem emptied daily or more frequently.
Rgds,
David McClelland
Storage and Systems Management Specialist
IBM Tivoli Certified Deployment Professional (ITSM 5.2)
SSO UK Service Delivery – Storage Services
IBM Global Services – IBM United Kingdom
|  |
Andrew Carlson <andyc AT ANDYC.CARENET DOT ORG>
Sent by: "ADSM: Dist Stor Manager"
<ADSM-L AT VM.MARIST DOT EDU>
09/12/2005 14:06
|
Please respond to
"ADSM: Dist Stor Manager" |
|
|
To
| ADSM-L AT VM.MARIST DOT EDU
|
|
cc
|
|
|
Subject
| Re: [ADSM-L] File Device
Class and File System Fragmentation with JFS2 |
|
Allen S. Rout wrote:
>I would think that the importance of contiguous placement would be
very
>strongly correlated with the disk tech. If I go to FILE devclasses
on my SSA,
>I would think preallocating would be indicated. If I were deplying
on
>something more abstracted (shark, netapp, etc) I would hope that the
>inefficient placement would be swamped by the cache.
>
>Would your predefined vols be smaller or larger than your scratch vols?
I'm
>very interested in your thinking here.
>
>
>
Here is my thinking. From what I gather about scratch volumes, they
are
opened, filled with what data they are recieving, and closed - but not
allocated full size. So, if I predefine, I might want to make my
volumes smaller, since there is more potential wasted space.
|
|
|
