[Ocfs2-tools-devel] [PATCH 0/24] tunefs rework V3

[Joel Becker]

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.

[Changes in V3]

- I didn't add feature_inline_data.c in the last iteration.  That would
  have been bad to miss.  It's in there now.
- tunefs_foreach_inode() tried to play tricks with the filetype.
  However, filetypes are not independent flags, so we have to let the
  iteration functions check for them.  This updates libocfs2ne and the
  features unwritten_extents and sparse_files.

[Changes in V2]

- Mark concurred with leaving superseded feature options out of help.
- Better TUNEFS_ET_SPARSE_MISSING message.
- Fixed allocation bug in op_set_journal_size.c
- Added a comment in op_set_slot_count.c re: strtol usage for ints
- Moved clusters_to_bytes(), etc out of op_resize.c and into
  ocfs2/ocfs2.h where they belong.  Filled out the entire API.
- Moved empty_clusters() and get_free_clusters() into libocfs2ne.
- Moved checks for OCFS2_SYSTEM_FL out of tunefs_foreach_inode() and
  into the callers.

[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 five 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.