Date: Mon, 3 May 2004 20:03:59 -0600 (MDT) From: Siddharth Aggarwal <saggarwa@cs.utah.edu> To: freebsd-fs@freebsd.org Subject: Re: Debugging pseudo-disk driver on FreeBSD Message-ID: <Pine.GSO.4.50L0.0405031958590.172-100000@faith.cs.utah.edu> In-Reply-To: <Pine.GSO.4.50L0.0405020024040.23508-100000@faith.cs.utah.edu> References: <Pine.GSO.4.50L0.0405020024040.23508-100000@faith.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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? >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.50L0.0405031958590.172-100000>