Debugging pseudo-disk driver on FreeBSD

[Siddharth Aggarwal]

On Sun, 2 May 2004, Siddharth Aggarwal wrote:

>
> 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.
>

I think I know what's going wrong here. The Inode it seems is getting
cached (probably the in-core inode) and that is overwriting the Inode that
I restore from the shadow
device. I used cksum to get the CRC of the device /dev/ad0s3
1. right after restoring to the previous state and
2. after restoring to the previous state and the doing ls -l /mnt/old1
followed by a sync.
The values returned by the 2 cksums are different.

So is there a way to invalidate in-core/cached inodes so that they don't
get flushed to the disk and overwrite the inode contents that I want?


 > 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?
>