From 553ea4c4cb4a50a609ab826b361800c8a5532ec5 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Fri, 10 Dec 2004 07:29:22 +0000 Subject: [PATCH] Clarifications. --- doc/filesys.texi | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/filesys.texi b/doc/filesys.texi index 767cfa3..4d66391 100644 --- a/doc/filesys.texi +++ b/doc/filesys.texi @@ -92,7 +92,7 @@ prepared for interactions with all previous parts (as usual). The provided file system requires external synchronization, that is, callers must ensure that only one thread can be running in the file -system code at once. Your submission should use a more finely granular +system code at once. Your submission should use a finer-grained synchronization strategy. You will need to consider synchronization issues for each type of file system object. The provided code uses the following strategies: @@ -481,6 +481,9 @@ 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 @code{length} or @code{sector_cnt} members. +You can keep a cached copy of the free map in memory permanently if you +like. It doesn't have to count against the cache size. + 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 -- 2.30.2