Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-6709

modify rsync utility to copy Lustre file striping

Details

    • Improvement
    • Resolution: Unresolved
    • Minor
    • None
    • None
    • 9223372036854775807

    Description

      Implement support in rsync to copy the lustre.lov xattr (Lustre striping) from the source file and store it on the target file before the file is opened in order to preserve the layout. This should be enabled if the --xattrs option is used.

      This is similar to the work done for the RHEL tar utility to preserve the file layout, which basically removed the filtering of lustre. xattrs and then restored all xattrs at the time the file is created. Note that the lustre.lov and trusted.lov xattrs are aliases for the same xattr, because non-root users cannot access the trusted. xattrs, but this should be opaque to tar.

      Any failure to apply lustre. or trusted. xattrs on the target file should not be considered a fatal error, in case rsync is writing to a non-Lustre filesystem.

      Attachments

        Activity

          [LU-6709] modify rsync utility to copy Lustre file striping

          I'm not against something like retools (which looks interesting), but it seems unlikely to me that changes like that would be accepted into the upstream tools. The tar change was accepted upstream because it didn't really have anything Lustre specific about it - it just changed the restore of xattrs to the start rather than the end.

          Another option that may be beneficial for Lustre in the vein of retools, but is totally generic, is to use fallocate() to have rsync/tar/gzip/bzip2 specify the file size before starting the restore. That would give Lustre a chance to know what the total file size is and make an appropriate striping decision, and then Lustre and all other file systems can preallocate this space on disk to avoid fragmentation.

          adilger Andreas Dilger added a comment - I'm not against something like retools (which looks interesting), but it seems unlikely to me that changes like that would be accepted into the upstream tools. The tar change was accepted upstream because it didn't really have anything Lustre specific about it - it just changed the restore of xattrs to the start rather than the end. Another option that may be beneficial for Lustre in the vein of retools, but is totally generic, is to use fallocate() to have rsync/tar/gzip/bzip2 specify the file size before starting the restore. That would give Lustre a chance to know what the total file size is and make an appropriate striping decision, and then Lustre and all other file systems can preallocate this space on disk to avoid fragmentation.
          rread Robert Read added a comment -

          As Malcolm pointed out recently, kolano published a similar patch for rsync (and a few other common tools) here: http://people.nas.nasa.gov/~kolano/projects/retools.html
          However, instead of copying existing striping information, his approach is to determine appropriate striping for files based on file size, which might be more appropriate for general purpose use.

          rread Robert Read added a comment - As Malcolm pointed out recently, kolano published a similar patch for rsync (and a few other common tools) here: http://people.nas.nasa.gov/~kolano/projects/retools.html However, instead of copying existing striping information, his approach is to determine appropriate striping for files based on file size, which might be more appropriate for general purpose use.

          People

            wc-triage WC Triage
            adilger Andreas Dilger
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated: