Skip to content
  • Alex Elder's avatar
    rbd: don't create sysfs entries for non-mapped snapshots · 3e83b65b
    Alex Elder authored
    When an rbd image gets mapped a device entry gets created for it
    under /sys/bus/rbd/devices/<id>/.  Inside that directory there are
    sysfs files that contain information about the image: its size,
    feature bits, major device number, and so on.
    
    Additionally, if that image has any snapshots, a device entry gets
    created for each of those as a "child" of the mapped device.  Each
    of these is a subdirectory of the mapped device, and each directory
    contains a few files with information about the snapshot (its
    snapshot id, size, and feature mask).
    
    There is no clear benefit to having those device entries for the
    snapshots.  The information provided via sysfs of of little real
    value--and all of it is available via rbd CLI commands.  If we
    still wanted to see the kernel's view of this information it could
    be done much more simply by including it in a single sysfs file for
    the mapped image.
    
    But there *is* a clear cost to supporting them.  Every time a snapshot
    context changes, these entries need to be updated (deleted snapshots
    removed, new snapshots created).  The rbd driver is notified of
    changes to the snapshot context via callbacks from an osd, and care
    must be taken to coordinate removal of snapshot data structures
    with the possibility of one these notifications occurring.
    
    Things would be considerably simpler if we just didn't have to
    maintain device entries for the snapshots.
    
    So get rid of them.
    
    The ability to map a snapshot of an rbd image will remain; the only
    thing lost will be the ability to query these sysfs directories for
    information about snapshots of mapped images.
    
    This resolves:
        http://tracker.ceph.com/issues/4796
    
    
    
    Signed-off-by: default avatarAlex Elder <elder@inktank.com>
    Reviewed-by: default avatarJosh Durgin <josh.durgin@inktank.com>
    3e83b65b