[Ocfs2-tools-devel] [PATCH] Option to skip cluster checking in tunefs.ocfs2

[Joel Becker]

On Tue, Oct 20, 2009 at 10:29:17PM +0200, Lars Marowsky-Bree wrote:
> I don't get the resistance to being able to force this if the stack is
> down. (We have so many ways how root can screw up a Linux system.) I
> could just get out a hex editor and do as I please, anyway ;-) 

	Allowing root to play with fire is fine.  But why hand out
matches if there is already a perfectly good pizo-electric starter?

> Even --list-sparse refuses w/o the cluster stack.

	That's pretty silly ;-)  I would expect --list-sparse and
--query could probably do without it.  Of course, we're considering
an o2info program to take query out of tunefs...

> Some admins may prefer to make changes to an OCFS2 mount in a
> virtualized environment too (ie, modifying the fs on Dom0 while the
> DomUs are stopped).

	*This* is a logical use case that requires some thought.  Of
course, you could just bring up a domU.

> I really think you're over-doing it here with insisting there mustn't be
> a way to force the computer to do as the admin wants to. Add a big
> warning, sure ...

	Years of experience is that most people always run with --force.
Then they call support.

> > 	Basically, you only run into the LVB size problem if the
> > lockspace already exists.  That only happens if someone is mounted.  And
> > if someone is mounted, you sure as heck don't want to --force.
> 
> # tunefs.ocfs2 -v --fs-features xattr /dev/dm-6
> Enabling feature "xattr"
> Cannot lock the filesystem. If you are sure the filesystem is not
> mounted on any node, you can use --force or -F to skip this check.
> tunefs.ocfs2: Unable to access cluster service while opening device "/dev/dm-6"
> 
> That _is_ with the stack up and the fs umounted. (And, admittedly, with
> Jan's patch.)

	I wonder what is going on there.  Do you have the filesystem
mounted on other nodes?  (I figured it had Jan's patch)

> dlm_tool ls does not show the lockspace, yet I seem to be hitting this
> problem. Or is this another issue?

	Weird.  I wonder what's up there.  Can you strace the sucker,
see where the error is?

> ...
> Oct 20 22:22:52 hex-0 ocfs2_controld[7198]: Mountgroup
> C5455FCF4BED429A9B0891DFE666687B successfully registered with dlm_controld
> Oct 20 22:22:52 hex-0 ocfs2_controld[7198]: notify_mount_client sending
> 0 "OK"
> Oct 20 22:22:52 hex-0 ocfs2_controld[7198]: Notified client: 1
> Oct 20 22:22:52 hex-0 ocfs2_controld[7198]: client msg
> Oct 20 22:22:52 hex-0 ocfs2_controld[7198]: client message 1 from 5: MRESULT
> Oct 20 22:22:52 hex-0 ocfs2_controld[7198]: complete_mount: uuid "C5455FCF4BED429A9B0891DFE666687B", errcode "-1485330 943", service "tunefs.ocfs2"

	I think this is tunefs.ocfs2 reporting to ocfs2_controld that it
had a problem so that ocfs2_controld cleans up.

Joel

-- 

"This is the end, beautiful friend.
 This is the end, my only friend the end
 Of our elaborate plans, the end
 Of everything that stands, the end
 No safety or surprise, the end
 I'll never look into your eyes again."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127