A: Yes, you are right. There weren't enough blocks to store all of the necessary file data. Try looking at image.200, which is big enough to hold the entire file.
A: Sure, here is what my solution produces for image.20:
fs341> debug superblock: 20 blocks 3 inode blocks 384 inodes inode 2: size: 27160 bytes direct blocks: 4 5 6 7 8 indirect block: 9 indirect data blocks: 13 14 inode 3: size: 9546 bytes direct blocks: 10 11 12
A: Both are correct! In a real filesystem, the number of inode blocks is chosen when the disk is formatted, so an operating system must be prepared to deal with whatever number of inode blocks are specified in the superblock. However, your format routine should always compute ten percent.
A: In this case, the format call should do nothing and return failure.
A: No. Format should do the minimum work necessary to create a blank filesystem. A blank filesystem should have no valid inodes, and thus no data blocks in use. The actual contents of the data blocks don't matter if no inode refers to them.
Now, if you were really worried about someone stealing your disk and then writing their own code to examine the data in blocks that were not in use, then a really aggressive filesystem would actually fill unused blocks with zeroes during a format or a delete. But, you don't have to do this.
A: A delete on an invalid inode should do nothing and return failure.
A: No, you have to use the Linux machines in the Fitzlab, because the image files are little-endian.