Details

    • New Feature
    • Resolution: Won't Fix
    • Minor
    • None
    • Lustre 2.6.0
    • 9223372036854775807

    Description

      DL-SNAP is a feature designed for directory level file backups.

      It is implemented on top of lustre ldiskfs without modification of ext4 disk format, though we set a special original flag to FEATURE of the superblock in order to check whether DL-SNAP is enabled.

      The feature makes execution of e2fsck command failed although no modification to ext2 file system structure.

       

      DL-SNAP uses COW(Copy On Write) mechanism to reduce backup time and storage usage.  When we create a snapshot, only inodes are created. At this point, new data blocks are not allocated on OST.  Data blocks of snapshot are allocated when original file is modified.

       

      Not only root users but also ordinary users can create snapshots. Users can create a snapshot of a directory using lfs command with snapshot option, and restore files by usual process such as cp command.

       

      For more information, please check the presentation at LUG2016.

      Attachments

        Activity

          [LU-11512] DL-SNAP: Directory Level Snapshot

          HAS_SNAPSHOT feature has been being reserved too long without the feature implementation.  adilger guarded the flag in EXT4 today, but at some moment without any progress, the flag can be excluded.

          artem_blagodarenko Artem Blagodarenko (Inactive) added a comment - HAS_SNAPSHOT feature has been being reserved too long without the feature implementation.   adilger guarded the flag in EXT4 today, but at some moment without any progress, the flag can be excluded.

          Hello Wang and Li

          DL-SNAP can create snapshot files recursivly for subdirectory.
          It scans files under the target directory and sends snapshot creation requests correspond to the original files(for the number of files times).

          takamura Tatsushi Takamura added a comment - Hello Wang and Li DL-SNAP can create snapshot files recursivly for subdirectory. It scans files under the target directory and sends snapshot creation requests correspond to the original files(for the number of files times).

          Thank you very much for teaching me in great detail, Andreas.
          We think DL_SNAP patch is difficut to be merged into Ext4 mainline, because it don't work as a stand-alone.
          But, could you please look at this patch if that is okay. If you need design documentations still, we will send you.

          takamura Tatsushi Takamura added a comment - Thank you very much for teaching me in great detail, Andreas. We think DL_SNAP patch is difficut to be merged into Ext4 mainline, because it don't work as a stand-alone. But, could you please look at this patch if that is okay. If you need design documentations still, we will send you.

          Tatsushi-san, it is not impossible to get changes included into the upstream ext4, but it takes time, effort, and coordination to do so. It is unfortunate that this patch is already several years old, as we could have used that time to discuss such changes with the upstream ext4 maintainers (of which I am one) and work to include the changes into the upstream ext4 code over that time. Maybe the changes could have already been in the upstream kernel (even RHEL or SLES distro kernels), as was done with project quotas, large xattrs, and large directory support.

          The patches under lustre/kernel_patches/patches are for the Lustre server kernel. While we do allow patches to be included there, they cannot be required patches, only optional patches (eg. to improve performance or to backport fixes and features from upstream kernels). We have moved away from adding features only to the Lustre kernel, since this adds maintenance burden for each new kernel added, and makes it difficult for users to update their kernels. The current Lustre server can build and run without any server patches, though an ldiskfs patch series is still needed for each kernel, but not if ZFS is used.

          I will take a look at the DL Snap changes when I have a chance, and see whether they are acceptable to be submitted upstream for ext4. At a minimum, they would need to be updated to the latest kernel, but there may be other changes needed in order to make them compatible with newer features.

          adilger Andreas Dilger added a comment - Tatsushi-san, it is not impossible to get changes included into the upstream ext4, but it takes time, effort, and coordination to do so. It is unfortunate that this patch is already several years old, as we could have used that time to discuss such changes with the upstream ext4 maintainers (of which I am one) and work to include the changes into the upstream ext4 code over that time. Maybe the changes could have already been in the upstream kernel (even RHEL or SLES distro kernels), as was done with project quotas, large xattrs, and large directory support. The patches under lustre/kernel_patches/patches are for the Lustre server kernel. While we do allow patches to be included there, they cannot be required patches, only optional patches (eg. to improve performance or to backport fixes and features from upstream kernels). We have moved away from adding features only to the Lustre kernel, since this adds maintenance burden for each new kernel added, and makes it difficult for users to update their kernels. The current Lustre server can build and run without any server patches, though an ldiskfs patch series is still needed for each kernel, but not if ZFS is used. I will take a look at the DL Snap changes when I have a chance, and see whether they are acceptable to be submitted upstream for ext4. At a minimum, they would need to be updated to the latest kernel, but there may be other changes needed in order to make them compatible with newer features.

          We didn't understand that adding original code to ldiskfs is not acceptable, because there are some patches(lustre/kernel_patches/patches/) modifying original kernel source.
          This DL-SNAP code is impossible to be merged into Ext4 mainline and it is impossible to realize DL-SNAP feature without adding code to ldiskfs.
          So we think it is impossible to be merged into lustre.

          For future reference, could you tell us the rules(which sources are acceptable or not to modify), difference in contents or polices of "ldiskfs/kernel_patches/patches/" and "lustre/kernel_patches/patches/".
          For example, can we create patches(not merged in mainline) which modify kernel code in "lustre/kernel_patches/patches/"?

          takamura Tatsushi Takamura added a comment - We didn't understand that adding original code to ldiskfs is not acceptable, because there are some patches(lustre/kernel_patches/patches/) modifying original kernel source. This DL-SNAP code is impossible to be merged into Ext4 mainline and it is impossible to realize DL-SNAP feature without adding code to ldiskfs. So we think it is impossible to be merged into lustre. For future reference, could you tell us the rules(which sources are acceptable or not to modify), difference in contents or polices of "ldiskfs/kernel_patches/patches/" and "lustre/kernel_patches/patches/". For example, can we create patches(not merged in mainline) which modify kernel code in "lustre/kernel_patches/patches/"?
          lixi_wc Li Xi added a comment -

          I've been looking into the Ext4 patch a little bit. Please correct me if I am wrong Tatsushi-san, but I think on Ext4 level, recurisve subdirectory snapshot is not supported. It might be implemented on Lustre level? I have a feeling that data on MDT might causes some difficulty for this snapshot implementation.

          lixi_wc Li Xi added a comment - I've been looking into the Ext4 patch a little bit. Please correct me if I am wrong Tatsushi-san, but I think on Ext4 level, recurisve subdirectory snapshot is not supported. It might be implemented on Lustre level? I have a feeling that data on MDT might causes some difficulty for this snapshot implementation.

          Thank you for contributing the patch. Is there any kind of design documentation or description that was written before or during development? Even if it is in Japanese, we can try machine translation to try and understand the implementation better.

          adilger Andreas Dilger added a comment - Thank you for contributing the patch. Is there any kind of design documentation or description that was written before or during development? Even if it is in Japanese, we can try machine translation to try and understand the implementation better.

          Still not look into the detailed codes, but from PPT, a quick question:

          Is DL-SNAP recursive for sub dir?

          wshilong Wang Shilong (Inactive) added a comment - Still not look into the detailed codes, but from PPT, a quick question: Is DL-SNAP recursive for sub dir?

          Tatsushi Takamura (takamr.tatsushi@jp.fujitsu.com) uploaded a new patch: https://review.whamcloud.com/33555
          Subject: LU-11512 ldiskfs: DL-SNAP Directory Level Snapshot
          Project: fs/lustre-release
          Branch: b2_6
          Current Patch Set: 1
          Commit: 303f237c5e116ac271f03db3cc1a3aeb2568b7f0

          gerrit Gerrit Updater added a comment - Tatsushi Takamura (takamr.tatsushi@jp.fujitsu.com) uploaded a new patch: https://review.whamcloud.com/33555 Subject: LU-11512 ldiskfs: DL-SNAP Directory Level Snapshot Project: fs/lustre-release Branch: b2_6 Current Patch Set: 1 Commit: 303f237c5e116ac271f03db3cc1a3aeb2568b7f0

          Sorry for the late reply. I have attached dl_snapshot patch to this ticket.

          dl_snapshot.patch

          takamura Tatsushi Takamura added a comment - Sorry for the late reply. I have attached dl_snapshot patch to this ticket. dl_snapshot.patch

          People

            takamura Tatsushi Takamura
            takamura Tatsushi Takamura
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: