On Wed, Jul 31 2013 at 1:08pm -0400, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Jul 31, 2013, at 8:32 AM, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > But on the desktop the fedora > > developers need to provide sane policy/defaults. > > Right. And the concern I have (other than a blatant bug), is the F20 > feature for the installer to create thinp LVs; and to do that the > installer needs to know what sane default parameters are. I think > perhaps determining those defaults is non-obvious because of my > experience in this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=984236 Hmm, certainly a strange one. But some bugs can be. Did you ever look to see if CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is enabled? Wouldn't explain any dmeventd memleak issues but could help explain slowness associated with mkfs.btrfs ontop of thinp. Anyway, to be continued in the BZ... > If I'm going to use thinP mostly for snapshots, then that suggests a > smaller chunk size at thin pool creation time; whereas if I have no > need for snapshots but a greater need for provisioning then a larger > chunk size is better. And asking usage context in the installer, I > think is a problem. It is certainly less than ideal but we haven't come up with an alternative yet. As Zdenek mentioned in comment#13 of the BZ you referenced, we're looking to do is establish default profiles for at least these 2 use-cases you mentioned. lvm2 has recently grown profile support. We just need to come to terms with what constitutes sufficiently small and sufficently large thinp block sizes. We're doing work to zero in on the best defaults... so ultimately this is still up in the air. But my current thinking for these 2 profiles is: * for performance, use data device's optimal_io_size if > 64K. - this will yield a thinp block_size that is a full stripe on RAID[56] * for snapshots, use data device's minimum_io_size if > 64K. If/when we have the kernel REQ_RESERVE support to prealloc space in the thin-pool it _could_ be that we make the snapshots profile the default; and anything that wanted more performance could use fallocate(). But it is a slippery slope because many apps could overcompensate to always use fallocate()... we really don't want that. So some form of quota might need to be enforced on a cgroup level (once cgroup's reservation quota is exceeded fallocate()'s REQ_RESERVE bio pass down will be skipped). Grafting in cgroup-based policy into DM is a whole other can of worms, but doable. Open to other ideas... Mike -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct