Re: mkfs and mdadm support

[snacktime <snacktime@gmail.com>]

One issue I'm running into is how to handle potentially dangerous operations like mkfs.    mkfs will fail without a force flag if you try to run it on a device that is already initialized with the same filesystem type, but if you run mkfs.ext3 on an xfs filesystem, it will happily create it without any warning.  I know there are other checks that can be done, but one bad regex and bye bye filesystem.  Using lvm or raid helps some because you could probably have a rule that if a device exists, it has a filesystem.  Your recipes for creating filesystems always create the device and filesystem in one operation, or not at all.

Another option would be to have a role just for initializing servers.  You put a server into that role to initialize it, and manually take it out once you know it's initialized correctly.  Other roles would not have recipes that run mkfs at all.  'Normal' roles would only do things like assembling/stopping raid arrays, mounting/unmounting filesystems, etc..  If I need to add a volume to an existing raid array or lvm group, I do that manually, add it to my json ball, and it just works.  Next reboot chef has the data it needs to bring everything up correctly.

This is one reason why I'm considering have a completely separate resource/provider for mkfs and friends.  I don't want it anywhere near critical data, and the thought of an automated script checking to see if my filesystem needs to be initialized would keep me up at night.

Chris

On Fri, Jun 12, 2009 at 11:34 AM, snacktime <snacktime@gmail.com> wrote:

For now I'm making a resource and provider for each one separately.  it won't be difficult to either add a higher level abstraction later, once everyone is in agreement as to what it should be. I hacked together about 50% of a raid resource/provider last night and will probably have time this weekend to get something done on lvm2.

On Tue, Jun 9, 2009 at 11:32 AM, Jeffrey Hulten <jhulten@gmail.com> wrote:

Wouldn't raid and lvm (and drbd, etc) all be volume types? It seems that they all provide a device to place a filesystem on.

For raw disk, sda/hda.
For raid, md0, etc.
For lvm, a VG which a LV is built from.
For drbd, drbd0, etc.

On Tue, Jun 9, 2009 at 10:53 AM, snacktime <snacktime@gmail.com> wrote:

Thanks, I totally missed the -s option.  I'm looking at the best way to safeguard against running mkfs on an existing filesystem.   So one of the options to the provider will be a force flag of some type, and if that flag is not present it will refuse to re initialize the filesystem.  mkfs isn't uniform in requiring a force flag to re initialize a device that already has a filesystem, so can't rely on that.

Chris

On Tue, Jun 9, 2009 at 10:26 AM, Steven Parkes <smparkes@smparkes.net> wrote:

Don’t know if there are corner cases that don’t work, but “file –s /dev/<block_device>”

 

From: snacktime [mailto:snacktime@gmail.com]
Sent: Tuesday, June 09, 2009 10:18 AM
To: chef@lists.opscode.com
Subject: Re: mkfs and mdadm support

 

That's kind of the conclusion I came to last night after thinking it over some more.  I've forked chef and started last night on the filesystem and raid resources.  Should be easy enough to re arrange if needed.

 

Would be nice if there was an available tool for detecting filesystem types.  Best I've found so far is parsing the output of parted.  Anyone know of a better way to handle this? 

 

Chris

On Tue, Jun 9, 2009 at 9:11 AM, Miguel Cabeça <cabeca@ist.utl.pt> wrote:

Hi,

 

So maybe there should be a top level filesystem resource that contain all of this.  Even after you add resources for mkfs, lvm, raid, etc.., you still need higher level logic to tie it all together, maybe a collection of definitions?

 

IMHO it would be too complicated to try to fit everything into the filesystem resource.

It would be simpler (famous last words) to have three resources like:
 filesystem
 raid
 volume

and combine them with definitions to achieve the complete goal (for example a xfs filesystem on top of an lvm2 volume, on top of a raid1 array)

Best Regards

Miguel Cabeça