Jan Kopriva wrote: > max at bruningsystems.com wrote: >> 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. > Hi Max, > > oh ok. Sorry, I should have been more concrete in my previous posts. > We actually aim exactly for this. Another question is how to force mdb > in an elegant way to > recognize the address specified on the mdb prompt to be different > object from memory address (i.e. for the inode use a suffix? that is > processed by the modified command line parser, > so one can do something like this: 6i::print -p struct icommon) > > Regarding loading the CTF info, I think you said you have started with > the implementation. If we can look on the code it would be great. Or, > if you want to implement this fully we can connect this with our > future work. > > Regards > > Jan > Hi Jan, You should simply document that your command expects an inumber. The 2a0::itob works as expected. Other commands in mdb work this way. For instance, "0t1234:A" to attach to pid (decimal) 1234. Frank has the right idea. I should be able to chain commands together via pipes. The occasional "summary" dcmd might be useful (for instance, showing the "most important/useful" fields in super blocks, or a summary of the cylinder group blocks.
As for seeing what I've done for loading CTF, it is not enough to show. I tried, what I hoped would be, the quick and easy approach. Basically hacking away error messages and trying to "force" it to accept ctf by calling the "normal" load ctf function in the operations for raw disks. This led me to realize that I would really have to spend some time determining a good way, and I have not had time to do that. However, I shall get around to this in the next month or so, unless someone else does it first. I just want the CTF so that I can finally figure out what is on disk for zfs. For most of what I do with ufs, mdb as is, and occasionally using dd gives me what I need. max
