When a FS really is that corrupt you may be out of luck anyway. Recovery from alternative superblocks hasn't really helped me in the past. I think a combination of live determination and maybe the state file is ok. Right now I use exec calls to create and verify existing filesystems and it's better to have a standard puppet type to do it.
In my oppinion Puppet should have this feature and the user can decide if he wants to use it. On 2/26/10, Luke Kanies <[email protected]> wrote: > On Feb 26, 2010, at 11:28 AM, Marcin Owsiany wrote: > >> On Thu, Feb 25, 2010 at 06:13:12PM +0100, Daniel wrote: >>> On Thu, Feb 25, 2010 at 6:05 PM, Luke Kanies >>> <[email protected]> wrote: >>>> On Feb 25, 2010, at 12:13 AM, Marcin Owsiany wrote: >>>> >>>>> On Wed, Feb 24, 2010 at 09:24:55AM -0800, Luke Kanies wrote: >>>>>> >>>>>> Or should we maybe skip the filesystem type entirely and just >>>>>> initialize >>>>>> the volume as a given filesystem when the volume itself is >>>>>> created? >>>>>> E.g., something like: >>>>>> >>>>>> logical_volume { foo: vg => bar, fs => ext3, ensure => present } >>>>>> >>>>>> So when you create the lv, you initialize the fs, but otherwise >>>>>> you >>>>>> don't mess with it. >>>>> >>>>> Makes sense, although you should not get rid of the FS type. It >>>>> will >>>>> still be useful for changing filesystem type (including online >>>>> migration >>>>> between compatible filesystems like ext2->ext3). >>>> >>>> Is there, then, a consistent, safe way to determine the filesystem >>>> type? >>> >>> Maybe file i another option can help. >>> >>> # file -s /dev/mapper/rootvg-tmplv >>> /dev/mapper/rootvg-tmplv: ReiserFS V3.6 block size 4096 (mounted or >>> unclean) num blocks 128000 r5 hash >> >> That's also approximately the method I used in my provider for the >> filesystem type. >> >>> I'm not sure if this works when the superblock is corrupt. Maybe i >>> can >>> do some testing on this subject >> >> I'm not sure it matters. There could always be a situation where your >> filesystem is broken enough for file/mount/kernel to not be able to >> recognize it, but for the data to still be in a recoverable state (at >> least partially). The point is that we don't want puppet to do >> anything >> harmful (like recreate the filesystem) in that case. Then again I >> don't >> know if there is anything that you can do to a filesystem without >> potentially harming it.. > > This sounds basically intractable - there's no dependable way to know > if there's a filesystem in place, which to me means there's no way to > know if we should create a filesystem. Right? > > Even recording the fact that we've created an FS before isn't > foolproof - if someone removes the state.yaml file, we lose that > recorded information. > > -- > Experience is the name everyone gives to their mistakes. > -- Oscar Wilde > --------------------------------------------------------------------- > Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- Sent from Google Mail for mobile | mobile.google.com Cheers, Daniel -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
