On Wed, Jul 31 2013 at 2:38pm -0400, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > On 7/31/13 12:08 PM, Chris Murphy 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 > > > > 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. > > Quite some time ago I had asked whether we could get the allocation-tracking > snapshot niceties from dm-thinp, without actually needing it to be thin. > > i.e. if you only want the efficient snapshots, a way to fully-provision > a "thinp" device. I'm still not sure if this is possible...? TBD, we could add a "sandeen_makes_thinp_his_bitch" param and if specified (likely for entire pool, but we'll see) it would mean thin volumes allocating from the pool would have their logical address space reserved to be completey contiguous on creation (with all thin blocks flagged in metadata as RESERVED). The actual thin block allocation (zeroing of blocks on first write if configured, etc.) transitions the metadata's block from RESERVED to PROVISIONED. Not yet clear to me that the DM thinp code can be easily adapted to make the thin block allocation 2 staged. But would seem to be a prereq for dm-thinp's REQ_RESERVE support. I'll check with Joe (cc'd) and come back with his dose of reality ;) > I guess I'm pretty nervous about offering actual thin provisioned > storage to "average" Fedora users. I'm having nightmares about the "bug" > reports already, just based on the likelihood of most users misunderstanding > the feature and it's requirements & expected behavior... Heh, you shouldn't be nervous. You can just punt said bugs over the fence right? ;) Mike -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
