On Wed, Apr 11, 2007 at 05:51:47AM -0600, Andreas Dilger wrote:
> > Of course the temptation then would be to start adding conditions,
> > functions, maybe an entire tcl interpreter.... :-)
>
> Yes, I thought of this too, and also the "let's build a full interpreted
> language into debugfs" conclusion. It wouldn't be fatal though - in
> some cases it would be nice to have debugfs loop over inodes to fix some
> unusual corruption.
I have actually thought about the possibility of extending libss so
that it would optionally load the tcl shared library, just as today we
optionally load the readline library. The interfaces used by libss to
call individual command handlers and those used by tcl aren't actually
all that different.
If someone wanted to look into it, patches would certainly be
gratefully accepted. Having the ability to loop over inodes would
come in handy, and while you can do it to day by writing the script in
perl or bash and then using debugfs -R, (1) it's clumsy, and (2) it's
slow for big filesystems if you have to read the bitmaps each time.
Speaking of which, wasn't someone going to write patches that did lazy
bitmap loading for debugfs? I can't remember who said they would do
that. To whoever was going to do that --- one thought which I had ---
it would probably be a good idea to keep the current catastrophic
mode, and change it so that in catatrophic mode, bitmaps are not
loaded automatically, and an error message is returned right away.
There may be situations where you don't want debugfs to ever even try
loading the bitmaps (because they will fail after waiting a long
time), and so an immediate refusal to execute a particular command
requires the bitmaps to be loaded may be preferable.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
