README sync

and typo fix

diff --git a/README b/README
index 0b939bbdbbc2e95b2f383d6a671ea836970b5855..2a67921dcf695d9e68b7a9311cee35e0f2403be9 100644 (file)
--- a/README
+++ b/README
@@ -3858,3 +3858,52 @@ FIXED orphans don't get cleaned up.  It seems a 'create' fails and leaves
           parent
        - if no next block and we are first, parent becomes empty,
           recurse upwards.
+
+12Oct2009
+ - too long, I've forgotten what I was up to..
+   + I've changed the format of indirect blocks to store an address.
+   + I've handled incorporation of an empty block
+   So now internal index blocks can never be empty - they get immediately
+   unlinked if they are.
+   Leaf index blocks can be empty while they have children.  We don't
+   flag them as empty, but rather wait until another child gets incorporated.
+   But I don't think I really like that.  It is an external ugliness based
+   entirely on internal implementation details.  Empty index blocks should
+   not get written out.  We need some way to reliably find an empty index
+   block.  The address won't appear in the parent so a lookup will find the
+   previous block which we cannot link to now as it may not exist yet.
+   Worse - if first index block goes empty, we can only unlink it by moving
+   the parent to start at the next block.  That would make this index block
+   totally unfindable.
+   So I think we have to stick with writing out empty index blocks very
+   rarely.  So we need to be sure they disappear properly.
+   The difficult case is if an index block becomes empty while it has some
+   children which don't end up getting dirtied. e.g. an update aborts.
+   We need to leave the block with enough credits to be written out.
+   I guess the Ncredit should be enough...
+   Maybe worry about that later.
+
+ - what about InoIdx blocks when they become empty?  It would be helpful
+   to flag them so that inode deletion can check....
+   Maybe just set depth to 0..
+
+ ARRGGG... I've completely lost it.  In need another ITO week.
+  I just got a bug in summary.c:71!!
+
+7 Jun 2010
+ - summary.c:71.
+   ablocks_used has hit zero too soon.
+   This should be the count of blocks for which space has been allocated
+   (B_Prealloc is set) but have not been given a phys address yet - at which
+   point the usage count is moved to cblocks_used or pblocks_used.
+   The last block (which may not be the cause of the problem) does not have
+   B_Prealloc set, yet physaddr == 0.
+   The block is 0/1, so the inode for the inode usage map.  This should have
+   physaddr 8 !!
+   We did find 8, then change to 73, but then changed to 0!
+  Ahhh... recent fix exposed a subtle bug ... fixed.
+
+ Now cluster.c:619: [ce9233f8]0/282(0)r2F:Pinned,Phase1,PinPending,CN,CNI,Claimed,PhysValid iblock(1) leaf(1)
+     cluster.c:619: [ce570a18]0/286(0)r2F:Pinned,Phase1,PinPending,SegRef,CN,CNI,Claimed,PhysValid iblock(1) leaf(1)
+   We are allocating an InoIdx block, but data block is not valid??
+

diff --git a/io.c b/io.c
index 7c8310ad9759a5bbb02d1974bf5bb21e7e1f0514..356691a92dfafd94c279a62d6e397e528889f657 100644 (file)
--- a/io.c
+++ b/io.c
@@ -417,7 +417,7 @@ lafs_load_block(struct block *b)
                struct datablock *db = dblk(b);
                if (b->physaddr == 0) {
                        /* block is either in the inode, or
-                        * non-existant (all 'nul').
+                        * non-existent (all 'nul').
                         */
                        struct lafs_inode *lai = LAFSI(b->inode);
                        void *baddr = map_dblock(db);