* explicitly specifying pgnum on pool creation
@ 2012-11-04 11:42 Sage Weil
2012-11-05 18:55 ` Josh Durgin
0 siblings, 1 reply; 3+ messages in thread
From: Sage Weil @ 2012-11-04 11:42 UTC (permalink / raw)
To: ceph-devel
The wip-explicit-pgnum changes the 'ceph osd pool create <name> <pgnum>'
command to require the pg_num value instead of defaulting to 8. This
would make it harder for users to get this wrong.
On the other hand, it probably also breaks some scripts for deploying
OpenStack that create volume and image pools. :/
Ideas?
The original idea was that the monitor would automagically notice when a
small pgnum pool gets lots of objects and trigger a split. Even if we
don't do that, pretty soon now you'll be able to explicitly increase
pg_num. I still think it might be a good idea to require it up-front,
though.
An alternative would be to default to a larger number (say, num_osds <<
2). My concern there is that it makes it easy to create lots of pgs for
pools that may be small, and it's still not large enough to get good
performance for the "create pool, run rados bench" crowd.
sage
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: explicitly specifying pgnum on pool creation
2012-11-04 11:42 explicitly specifying pgnum on pool creation Sage Weil
@ 2012-11-05 18:55 ` Josh Durgin
2012-11-05 19:35 ` Sage Weil
0 siblings, 1 reply; 3+ messages in thread
From: Josh Durgin @ 2012-11-05 18:55 UTC (permalink / raw)
To: Sage Weil; +Cc: ceph-devel
On 11/04/2012 03:42 AM, Sage Weil wrote:
> The wip-explicit-pgnum changes the 'ceph osd pool create <name> <pgnum>'
> command to require the pg_num value instead of defaulting to 8. This
> would make it harder for users to get this wrong.
I like this. It'd be great if we could add a pgnum argument to
'rados mkpool' and the corresponding librados pool_create* functions
too.
> On the other hand, it probably also breaks some scripts for deploying
> OpenStack that create volume and image pools. :/
If those scripts are creating pools with 8 pgs, they're going to
create problems anyway. I don't mind breaking them as long as it's well
documented (i.e. release notes and docs on 'ceph osd pool create'
should mention the change).
> Ideas?
>
> The original idea was that the monitor would automagically notice when a
> small pgnum pool gets lots of objects and trigger a split. Even if we
> don't do that, pretty soon now you'll be able to explicitly increase
> pg_num. I still think it might be a good idea to require it up-front,
> though.
Until split is implemented and well-tested, I think it makes sense to
require it up-front. It's easy to relax that requirement later if we
want to make it more automatic.
> An alternative would be to default to a larger number (say, num_osds <<
> 2). My concern there is that it makes it easy to create lots of pgs for
> pools that may be small, and it's still not large enough to get good
> performance for the "create pool, run rados bench" crowd.
It would also be easy to create too few pgs, and then add a bunch of
osds later.
Josh
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: explicitly specifying pgnum on pool creation
2012-11-05 18:55 ` Josh Durgin
@ 2012-11-05 19:35 ` Sage Weil
0 siblings, 0 replies; 3+ messages in thread
From: Sage Weil @ 2012-11-05 19:35 UTC (permalink / raw)
To: Josh Durgin; +Cc: ceph-devel
On Mon, 5 Nov 2012, Josh Durgin wrote:
> On 11/04/2012 03:42 AM, Sage Weil wrote:
> > The wip-explicit-pgnum changes the 'ceph osd pool create <name> <pgnum>'
> > command to require the pg_num value instead of defaulting to 8. This
> > would make it harder for users to get this wrong.
>
> I like this. It'd be great if we could add a pgnum argument to
> 'rados mkpool' and the corresponding librados pool_create* functions
> too.
I'm tempted to remove those commands from teh rados tool. I think we need
to keep them in the librados api, tho, so maybe that's not helpful.
Anyway, yeah, definitely!
> > On the other hand, it probably also breaks some scripts for deploying
> > OpenStack that create volume and image pools. :/
>
> If those scripts are creating pools with 8 pgs, they're going to
> create problems anyway. I don't mind breaking them as long as it's well
> documented (i.e. release notes and docs on 'ceph osd pool create'
> should mention the change).
Ok. Let's try to do this this week for bobtail!
sage
>
> > Ideas?
> >
> > The original idea was that the monitor would automagically notice when a
> > small pgnum pool gets lots of objects and trigger a split. Even if we
> > don't do that, pretty soon now you'll be able to explicitly increase
> > pg_num. I still think it might be a good idea to require it up-front,
> > though.
>
> Until split is implemented and well-tested, I think it makes sense to
> require it up-front. It's easy to relax that requirement later if we
> want to make it more automatic.
>
> > An alternative would be to default to a larger number (say, num_osds <<
> > 2). My concern there is that it makes it easy to create lots of pgs for
> > pools that may be small, and it's still not large enough to get good
> > performance for the "create pool, run rados bench" crowd.
>
> It would also be easy to create too few pgs, and then add a bunch of
> osds later.
>
> Josh
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-11-05 19:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-04 11:42 explicitly specifying pgnum on pool creation Sage Weil
2012-11-05 18:55 ` Josh Durgin
2012-11-05 19:35 ` Sage Weil
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.