[Lustre-discuss] Selective e2fsprogs installation on Ubuntu

[Jim Garlick]

Hi Andreas,

I wholeheartedly agree.  I'll submit a patch to bugzilla for your
consideration.  If it's accepted, then we won't have to maintain it :-)

Jim

On Thu, Jun 03, 2010 at 01:02:17PM -0700, Andreas Dilger wrote:
> On 2010-06-03, at 13:47, Jim Garlick wrote:
> > Actually I just redid the patch for 1.41.10.sun2 (attached).
> > Haven't tested it yet but it should be OK.
> > 
> > It's mostly print stuff with one exception: mke2fs creates a journal if
> > argv[0] is mke3fs (we add mkfs.ldiskfs).  Some of the prints instruct users
> > to run commands, so its a bit more than cosmetic.
> 
> If I had one complaint about this patch is the name "tune.ldiskfs" isn't right. The generic command is called "tunefs", so it should be called "tunefs.ldiskfs", like "tunefs.lustre".
> 
> TUNEFS(8)                 BSD System Manager's Manual                TUNEFS(8)
> 
> NAME
>      tunefs -- tune up an existing file system
> :
> :
> BUGS
>      You can tune a file system, but you can't tune a fish.
> 
> HISTORY
>      The tunefs command appeared in 4.2BSD.
> 
> 
> Now, if I had two complaints about this patch (sorry), the second one would be that it is not possible to include this into our e2fsprogs as-is because it unconditionally replaces all of the command names instead of having a "subst" or #define that allows the use of either the standard command names or the ldiskfsprogs names via a configure option.
> 
> The 1.6 and 1.8 Lustre allow the use of the --with-ldiskfsprogs configure option in ldiskfs/build/autoconf/lustre-build.m4 to select the alternate names added by your patch, it would be nice to add the same --with-ldiskfsprogs to e2fsprogs so that we can consolidate the e2fsprogs code better.
> 
> 
> > On Thu, Jun 03, 2010 at 11:55:52AM -0700, Ramiro Alba Queipo wrote:
> >> Hi Jim,
> >> 
> >> Thanks for the patch. Now I can see how enable using ldiskfsprogs
> >> instead of e2fsprogs, so than can be installed without overwriting the
> >> original binaries in e2fsprogs.
> >> The only thing is that your patch as it is for 1.41.5.sun1, must be
> >> redone for 1.41.10.sun2, but I wonder if this changes only affect to
> >> print stuff so that it is 'safe' to not to commit then. Or else, they
> >> can modify program behaviour
> >> 
> >> Cheers
> >> 
> >> On Tue, 2010-06-01 at 10:54 -0700, Jim Garlick wrote:
> >>> I've attached our patch to e2fsprogs which turns it into ldiskfsprogs.
> >>> We also have a custom spec file for it but since you're using Ubuntu I assume
> >>> that's of no use to you.
> >>> 
> >>> This is against 1.41.5.sun1
> >>> 
> >>> Jim
> >>> 
> >>> On Tue, Jun 01, 2010 at 10:19:05AM -0700, Andreas Dilger wrote:
> >>>> On 2010-06-01, at 07:25, Ramiro Alba Queipo wrote:
> >>>>> On Tue, 2010-06-01 at 02:15 -0600, Andreas Dilger wrote:
> >>>>>> On 2010-06-01, at 01:23, Ramiro Alba Queipo wrote:
> >>>>>>> I've just compiled the last patched e2fsprogs (1.41.10) package suitable
> >>>>>>> for the last lustre version (1.8.3) and I had some booting problems when
> >>>>>>> overriding some existing files in original packages (Ubuntu LTS 10.04),
> >>>>>>> so I thought it would be better to install only the needed programs from
> >>>>>>> patched e2fsprogs:
> >>>>>> 
> >>>>>> It is possible to build the lustre e2fsprogs as "ldiskfsprogs" via configure option.
> >>>>> 
> >>>>> Fine. But, I can not see how to do it. No references to ldiskfsprogs
> >>>>> when doing ./configure --help. Only seen at 'e2fsprogs.spec.in, but I do
> >>>>> not know how to use. Please, could you give me a minimal guideline. I've
> >>>>> worked enough with autoconf/automake so that I can understand it .
> >>>> 
> >>>> Hmm, possibly this is still in a patch at LLNL?  Maybe Jim (CC'd) can send you their latest patch.
> >>>> 
> >>>> Also, depending on what the problem actually is, you can build the e2fsprogs package without many of the optional components:
> >>>> 
> >>>>  --disable-libuuid	  do not build private uuid library
> >>>>  --disable-libblkid	  do not build private blkid library
> >>>>  --disable-debugfs   	  disable support of debugfs program
> >>>>  --disable-e2scan   	  disable support of e2scan program
> >>>>  --disable-imager   	  disable support of e2image program
> >>>>  --disable-resizer   	  disable support of e2resize program
> >>>>  --disable-tls           disable use of thread local support
> >>>>  --disable-uuidd         disable building the uuid daemon
> >>>> 
> >>>> Of course, it would also be good to figure out what was actually causing your booting problems, and fix that rather than just working around it.
> >>>> 
> >> 
> >>>>> Clients:
> >>>>> --------
> >>>>> 
> >>>>> Only 'lfsck' (compiled with --with-lustre=_LUSTRE_SOURCE_DIR_) is useful
> >>>>> 
> >>>>> Servers:
> >>>>> --------
> >>>>> 
> >>>>> mke2fs -> called by 'mkfs.lustre'
> >>>>> e2fsck -> not called by lustre but needed to check a failed MDT/OST so
> >>>>> it can be installed as other name
> >>>>> tune2fs -> called by tunefs.lustre?/can be installed as a not existing
> >>>>> program
> >>>>> dumpe2fs -> useful but not essential?
> >>>>> 
> >>>>> Please, tell me if I am missing/misunderstanding  something?
> 
> 
> Cheers, Andreas
> --
> Andreas Dilger
> Lustre Technical Lead
> Oracle Corporation Canada Inc.