Eric Lee / smarc-fsl-linux-kernel

11 Mar, 2016

2 commits

10 Dec, 2015

3 commits

  • 086fbbbda   dm thin metadata: make dm_thin_find_mapped_range() atomic ... Browse Code »

    Refactor dm_thin_find_mapped_range() so that it takes the read lock on
    the metadata's lock; rather than relying on finer grained locking that
    is pushed down inside dm_thin_find_next_mapped_block() and
    dm_thin_find_block().

    Signed-off-by: Joe Thornber
    Signed-off-by: Mike Snitzer

    Joe Thornber
     
  • 3d5f67332   dm thin metadata: speed up discard of partially mapped volumes ... Browse Code »

    Use dm_btree_lookup_next() to more quickly discard partially mapped
    volumes.

    Signed-off-by: Joe Thornber
    Signed-off-by: Mike Snitzer

    Joe Thornber
     
  • 49e99fc71   dm thin metadata: fix bug when taking a metadata snapshot ... Browse Code »

    When you take a metadata snapshot the btree roots for the mapping and
    details tree need to have their reference counts incremented so they
    persist for the lifetime of the metadata snap.

    The roots being incremented were those currently written in the
    superblock, which could possibly be out of date if concurrent IO is
    triggering new mappings, breaking of sharing, etc.

    Fix this by performing a commit with the metadata lock held while taking
    a metadata snapshot.

    Signed-off-by: Joe Thornber
    Signed-off-by: Mike Snitzer
    Cc: stable@vger.kernel.org

    Joe Thornber
     

03 Dec, 2015

1 commit

  • 993ceab91   dm thin metadata: fix bug in dm_thin_remove_range() ... Browse Code »

    dm_btree_remove_leaves() only unmaps a contiguous region so we need a
    loop, in __remove_range(), to handle ranges that contain multiple
    regions.

    A new btree function, dm_btree_lookup_next(), is introduced which is
    more efficiently able to skip over regions of the thin device which
    aren't mapped. __remove_range() uses dm_btree_lookup_next() for each
    iteration of __remove_range()'s loop.

    Also, improve description of dm_btree_remove_leaves().

    Fixes: 6550f075 ("dm thin metadata: add dm_thin_remove_range()")
    Signed-off-by: Joe Thornber
    Signed-off-by: Mike Snitzer
    Cc: stable@vger.kernel.org # 4.1+

    Joe Thornber
     

01 Nov, 2015

1 commit

12 Aug, 2015

1 commit

12 Jun, 2015

3 commits

30 May, 2015

1 commit

10 Feb, 2015

1 commit

11 Nov, 2014

2 commits

16 Jul, 2014

1 commit

  • 9aec8629e   dm thin metadata: do not allow the data block size to change ... Browse Code »

    The block size for the thin-pool's data device must remained fixed for
    the life of the thin-pool. Disallow any attempt to change the
    thin-pool's data block size.

    It should be noted that attempting to change the data block size via
    thin-pool table reload will be ignored as a side-effect of the thin-pool
    handover that the thin-pool target does during thin-pool table reload.

    Here is an example outcome of attempting to load a thin-pool table that
    reduced the thin-pool's data block size from 1024K to 512K.

    Before:
    kernel: device-mapper: thin: 253:4: growing the data device from 204800 to 409600 blocks

    After:
    kernel: device-mapper: thin metadata: changing the data block size (from 2048 to 1024) is not supported
    kernel: device-mapper: table: 253:4: thin-pool: Error creating metadata object
    kernel: device-mapper: ioctl: error adding target to table

    Signed-off-by: Mike Snitzer
    Acked-by: Joe Thornber
    Cc: stable@vger.kernel.org

    Mike Snitzer
     

28 Mar, 2014

1 commit

06 Mar, 2014

1 commit

  • 07f2b6e03   dm thin: ensure user takes action to validate data and metadata consistency ... Browse Code »

    If a thin metadata operation fails the current transaction will abort,
    whereby causing potential for IO layers up the stack (e.g. filesystems)
    to have data loss. As such, set THIN_METADATA_NEEDS_CHECK_FLAG in the
    thin metadata's superblock which:
    1) requires the user verify the thin metadata is consistent (e.g. use
    thin_check, etc)
    2) suggests the user verify the thin data is consistent (e.g. use fsck)

    The only way to clear the superblock's THIN_METADATA_NEEDS_CHECK_FLAG is
    to run thin_repair.

    On metadata operation failure: abort current metadata transaction, set
    pool in read-only mode, and now set the needs_check flag.

    As part of this change, constraints are introduced or relaxed:
    * don't allow a pool to transition to write mode if needs_check is set
    * don't allow data or metadata space to be resized if needs_check is set
    * if a thin pool's metadata space is exhausted: the kernel will now
    force the user to take the pool offline for repair before the kernel
    will allow the metadata space to be extended.

    Also, update Documentation to include information about when the thin
    provisioning target commits metadata, how it handles metadata failures
    and running out of space.

    Signed-off-by: Mike Snitzer
    Signed-off-by: Joe Thornber

    Mike Snitzer
     

