[Ocfs2-tools-devel] [PATCH 0/22] tunefs rework

Joel Becker joel.becker at oracle.com
Fri Jul 25 19:07:38 PDT 2008


This is a rework of the tunefs.ocfs2 program.  More than one of us has
noted that adding capabilities to tunefs.ocfs2 is a chore.  The code
often does the same thing in multiple places.  A new capability has to
add itself to many, many parts of the code.

The rework had these major goals:
    
1) All operations would be independent.  They do not need to know what
   else is running.  They live in a separate C file and can be tested by
   themselves.
    
2) All operation can run in the same invocation of tunefs.  The master
   program makes sure the appropriate locks are taken and that each
   operation is given a clean filesystem to work with.
    
3) The actual working code should move over with only small changes.
   The code that performs an operation is largely unchanged.  Output
   functions are different, and a couple common bits of code moved into
   libocfs2ne.

4) After the rework, adding new capabilities should be adding one source
   file and connecting it to the master code.


[Open Question]

Some tunefs.ocfs2 options were actually feature flags.  For example,
'-M cluster' is really '--fs-features=nolocal'.  ocfs2ne supports both
methods for all of these options.  It is fully compatible with
tunefs.ocfs2, and adds the ability to specify these feature flags in
--fs-features.  The actual work is done as a feature method.

The question is, what do we print in the output of '--help'?  Do we tell
people to prefer the old way, mention the old way but mark it as
deprecated, or leave out the old way and only describe the
'--fs-features' way?  I chose the last one, but it's trivial to change.


[About the Patches]

The last patchset I sent out, I got feedback that underlying functions
were hard to review without knowing how they would be used.  So this
patch series is in a sort of reverse order, starting with the simplest
methods, going to the more complex ones, and finally introducing the
libocfs2ne library and ocfs2ne master program.  Hopefully, the shared
functions used by the methods will be obvious in what they do, and the
methods will be very readable.

If this isn't the case, just start from the last patch and go backwards.
But give me feedback so I can see if everyone finds this doesn't work.

The patches are in four groups.

First, there are four patches to libocfs2 to enhance the feature code.
Three of these have already been seen on ocfs2-tools devel.  A fifth
patch introduces the internal ocfs2ne error codes.

The second group of eight patches contains every operation except
feature bits.  These operations should be pretty readable by themselves.

The third group has six patches.  The five feature methods ocfs2ne
supports, followed by the features operation.  The feature operation is
a peer to the operations in the second group, and it handles running the
feature methods.

Finally, the fourth group contains the libocfs2ne library and the
ocfs2ne master program.  The library contains the shared routines used
by everything, like error functions, functions to block signals, and so
on.  The ocfs2ne program parses the command line arguments and generates
a list of operations to run.  It then runs each in turn.  This group
also includes the Makefile bits.

The code is available via git, in the 'tools-cleanup' branch of the
ocfs2-tools git repository.

View:
http://oss.oracle.com/git/?p=ocfs2-tools.git;a=shortlog;h=tunefs-cleanup
Pull:
git pull git://oss.oracle.com/git/ocfs2-tools.git tunefs-cleanup


[FAQ]

1) Why don't these patches remove the old code?

   I wanted to test the code alongside each other to ensure the reworked
   code functions properly.  Please test!  Once we're happy, I'll make
   the patch to remove the old code.

2) Why 'ocfs2ne'?

   It's a pun on 'tune2fs', of course.  Having a different name allows
   us to build both tunefs.ocfs2 and ocfs2ne.  When the old code is
   removed, the new program will be installed as tunefs.ocfs2.

3) "It's quiet."  "Yeah, too quiet."

   The old tunefs.ocfs2 was very chatty.  This doesn't fit with a normal
   command-line program that only tells you when something goes wrong.
   The new code has proper verbosity levels - just keep adding '-v' for
   more noise.  Say '-i' like cp(1), mv(1), and rm(1) if you want
   ocfs2ne to ask you questions.






More information about the Ocfs2-tools-devel mailing list