Put a cap on implications.

Put a cap on implications.

The implication code was causing out of memory problems.

In fs/xfs/xfs_bmap.c there is code like this:

       if (unlikely(XFS_TEST_ERROR(
            (XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_EXTENTS &&
             XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_BTREE &&
             XFS_IFORK_FORMAT(ip, whichfork) != XFS_DINODE_FMT_LOCAL),
             mp, XFS_ERRTAG_BMAPIFORMAT, XFS_RANDOM_BMAPIFORMAT))) {
                XFS_ERROR_REPORT("xfs_bmapi", XFS_ERRLEVEL_LOW, mp);
                return XFS_ERROR(EFSCORRUPTED);
        }

We merge ip and whichfork like a zillion times and get these huge sm_state
trees.  It's very difficult to handle with the current algorithm.

Now the code bails out instead of trying to calculate really complicated
implications.

Bailing out in this limited way is Ok.  Implications theoretically don't
uncover bugs, they just get rid of false positives.  Probably that code
didn't have any false positives anyway so we're hanging there trying to
get rid of something that wasn't a problem.

I tested 10000 and 5000 on xfs_bmap.c.  5000 is faster obviously.  There
didn't seem like any advantage of going with 10000.

Signed-off-by: Dan Carpenter <error27@gmail.com>