All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.