[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-ufs-discuss
Subject:    Re: [ufs-discuss] Re: ufs_ondisk: a new project proposal
From:       "Frank Batschulat (Home)" <Frank.Batschulat () Sun ! COM>
Date:       2007-05-24 7:48:35
Message-ID: op.tstmm9ol046apg () opteron
[Download RAW message or body]

On Wed, 23 May 2007 21:42:21 +0200, Richard L. Hamilton <rlhamil@smart.net> wrote:

>> we would like to start a new project called
>> ufs_ondisk.
>>
>> The goal of the project is to create a new MDB module
>> that could be used for
>> - browsing and changing ufs ondisk metadata
>> - formatted and unformatted  output of ufs ondisk
>>  objects
>>  browsing ondisk file data
>>  browsing and changing ufs ondisk logs
>
> Can't fsdb (the UFS flavor) do all of that except the last one?
> Seems a lot of trouble to do something else rather than extend that.

actually not, it would be a cool thing to do, and in fact we even
had a project supposed to produce an mdb version of fsdb back in 2001,
Solaris 9 timeframe. Unfortunately it got killed, along with the people
and the prototype, then I guess to remember we had a 2nd attempt and MarkS
may still have that code around. so far for the history, now for the why
do this would be a good thing:

1)  What are the things fsdb lacks in?

It is very buggy, and has very difficult user interface.  Adding
support for any new UFS features has usually resulted in breaking one
or more of its other aspects. The fsdb logging support is a shining
example of that and is broken in a couple of places actually.

4658830 fsdb still doesn't handle large file systems
http://bugs.opensolaris.org/view_bug.do?bug_id=4658830

4765915 fsdb_ufs logging support is complete rubbish
http://bugs.opensolaris.org/view_bug.do?bug_id=4765915

4622941 ufs fsdb: "fs_clean CAN be trusted" lies!
http://bugs.opensolaris.org/view_bug.do?bug_id=4622941

6433317 fsdb_ufs's :inode command can display the incorrect inode number.
http://bugs.opensolaris.org/view_bug.do?bug_id=6433317

2) What would make fsdb more useful and usable?

rm -rf usr/src/cmd/fs.d/*/fsdb

Alternatively, a from-scratch re-implementation, with an eye towards
robust coding (such as not trusting what's on disk) with a less
dysfunctional user interface.

3) What information/data are not provided by fsdb?

Its general feature set is pretty good, the bugs and user interface
are the problems. We've found other solutions for almost all the things
we theoretically should use fsdb for, due to how painful fsdb is to use.

4) Are the user interfaces in fsdb easy to learn and use?

No.  The commands are modelled on adb, "to promote the use of fsdb through
familiarity".  However, it has almost no actual commands in common
with adb, and adb is far from easy to use itself.  Thus, it is almost
impossible to use fsdb without having a copy of the man page at hand
at all times.  Perhaps if it were something that was used every day,
the commands would become memorized, but such a situation is very
rare. And last but not least - adb is gone anyways since Soalris 9.

---
frankB



_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]