add_block_address: be careful with physaddr == 0

An address of '0' is not consecutive with and address of '1' and while
it is very unlikely to ever be a problem, make sure we don't try to
combine those addresses into a range in the uninc table.

Also remove a comment about a possible problem that doesn't seem to be
a real problem.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/index.c b/index.c
index d5adfe788780d1bba6b76df0d7ad35906aa26339..d1c40978d979075105fa471aaabe74445bc8671b 100644 (file)
--- a/index.c
+++ b/index.c
@@ -2016,6 +2016,7 @@ int lafs_add_block_address(struct fs *fs, struct block *blk)
                [p->uninc_table.pending_cnt-1];
        if (p->uninc_table.pending_cnt >= 1 &&
            a->fileaddr+a->cnt == blk->fileaddr &&
+           a->physaddr != 0 &&
            a->physaddr+a->cnt == blk->physaddr) {
                a->cnt++;
                if (test_and_clear_bit(B_UnincCredit, &blk->flags))
@@ -2165,11 +2166,7 @@ int lafs_allocated_block(struct fs *fs, struct block *blk, u64 phys)
                         */
                        return 0;
                getref(blk, MKREF(uninc));
-               /* FIXME if this block is beyond EOF, we might be about
-                * to invalidate it, so putting it on a list is a bad
-                * idea.  We can just *know* that beyond EOF is
-                * truncated and not store the block.... maybe??
-                */
+
                spin_lock(&blk->inode->i_data.private_lock);
                blk->chain = p->uninc_next;
                p->uninc_next = blk;