I am looking for advice:

        I am developing a file system (it can exist as a module or compiled in).

        A problem has developed which I do not know how to debug and would like
        some advice.

        The symptoms:
                I can mount my FS read from it, write into and out of it and unmount
        it. However, it is subject to periodic page-faults. These can happen while
        the FS is mounted, or after it has been dismounted (even for a while).
        The page-fault occurs at random and doesn't depend on whether I reference
        the FS or not. When I look at the core dump, I see that it occurs in
        the VFS usually after an open, say ufs_open(), and often in vn_isdisk().
        When I look at the arguments to these calls, I see *vp = 0 or a bad address.

        Clearly my FS has corrupted a vnode, or the buffer cache.

        (Maybe some vnodes are still locked or referenced, or corrupted? or some
         buffer blocks are corrupted or not released?)

        So I'm thinking to do the following:

                1. Mount my FS, cd into it and do the following:

                        cp /etc/passwd .
                        rm *
                        cd /
                        umount /mnt

                2. panic the system to get a core dump.
                        This could be done, say, by putting the panic(9) call
                        in my vfs unmount() function before the return.

        My questions:

           Is there a way to analyize a core dump with gdb(1) and detect:

                a) corrupted vnodes?
                b) locked/referenced vnodes (that should have been released)?
                c) corrupted buffer cache?
                d) locked buffer blocks (that should have been released)?

           In other words, I want evaluate the state of the vfs after my
           FS has done its damage, but before the inevitable panic occurs.

           Any further hints on what I should look at would be greatly appreciated.

                        Thank-you
                        Ed Alley
                        

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to