No, SFS will not do concurrent I/O to minidisks located on a single volume.
SFS knows on which volules its minidisks are located and acts accordingly.
If I remember well, I displayed some minidisk usage in my first append for
this subject, where one can see that SFS leaves mindisks unused. Have a
Steve,
I know an SFS server won't do multiple I/O's to the same minidisk. My
question is whether it will do concurrent I/O's to different minidisks
on the same volume. If it will, there might be some benefit to putting
two or three minidisks on one volume and using PAV. If not, I'll just
put one
PAVs will not benefit SFS. An SFS server (1 entity) can't be setup to do
multiple I/Os to the same minidisk. Therefore, the VM I/O dispatcher
doesn't have anything (ie. multiple I/Os) to spread out over the real
system attached Aliases.
Regards, Steve.
Steve Wilkins
IBM z/VM Development
You really do not want three minidisks belonging to the same SFS on the
same DASD. SFS processing will process them singularly. i.e. it will
do writes to them filling the first, then the second, then the third.
SFS will not spread the I/O among multiple minidisks on the same DASD
volume unless SF
On Wednesday, 06/20/2007 at 06:15 AST, David Boyes <[EMAIL PROTECTED]>
wrote:
> You don't have to. It's just more useful if you do.
>
> You have to modify CHKIPADR if you want the server to present the user's
home
> filespace by default on succesful authentication.
If you don't specify a defau
The HTML document describing my RxServer package (that includes an improved
VMUTIL server) explains how WAKEUP works with its WAKEUP file. We also
explain problems of scheduled events that can be missed when a running task
brings VMUTIL into the next day.
open the RxSERVER HTM file and search f
