No, you don't have to worry about this one. The problem happens when sfs tries to remove/rename the directory entries "." or ".." which refer to the same vnode as the directory that contains them (hence, locking the directory and then the file being removed fails because they are the same thing and you are trying to acquire the same lock). Really, SFS should check that you are not trying to remove a directory, but the code you have was written for a world without subdirectories, and it was assumed that the entries "." and ".." would not be used until subdirectory support was implemented.
My apologies for not catching this one sooner.
Sure - we will be using testbin/badcall (selecting tests for the system calls you need to implement) as well as f_test, modified to run just the BIGFILE and CONCUR tests (since we don't require subdirectories this term). We will also be using a pseudo-shell program to run individual commands on your file system (e.g., cp, cat, pwd, ls, etc.) - see the assignments page if you want to try it out yourself. We will also be running the in-kernel file system stress tests to check the buffer cache implementation.
No, this doesn't indicate a problem with SFS. Refer back to the code reading questions - what's the maximum size of an SFS file, and how does that compare to the size of the BIGFILE created by f_test? To use this test with SFS, just reduce the file size to be less than the SFS maximum.
You do have to support fork by copying the parent's open file table to the new child, as per the assignment handout. That means that openfile objects can become shared, and you do need to provide synchronization for them. The comment in the code is a leftover from a previous term.
No, you do not have to implement mkdir or rmdir - you only need to implement the system calls listed in the assignment handout. Neither SFS (this year) nor emufs will support these operations anyway.
There are two possible problems here. First, you have no way of passing arguments to user-level processes when they start running. So, any test that requires arguments (like the name of the file for filetest, or the tests to run for f_test) will not work. You will need to rewrite the tests to provide these arguments at compile-time. The directory tests in f_test will not work since we are not implementing support for the directory-related system calls (mkdir/rmdir).
Second, the emulated file system does not support many of the file system operations. In particular, it will not allow you to remove a file or directory so that you cannot accidentally delete files stored on your host file system. By default, if you specify a file name without identifying the device or file system, it will refer to the boot file system, which starts out as emufs, named emu0:. So, if you run filetest and you have specified "foo" as the name of the file, it will not work because the name "foo" refers to "emu0:foo". To get around this, you can explicitly identify your SFS file system when you name the file (e.g. if you have created an SFS file system named "VOL" you would say "VOL:foo"), OR you can change the boot file system to your SFS file system after you have mounted it, using the "bootfs" command at the OS/161 menu prompt. If you do this, then you will have to identify the emufs when you name the program that you want to run (e.g., "p emu0:testbin/filetest").
If you recall the lecture notes on file system naming, this means that OS/161 does not provide name transparency - you have to identify the device/file system along with the name of the file.
No. The functions that do disk I/O are those defined in sfs_io.c - sfs_rblock, sfs_wblock and sfs_rwblock. So, for any use of these functions, you need to consider whether it should go through the buffer cache instead, and make the necessary changes. You will find that many of these uses are the result of code called from sfs_io - particularly the sfs_partialio and sfs_blockio functions. The goal is not to replace the call to sfs_io, but to follow it and see how and why I/O is performed in response to file system operations like sfs_read and sfs_write.