From: NeilBrown Date: Mon, 7 Jun 2010 03:23:59 +0000 (+1000) Subject: README sync X-Git-Url: http://git.neil.brown.name/?a=commitdiff_plain;h=f67aeb3909c6fd07ca231e3c94d6b0427da670f6;p=LaFS.git README sync and typo fix --- diff --git a/README b/README index 0b939bb..2a67921 100644 --- 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 7c8310a..356691a 100644 --- 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);