Debugging pseudo-disk driver on FreeBSD

[Siddharth Aggarwal]

Hi,

I am working on a Copy on Write disk driver on FreeBSD where I try to save
the state of a filesystem (/dev/ad0s3) to another device (/dev/ad0s4) by
making a virtual device that sits on top of these two (/dev/shd0).

1. So in the strategy routine, I get the block read/write calls to
(/dev/shd0) .
2. For a write operation, I copy the previous contents of the block
(number corresponding to /dev/ad0s3)  on to a free block on /dev/ad0s4
3. To restore previous contents of disk, I read the allocated free block
from /dev/ad0s4 and write it back to original block number /dev/ad0s3.

The virtual device /dev/shd0 is mounted on /mnt

So to test it out, my /dev/ad0s3 originally had a file "old1" of 13685
bytes containing repeating string pattern (OLDOLD)
I then copied a file "new1" of 8211 bytes having the repeating pattern
(NEWNEW) to overwrite the old one
i.e. cp new1 /mnt/old1

A hexdump shows that a block of 8192 bytes containing "OLDOLD" was copied
over to /dev/ad0s4 and its place being taken be "NEWNEW" in /dev/ad0s3.
Also remaining bytes (beyond the 8192 bytes) still remain in /dev/ad0s3.
So this shows that the copy on write was done correctly. And I correctly
see 8211 bytes of "NEWNEW" in /mnt/old1 (ls -l /mnt/old1)

I then send an IOCTL to my driver to restore to the previous state
(expecting it to give me 13685 bytes of "OLDOLD" back in /mnt/old1)
After unmounting and remounting, I see that the contents of /mnt/old1 have
become OLDOLD, but there are only 8211 bytes instead of 13685. A hexdump of
/dev/ad0s3 however, shows that there are indeed 13685 consecutive bytes of
OLDOLD lying there.

This has lead me to believe that the Inode of /mnt/old1 is not being
refereshed (or it was never saved off to the /dev/ad0s4 in the first place). Do Inode
read/writes go through the strategy routine in the first place?

Any idea what could be going wrong?

Thanks.