Alan, you are correct, after running mkfs there's always filesystem metadata overhead. My statement about eckd dasdfmt loss and no loss for scsi fba refers to their capacity before running mkfs.
-------------------------------------------------------- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -----Original Message----- From: Linux on 390 Port on behalf of Alan Altmark Sent: Thu 7/3/2008 6:40 PM To: [email protected] Subject: Re: Linux DASD Questions On Thursday, 07/03/2008 at 11:58 EDT, "Romanowski, John (OFT)" <[EMAIL PROTECTED]> wrote: > "How much capacity do you lose when defining Linux DASD volumes(ECKD) as > minidisk under zVM?" > I remember the 4K formatting of ECKD dasd lost roughly 18% of capacity. > > "How much capacity do you lose when defining Linux DASD volumes > (SCSI-ZFCP) at FBA 4k blocksizes?" > No loss using scsi FBA. 4K block uses 512-byte FBA blocks in groups of 8 Not true. There is always loss, as some of those 4K blocks contain filesystem metadata, not user data. The more files you have, the more metadata (directory entries). And, of course, the larger the file, the more metatdata is required to track those blocks. The good news is that there is no unusable space. On ECKD volumes, there is *additional* filesystem loss because you can only fit 12 4K blocks on a track. 15 tracks per cylinder means 180 blocks per cylinder. The tracks are more than 48K bytes in length, but not long enough to hold 13 blocks, so the leftover space is unusable. It is possible to design a filesystem that uses all the space, but that means that you will have to do all sorts of fancy calculations to decide where a block is located and it means that you're not getting benefits of the track cache. The CPU overhead, the cache pollution, and the risk of two rotations of the disk to read a single block lead one to conclude that it isn't worth it. Disks are cheap. They'll make more. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
