Re: mkfs and mdadm support

[snacktime <snacktime@gmail.com>]

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