28 Feb, 2014

1 commit

  • 7d48935ef   dm thin: allow metadata space larger than supported to go unused ... Browse Code »

    It was always intended that a user could provide a thin metadata device
    that is larger than the max supported by the on-disk format. The extra
    space would just go unused.

    Unfortunately that never worked. If the user attempted to use a larger
    metadata device on creation they would get an error like the following:

    device-mapper: space map common: space map too large
    device-mapper: transaction manager: couldn't create metadata space map
    device-mapper: thin metadata: tm_create_with_sm failed
    device-mapper: table: 252:17: thin-pool: Error creating metadata object
    device-mapper: ioctl: error adding target to table

    Fix this by allowing the initial metadata space map creation to cap its
    size at the max number of blocks supported (DM_SM_METADATA_MAX_BLOCKS).
    get_metadata_dev_size() must also impose DM_SM_METADATA_MAX_BLOCKS (via
    THIN_METADATA_MAX_SECTORS), otherwise extending metadata would cap at
    THIN_METADATA_MAX_SECTORS_WARNING (which is larger than supported).

    Also, the calculation for THIN_METADATA_MAX_SECTORS didn't account for
    the sizeof the disk_bitmap_header. So the supported maximum metadata
    size is a bit smaller (reduced from 33423360 to 33292800 sectors).

    Lastly, remove the "excess space will not be used" warning message from
    get_metadata_dev_size(); it resulted in printing the warning multiple
    times. Factor out warn_if_metadata_device_too_big(), call it from
    pool_ctr() and maybe_resize_metadata_dev().

    Signed-off-by: Mike Snitzer
    Acked-by: Joe Thornber

    Mike Snitzer
     

18 Feb, 2014

1 commit

  • 4d1662a30   dm thin: avoid metadata commit if a pool's thin devices haven't changed ... Browse Code »

    Commit 905e51b ("dm thin: commit outstanding data every second")
    introduced a periodic commit. This commit occurs regardless of whether
    any thin devices have made changes.

    Fix the periodic commit to check if any of a pool's thin devices have
    changed using dm_pool_changed_this_transaction().

    Reported-by: Alexander Larsson
    Signed-off-by: Mike Snitzer
    Acked-by: Joe Thornber
    Cc: stable@vger.kernel.org

    Mike Snitzer
     

07 Jan, 2014

1 commit

  • 19fa1a675   dm thin: fix discard support to a previously shared block ... Browse Code »

    If a snapshot is created and later deleted the origin dm_thin_device's
    snapshotted_time will have been updated to reflect the snapshot's
    creation time. The 'shared' flag in the dm_thin_lookup_result struct
    returned from dm_thin_find_block() is an approximation based on
    snapshotted_time -- this is done to avoid 0(n), or worse, time
    complexity. In this case, the shared flag would be true.

    But because the 'shared' flag reflects an approximation a block can be
    incorrectly assumed to be shared (e.g. false positive for 'shared'
    because the snapshot no longer exists). This could result in discards
    issued to a thin device not being passed down to the pool's underlying
    data device.

    To fix this we double check that a thin block is really still in-use
    after a mapping is removed using dm_pool_block_is_used(). If the
    reference count for a block is now zero the discard is allowed to be
    passed down.

    Also add a 'definitely_not_shared' member to the dm_thin_new_mapping
    structure -- reflects that the 'shared' flag in the response from
    dm_thin_find_block() can only be held as definitive if false is
    returned.

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

    Signed-off-by: Joe Thornber
    Signed-off-by: Mike Snitzer
    Cc: stable@vger.kernel.org

    Joe Thornber
     

11 Dec, 2013

1 commit

  • 9b7aaa64f   dm thin: allow pool in read-only mode to transition to read-write mode ... Browse Code »

    A thin-pool may be in read-only mode because the pool's data or metadata
    space was exhausted. To allow for recovery, by adding more space to the
    pool, we must allow a pool to transition from PM_READ_ONLY to PM_WRITE
    mode. Otherwise, running out of space will render the pool permanently
    read-only.

    Signed-off-by: Joe Thornber
    Signed-off-by: Mike Snitzer
    Cc: stable@vger.kernel.org

    Joe Thornber
     

10 May, 2013

3 commits

02 Mar, 2013

1 commit

22 Dec, 2012

1 commit

  • e3cbf9451   dm persistent data: fix nested btree deletion ... Browse Code »

    When deleting nested btrees, the code forgets to delete the innermost
    btree. The thin-metadata code serendipitously compensates for this by
    claiming there is one extra layer in the tree.

    This patch corrects both problems.

    Signed-off-by: Joe Thornber
    Signed-off-by: Alasdair G Kergon

    Joe Thornber
     

27 Jul, 2012

13 commits