On Wed, Jul 31 2013 at 2:38pm -0400, Eric Sandeen sandeen@redhat.com wrote:
On 7/31/13 12:08 PM, Chris Murphy wrote:
On Jul 31, 2013, at 8:32 AM, Mike Snitzer snitzer@redhat.com 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