Jan Kopriva wrote:
> max at bruningsystems.com wrote:
>> Michael Shapiro wrote:
>>>> Hi all,
>>>>
>>>> since ufs community is somehow assumed dead and inactive and
>>>> therefore viewed as not being able to sponsor projects,
>>>> I would like to know your opinion and possibly ask for sponsorship
>>>> of the following project related to MDB.
>>>>
>>>> ufs-ondisk
>>>>
>>>> Description:
>>>>
>>>> The goal of the project is to provide a user with reliable tool for
>>>> working with ufs on disk format.
>>>> The tool will provide the following:
>>>>
>>>> - browsing and changing ufs ondisk metadata
>>>> - formatted and unformatted output of ufs ondisk objects
>>>> - browsing ondisk file data
>>>> - browsing and changing ufs ondisk logs
>>>>
>>>> For this purpose we will create a separate component(module):
>>>> libufs that will handle all the related logic
>>>> and export public interfaces which will be used by the external
>>>> consumers. The most important consumer
>>>> will be a new MDB module created together with libufs. MDB has been
>>>> chosen for its modularity and
>>>> because it is one of the main tools used by sustaining engineers
>>>> and kernel internals students.
>>>> The project aims those two categories of users. MDB already
>>>> supports ufs in-core,
>>>> thus having ufs-ondisk would make a nice complement to it.
>>>>
>>>> Thanks
>>>>
>>>> Jan
>>>>
>>>
>>> Certainly feel free to contribute this work: better debugging support
>>> is always a good thing. That said, if you had the choice, contributing
>>> more ZFS debugging support or some other filesystem not headed for EOL
>>> is a more strategic use of time and effort.
>>>
>>> -Mike
>>>
>>>
>> Hi,
>> A lot of what you want to do can already be done via fstyp -v and
>> fsdb_ufs(1M). If you want to extend mdb,
>> a (what I think) much more interesting project/RFE is to allow mdb
>> to use CTF information with the raw disk. This would allow ::print
>> to work with data structures on the raw disk. This would allow you
>> to debug UFS as well as ZFS, and any other file system that is stored
>> on disk. Just my 2 cents. I have started implementing this, but
>> have a ways to go and not enough time at present.
>>
>> max
> Hi Max,
>
> we basically want to have this feature - finding the info on the raw
> disk and use mdb commands for it.
> In the end, you still end up with a file system dependent code, that
> is why we want to introduce libufs.
>
> Regards
>
> Jan
>
>
Hi Jan,
I am not arguing with the idea of libufs. I think it is a good idea.
But I would start with adding support in mdb for loading CTF information
from kernel modules to be used with the raw disk. I find that with
::print, there are only a few other dcmds/walkers that I regularly use.
It would be great to be able to specify an inumber to get the on-disk
location of an inode, and then ::print -p struct icommon to print out
the contents. So the "specify an inumber to get the on-disk location"
would be a new dcmd, but ::print is already there (assuming you can load
CTF info). Once you have the CTF info, you are not constrained to doing
this only with ufs. In other words, it would work with zfs as well.
