* Feedback: default FS pools and newfs behavior
@ 2014-05-21 15:32 John Spray
2014-05-21 19:21 ` Wido den Hollander
2014-05-26 20:57 ` Sebastien Han
0 siblings, 2 replies; 3+ messages in thread
From: John Spray @ 2014-05-21 15:32 UTC (permalink / raw)
To: Ceph Development
In response to #8010[1], I'm looking at making it possible to
explicitly disable CephFS, so that the (often unused) filesystem pools
don't hang around if they're unwanted.
The administrative behavior would change such that:
* To enable the filesystem it is necessary to create two pools and
use "ceph newfs <metadata> <data>"
* There's a new "ceph rmfs" command to disable the filesystem and
allow removing its pools
* Initially, the filesystem is disabled and the 'data' and 'metadata'
pools are not created by default
There's an initial cut of this on a branch:
https://github.com/ceph/ceph/commits/wip-nullfs
Questions:
* Are there strong opinions about whether the CephFS pools should
exist by default? I think it makes life simpler if they don't,
avoiding "what the heck is the 'data' pool?" type questions from
newcomers.
* Is it too unfriendly to require users to explicitly create pools
before running newfs, or do we need to auto-create pools when they run
newfs? Auto-creating some pools from newfs is a bit awkward
internally because it requires modifying both OSD and MDS maps in one
command.
Cheers,
John
1. http://tracker.ceph.com/issues/8010
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Feedback: default FS pools and newfs behavior
2014-05-21 15:32 Feedback: default FS pools and newfs behavior John Spray
@ 2014-05-21 19:21 ` Wido den Hollander
2014-05-26 20:57 ` Sebastien Han
1 sibling, 0 replies; 3+ messages in thread
From: Wido den Hollander @ 2014-05-21 19:21 UTC (permalink / raw)
To: John Spray, Ceph Development
On 05/21/2014 05:32 PM, John Spray wrote:
> In response to #8010[1], I'm looking at making it possible to
> explicitly disable CephFS, so that the (often unused) filesystem pools
> don't hang around if they're unwanted.
>
> The administrative behavior would change such that:
> * To enable the filesystem it is necessary to create two pools and
> use "ceph newfs <metadata> <data>"
> * There's a new "ceph rmfs" command to disable the filesystem and
> allow removing its pools
> * Initially, the filesystem is disabled and the 'data' and 'metadata'
> pools are not created by default
>
> There's an initial cut of this on a branch:
> https://github.com/ceph/ceph/commits/wip-nullfs
>
> Questions:
> * Are there strong opinions about whether the CephFS pools should
> exist by default? I think it makes life simpler if they don't,
> avoiding "what the heck is the 'data' pool?" type questions from
> newcomers.
+1
We simpler the clusters are, the better imho. A lot of users don't
require CephFS, so don't enable what ain't used.
> * Is it too unfriendly to require users to explicitly create pools
> before running newfs, or do we need to auto-create pools when they run
> newfs? Auto-creating some pools from newfs is a bit awkward
> internally because it requires modifying both OSD and MDS maps in one
> command.
>
> Cheers,
> John
>
> 1. http://tracker.ceph.com/issues/8010
> --
> 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
>
--
Wido den Hollander
42on B.V.
Ceph trainer and consultant
Phone: +31 (0)20 700 9902
Skype: contact42on
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Feedback: default FS pools and newfs behavior
2014-05-21 15:32 Feedback: default FS pools and newfs behavior John Spray
2014-05-21 19:21 ` Wido den Hollander
@ 2014-05-26 20:57 ` Sebastien Han
1 sibling, 0 replies; 3+ messages in thread
From: Sebastien Han @ 2014-05-26 20:57 UTC (permalink / raw)
To: John Spray; +Cc: ceph-devel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
Hi John,
Thanks for you work!
––––
Sébastien Han
Cloud Engineer
"Always give 100%. Unless you're giving blood.”
Phone: +33 (0)1 49 70 99 72
Mail: sebastien.han@enovance.com
Address : 11 bis, rue Roquépine - 75008 Paris
Web : www.enovance.com - Twitter : @enovance
On 21 May 2014, at 17:32, John Spray <john.spray@inktank.com> wrote:
> In response to #8010[1], I'm looking at making it possible to
> explicitly disable CephFS, so that the (often unused) filesystem pools
> don't hang around if they're unwanted.
>
> The administrative behavior would change such that:
> * To enable the filesystem it is necessary to create two pools and
> use "ceph newfs <metadata> <data>"
> * There's a new "ceph rmfs" command to disable the filesystem and
> allow removing its pools
> * Initially, the filesystem is disabled and the 'data' and 'metadata'
> pools are not created by default
>
> There's an initial cut of this on a branch:
> https://github.com/ceph/ceph/commits/wip-nullfs
>
> Questions:
> * Are there strong opinions about whether the CephFS pools should
> exist by default? I think it makes life simpler if they don't,
> avoiding "what the heck is the 'data' pool?" type questions from
> newcomers.
+1
> * Is it too unfriendly to require users to explicitly create pools
> before running newfs, or do we need to auto-create pools when they run
> newfs? Auto-creating some pools from newfs is a bit awkward
> internally because it requires modifying both OSD and MDS maps in one
> command.
I believe it is legitimate to create these 2 pools. Having this part of the process looks good to me.
The only question I have is: why don’t we have a similar behaviour for the RBD pool?
Usually even if you need RBD, you will create another pool that matches a use case.
Cheers.
>
> Cheers,
> John
>
> 1. http://tracker.ceph.com/issues/8010
> --
> 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
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-05-26 21:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-21 15:32 Feedback: default FS pools and newfs behavior John Spray
2014-05-21 19:21 ` Wido den Hollander
2014-05-26 20:57 ` Sebastien Han
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.