Mount and ext3 issues with Busybox 1.2.2.1

Rob Landley rob at landley.net
Mon Nov 20 05:36:59 UTC 2006


On Friday 17 November 2006 4:31 pm, Denis Vlasenko wrote:
> On Thursday 16 November 2006 23:16, Jim Gifford wrote:
> > I've taken this step a little further, instead of using my dynamic 
> > linked version, I tried to build busybox statically. The same errors 
> > occur. Then I also tried using a glibc static linked version, again the 
> > same failure.
> 
> Are you using busybox's mke2fs? If yes, try using "standard" one.
> 
> I think that having specialized filesystem utilities in busybox
> is a mistake. Filesystems are critical to people's data.
> Bugfixes to them are critical. Bugs can be particularly deadly
> ("busybox's e2fsck ate my disk!!!").

Actually, mke2fs and tune2fs aren't brain surgery.  The ones we have are 
_crap_, but I was in the process of writing new ones when I burned out, and 
the two of them together probably wouldn't have totaled 1000 lines.  The 
current monstrosity is constructed as a set of nested libraries that nobody 
ever re-uses.  (There's a uuid generation library.  Yes really.  It can be 
replaced with about 5 lines of C, I know this because I did it.  Posted it 
here even, check the archives...)

As for e2fsck, that's actually not as bad as it looks.  Again, current 
implementation is horrible, but in general if you keep in mind that if you 
can't be sure you've fixed it, don't mess with it (and don't sign off on it 
as fixed either), then you at least won't make things worse.

I hope to get around to doing all this in toybox someday.  (At the moment I'm 
still debugging my new command line parsing infrastructure before 
implementing a gazillion small simple commands like "setsid"...)

> It is not reasonable to expect busybox version of e.g.
> reiserfsck to be kept up-to-date. Well, unless we will have
> particularly devoted maintainer for such a task.

Screw reiserfs.  There is one standard Linux filesystem, and it's the ext2 
line (including ext3 and ext4).  You don't need to be "up to date" with the 
mkfs utilities, a 1998 version still makes a readable filesystem (after all, 
you make an _empty_ filesystem and then the kernel driver takes over), and 
tune2fs isn't hard (which can add has_journal and dir_index to bring up you 
to date).

For most of the other stuff I looked at (gene2fs, mkisofs, mksquashfs) it's 
really an archiver more than anything else, and isn't so scary if you 
approach it as one.  There's nothing magical about filesystems. :)

> Currently we don't have one. e2fs code is not actively maintained.

You may remember me objecting to it going in way back when?  That was in the 
grey zone when I was acting maintainer but not official maintainer yet: I 
couldn't really say no to the other people with CVS commit access, just 
grumble in their direction about leaving messes for other people to clean up.

> What I see there - I don't like it. Random example:

The entirety of e2fsprogs in BusyBox is crap.  I'd planned to rewrite it from 
scratch.  Still plan to in toybox, it just got bumped down the todo list a 
bit while I go after low-hanging fruit first...

> Since when utilities decide what should be in PATH??
> I (user) is in charge here!

What's it shelling out to?

(There's usually a historical reason for this kind of thing.  Doesn't mean it 
was ever a good idea, I just usually prefer to figure out what they were 
_trying_ to do unless I'm taking a start-over-from-scratch approach.  For 
mke2fs you can start over, but for e2fsck you have to look at the old one 
because nothing else documents everything it's doing and the _point_ of 
e2fsck is to catch things the filesystem driver won't...)

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery



More information about the busybox mailing list