> -----Original Message----- > From: Lucius, Leland [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 18, 2004 12:55 PM > To: [EMAIL PROTECTED] > Subject: Re: dasdfmt with a 1K block size - still not recommend? > > > > > > As long as you have to use a 3390 track image with > > ECKD mapping, the smaller tracksize will cost you > > capacity on the image. Probably only the RVA will see > > equivalent savings on the backend. Other devices do a > > one to one mapping of the full ECKD image. > > > So, why not format the tracks with 1 full track block (rounded to next > lower 512-byte boundary) and have the driver logically divide > the track > up into whatever 512-byte multiple blocks the user wants? > > (I'm probably being stoopid here...) > > Leland >
The main reason that I can think of is that the I/O must be a complete block. By making the physical block == maximum block on the track (or nearest multiple of the "logical block"), you must read and write the entire track in order to get / update any "logical block" contained within that track. This could possibly cause excessive I/O traffic to the disk. For sequential type I/O, this would be excellent. For a data base with random I/O, however, it could be very bad. -- John McKown Senior Systems Programmer UICI Insurance Center Applications & Solutions Team This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited.
