> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Erik Trimble > > (1) Unless you are using Zvols for "raw" disk partitions (for use with > something like a database), the recordsize value is a MAXIMUM value, NOT > an absolute value. Thus, if you have a ZFS filesystem with a record size of > 128k, it will break up I/O into 128k chunks for writing, but it will also write > smaller chunks. I forget what the minimum size is (512b or 1k, IIRC), but what > ZFS does is use a Variable block size, up to the > maximum size specified in the "recordsize" property. So, if > recordsize=128k and you have a 190k write I/O op, it will write a 128k chunk, > and a 64k chunk (64 being the smallest multiple of 2 greater than the > remaining 62 bits of info). It WON'T write two 128k chunks.
So ... Suppose there is a raidz2 with 8+2 disks. You write a 128K chunk, which gets divided up into 8 parts, and each disk writes a 16K block, right? It seems to me, limiting the max size of data that a disk can write will ultimately result in more random scattering of information about in the drives, and degrade performance. We previously calculated (in some other thread) that in order for a drive to be "efficient" which we defined as 99% useful and 1% wasted time seeking, then each disk would need to be read/writing 40M blocks consistently. (Of course, depending on the specs of the drive, but typical consumer & enterprise disks were consistently around 40M.) So wouldn't it be useful to set the recordsize to something huge? Then if you've got a large chunk of data to be written, it's actually *permitted* to be written as a large chunk instead of forcibly breaking it up? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
