Jeremy Teo wrote:
Would it be worthwhile to implement heuristics to auto-tune
'recordsize', or would that not be worth the effort?
Here is one relatively straightforward way you could implement this.
You can't (currently) change the recordsize once there are multiple
blocks in the file. This shouldn't be too bad because by the time
they've written 128k, you should have enough info to make the choice.
In fact, that might make a decent algorithm:
* Record the first write size (in the ZPL's znode)
* If subsequent writes differ from that size, reset write size to zero
* When a write comes in past 128k, see if the write size is still
nonzero; if so, then read in the 128k, decrease the blocksize to the
write size, fill in the 128k again, and finally do the new write.
Obviously you will have to test this algorithm and make sure that it
actually detects the recordsize on various databases. They may like to
initialize their files with large writes, which would break this. If
you have to change the recordsize once the file is big, you will have to
rewrite everything[*], which would be time consuming.
--matt
[*] Or if you're willing to hack up the DMU and SPA, you'll "just" have
to re-read everything to compute the new checksums and re-write all the
indirect blocks.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
