README update

diff --git a/README b/README
index 7d7254162b516d204d4ac37d4977ed4360ab473b..84bad535cd7ee5793a129751797c74857ff9119a 100644 (file)
--- a/README
+++ b/README
@@ -2059,3 +2059,27 @@ kernel BUG at /home/neilb/work/nfsbrick/fs/module/segments.c:371!
   FIXME  When we sync a small file, we just write out the inode.
      rollforward currently ignores data in inodes I think.
      Thanks needs to be fixed to ensure this data is safe.
+
+ - stop iblock from disappearing so much.
+
+ - I think...
+    While cleaning a file, I truncate it.  This makes it appear
+    to fit in the inode but it is very big and we get confused.
+   We cannot allocate block 0 until all the others have been
+   allocated to 0 and forgotten.
+   But what if we truncate a file to 10 bytes, then fsync?
+    We need to write the data promptly, but we like doing truncate
+    in the background.
+   When we extend a file we already need to wait for truncation
+    to complete (FIXME do we do that?)  We could wait on fsync too.
+   We cannot just delay block0 as it might be part of a checkpoint
+    that has to complete promptly while truncation can take a long time.
+   i.e. we have a very large file.  We update the first byte, then
+    truncate to 2 bytes.... we don't need to write until fsync which will wait...
+    Directory?? delete lots of entries so it shrinks to one block?
+       There is no delayed truncate there.
+   ?? Never clean an I_Trunc file.  
+   If we try to allocate a file with other indexes:
+     clear Realloc
+     if Dirty and Pinned, just do normal alloc
+     if Dirty and not pinned, skip.