Debugging pseudo-disk driver on FreeBSD
saggarwa at cs.utah.edu
Mon May 3 19:04:00 PDT 2004
On Sun, 2 May 2004, Siddharth Aggarwal wrote:
> 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
> 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?
More information about the freebsd-fs