-the same file open, you will create a huge synchronization headache
-for yourself if each @struct{file} has its own copy of the inode.
-
-Note that you can store pointers to inodes in @struct{file} if
-you want, and you can store some other small amount of information to
-help you find the inode when you need it.
-
-Similarly, if you want to store one block of data plus some small
-amount of metadata for each of your 64 cache entries, that's fine.
-
-@item
-@b{But why can't we store copies of inodes in @struct{file}? We
-don't understand the answer to the previous question.}
-
-The issue regarding storing @struct{inode}s has to do with
-implementation of the buffer cache. Basically, you can't store a
-@code{struct inode *} in @struct{inode}. Each time you need
-to read a @struct{inode}, you'll have to get it either from the
-buffer cache or from disk.
-
-If you look at @func{file_read_at}, it uses the inode directly
-without having first read in that sector from wherever it was in the
-storage hierarchy. You are no longer allowed to do this. You will
-need to change @code{file_read_at} (and similar functions) so that it
-reads the inode from the storage hierarchy before using it.
+the same file open, you will create a huge synchronization headache for
+yourself if each @struct{inode} has its own copy of the on-disk inode.
+
+You can store pointers to inode data in @struct{inode_disk}, if you
+want, and you can store some other small amount of information to help
+you find the inode when you need it. Similarly, if you want to store
+one block of data plus some small amount of metadata for each of your 64
+cache entries, that's fine.
+
+If you look at @func{file_read_at}, it uses the inode directly without
+having first read in that sector from wherever it was in the storage
+hierarchy. This will no longer work. You will need to change
+@code{file_read_at} (and similar functions) so that it reads the inode
+from the storage hierarchy before using it.