The File Server Remote VSS Protocol (FSRVP) was recently defined by Microsoft. It allows for SMB clients to remotely request the creation, exposure and destruction of share snapshots.

Aside from support in Windows Server 2012, preliminary FSRVP server support has also been implemented for Samba.

FSRVP client support in cifs.ko would allow for Btrfs style snapshot behaviour on SMB filesystem mount-points, e.g:

cifs filesystem snapshot create /mnt/win2k12share /mnt/win2k12share/my_snapshot

  • user-space cifs binary issues BTRFSIOCSNAP_CREATE style ioctl to kernel
  • kernel connects to the FssagentRpc SMB named pipe
  • kernel dispatches FSRVP requests to create and expose a snapshot of win2k12_share
  • kernel mounts the newly exposed snapshot share under /mnt/win2k12share/mysnapshot
  • user-space stores corresponding shadow-copy GUIDs

cifs filesystem snapshot delete /mnt/win2k12share/mysnapshot

  • user-space retrieves corresponding shadow-copy GUIDs for my_snapshot
  • kernel unmounts my_snapshot
  • kernel dispatches FSRVP requests to destroy the snapshot
  • user-space removes the corresponding shadow-copy GUIDs

Note: There are a bunch of underscores in the above text that have been unintentionally marked-up, see source.

Looking for hackers with the skills:

cifs smb snapshot snapper

This project is part of:

Hack Week 10

Activity

  • about 11 years ago: dmdiss left this project.
  • about 11 years ago: lmuelle liked this project.
  • about 11 years ago: dmdiss started this project.
  • about 11 years ago: dmdiss added keyword "cifs" to this project.
  • about 11 years ago: dmdiss added keyword "smb" to this project.
  • about 11 years ago: dmdiss added keyword "snapshot" to this project.
  • about 11 years ago: dmdiss added keyword "snapper" to this project.
  • about 11 years ago: dmdiss originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

    Creator:
    Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
    Members:
    Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

    Description

    Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

    Goals

    Primary

    Start phasing out/deprecation of older SMB versions

    Secondary

    • Clean up of the code (with focus on the newer versions)
    • Update cifs-utils
    • Update documentation
    • Improve backport workflow (see below)

    Technical details

    Ideas for the implementation.

    • fs/smb/client/{old,new}.c to generate the respective modules
      • Maybe don't create separate folders? (re-evaluate as things progresses!)
    • Remove server->{ops,vals} if possible
    • Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
    • Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
    • Restructure multichannel
      • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
      • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
    • Authentication mechanisms
      • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.


    Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

    Creator:
    Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
    Members:
    Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

    Description

    Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

    Goals

    Primary

    Start phasing out/deprecation of older SMB versions

    Secondary

    • Clean up of the code (with focus on the newer versions)
    • Update cifs-utils
    • Update documentation
    • Improve backport workflow (see below)

    Technical details

    Ideas for the implementation.

    • fs/smb/client/{old,new}.c to generate the respective modules
      • Maybe don't create separate folders? (re-evaluate as things progresses!)
    • Remove server->{ops,vals} if possible
    • Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
    • Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
    • Restructure multichannel
      • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
      • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
    • Authentication mechanisms
      • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.