Skip to main content Link Menu Expand (external link) Document Search Copy Copied

FAQ

Table of Contents

  1. How much code will I need to write?
  2. Can BLOCK_SECTOR_SIZE change?
  3. What is the largest file size that we are supposed to support?
  4. How should a file name like a\\b be interpreted?
  5. How about a file name like /../x?
  6. How should a file name that ends in / be treated?
  7. Can we keep a struct inode_disk inside struct inode?

How much code will I need to write?

Here’s a summary of our reference solution. Note that the diff was generated relative to the staff solution for Project User Programs. The reference solution represents just one possible solution. Many other solutions are also possible and many of those differ greatly from the reference solution. Some excellent solutions may not modify all the files modified by the reference solution, and some may modify files not modified by the reference solution.

filesys/directory.c |   43 ++-
filesys/directory.h |    2
filesys/filesys.c   |  182 +++++++++++-
filesys/filesys.h   |    5
filesys/free-map.c  |   32 +-
filesys/fsutil.c    |    2
filesys/inode.c     |  435 +++++++++++++++++++++++++------
filesys/inode.h     |    6
threads/thread.c    |    1
userprog/process.c  |    4
userprog/process.h  |   10
userprog/syscall.c  |  110 +++++++
userprog/syscall.h  |    5
13 files changed, 717 insertions(+), 120 deletions(-)

Can BLOCK_SECTOR_SIZE change?

No. BLOCK_SECTOR_SIZE is fixed at 512. For integrated drive electronic (IDE) disks, this value is a fixed property of the hardware. Other disks do not necessarily have a 512-byte sector, but for simplicity Pintos only supports those that do.

What is the largest file size that we are supposed to support?

The file system partition we create will be 8 MiB or smaller. However, individual files will have to be smaller than the partition to accommodate the metadata. You’ll need to consider this when deciding your inode organization.

How should a file name like a\\b be interpreted?

Multiple consecutive slashes are equivalent to a single slash, so this file name is the same as a/b.

How about a file name like /../x?

The root directory is its own parent, so it is equivalent to /x/.

How should a file name that ends in / be treated?

Most Unix systems allow a slash at the end of the name for a directory, and reject other names that end in slashes. We will allow this behavior, but you may also choose to simply reject a name that ends in a slash.

Can we keep a struct inode_disk inside struct inode?

The goal of the 64-block limit is to bound the amount of cached file system data. If you keep a block of disk data, whether file data or metadata, anywhere in kernel memory then you have to count it against the 64-block limit. The same rule applies to anything that’s similar to a block of disk data, such as a struct inode_disk without the length member.

That means you’ll have to change the way the inode implementation accesses its corresponding on-disk inode right now since it currently just embeds a struct inode_disk in struct inode and reads the corresponding sector from disk when it’s created. Keeping extra copies of inodes would subvert the 64-block limitation that we place on your cache.

You can store a pointer to inode data in struct inode, but if you do so you should carefully make sure that this does not limit your operating system to 64 simultaneously open files. You can also store other information to help you find the inode when you need it. Similarly, you may store some metadata along with each of your 64 cache entries.

You can keep a cached copy of the free map permanently in memory if you like. It doesn’t have to count against the cache size.

byte_to_sector in filesys/inode.c uses the struct inode_disk directly without first reading that sector from wherever it was in the storage hierarchy. This will no longer work. You will need to change inode_byte_to_sector to obtain the struct inode_disk from the cache before using it.