def check(monitor, verify=False, add_lease=False):
    """Check up on my health, optionally repairing any problems.

        This returns a Deferred that fires with an instance that provides
        ICheckResults, or None if the object is non-distributed (i.e. LIT
        files).

        The monitor will be checked periodically to see if the operation has
        been cancelled. If so, no new queries will be sent, and the Deferred
        will fire (with a OperationCancelledError) immediately.

        Filenodes and dirnodes (which provide IFilesystemNode) are also
        checkable. Instances that represent verifier-caps will be checkable
        but not downloadable. Some objects (like LIT files) do not actually
        live in the grid, and their checkers return None (non-distributed
        files are always healthy).

        If verify=False, a relatively lightweight check will be performed: I
        will ask all servers if they have a share for me, and I will believe
        whatever they say. If there are at least N distinct shares on the
        grid, my results will indicate r.is_healthy()==True. This requires a
        roundtrip to each server, but does not transfer very much data, so
        the network bandwidth is fairly low.

        If verify=True, a more resource-intensive check will be performed:
        every share will be downloaded, and the hashes will be validated on
        every bit. I will ignore any shares that failed their hash checks. If
        there are at least N distinct valid shares on the grid, my results
        will indicate r.is_healthy()==True. This requires N/k times as much
        download bandwidth (and server disk IO) as a regular download. If a
        storage server is holding a corrupt share, or is experiencing memory
        failures during retrieval, or is malicious or buggy, then
        verification will detect the problem, but checking will not.

        If add_lease=True, I will ensure that an up-to-date lease is present
        on each share. The lease secrets will be derived from by node secret
        (in BASEDIR/private/secret), so either I will add a new lease to the
        share, or I will merely renew the lease that I already had. In a
        future version of the storage-server protocol (once Accounting has
        been implemented), there may be additional options here to define the
        kind of lease that is obtained (which account number to claim, etc).

        TODO: any problems seen during checking will be reported to the
        health-manager.furl, a centralized object that is responsible for
        figuring out why files are unhealthy so corrective action can be
        taken.
        """
