terryl@sri-unix (07/28/82)
Has anyone ever come across the cryptic message from fsck that goes something like this: "Possible file size error inum = a number"? Well, I have and I thought I'd check it it out further. What the message means is that the blocks allocated to the file do not correspond to the size of the file. After much further digging, I found the problem in writei in the ker- nel. When a user is creating a file, (or writing a file where the block the users wants to write does not exist), bmap will allocate a block from the file system for the user. Then writei will do an iomove from the user process into the kernel buffer that corresponds to the block just allocated. If the iomove is successful, then everything is hunky-dory and the user structure variables u.u_base, u.u_count, and u.u_offset are updated to reflect this; however, if the iomove is not successful, then the variables are not updated. When the call to iomove returns to writei, writei checks to see if u.u_offset is greater than the inode size; if it is, then the inode size is updated to the value of u.u_offset. If the iomove was not successful, then the inode size is not updated, but the block allocated in bmap is still associated with that inode, thus causing the "Possible file size error" in fsck. This bug exists in the Berkeley kernel that we run on our 11/70, and I do believe that it exists in the virgin v7 system, also. I do not know if this bug exists on any of the VAX systems, but I would hazard a guess that it does. The bug is not dangerous in any way, but could only cause a lost block or so in the file system. The fix (if anyone considers this a serious bug) is pretty obvious; the block allocated in bmap should be released. Terry Laskodi decvax!teklabs!terryl or ucbvax!teklabs!terryl