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

not include the .lustre directory in readdir output

Details

    • Bug
    • Resolution: Fixed
    • Major
    • Lustre 2.7.0, Lustre 2.5.4
    • Lustre 2.6.0
    • None
    • 3
    • 13937

    Description

      Comments from Andreas

      "I noticed that ".lustre" now appears in "ls -a" output, but I don't think that is supposed to happen. It might have been added when .lustre was created as a real inode in 2.4 or so?

      This causes a problem because backup and other filesystem scanning tools will want to go into .lustre and read all the files there, and may also want to restore them after a crash, which could cause problems.

      I think readdir needs to be fixed to not include the .lustre directory in readdir output. "

      Attachments

        Issue Links

          Activity

            [LU-5044] not include the .lustre directory in readdir output

            Patch landed to Master.

            jlevi Jodi Levi (Inactive) added a comment - Patch landed to Master.

            I'd like to land the 11186 patch to b2_5 so that we can fix LU-5955 on the client.

            adilger Andreas Dilger added a comment - I'd like to land the 11186 patch to b2_5 so that we can fix LU-5955 on the client.
            jhammond John Hammond added a comment - See also http://review.whamcloud.com/#/c/11186/ .
            rread Robert Read added a comment -

            >Is this really a problem? Shouldn't we wait for some sign that this is causing an issue for some real program before we go adding special cases?

            I suppose it means backup and recursive copy tools need to be configured to skip it, but other filesystems have similar "magic" directories that shouldn't be copied, so it's not that odd. I agree it would be simpler to leave it alone.

            rread Robert Read added a comment - >Is this really a problem? Shouldn't we wait for some sign that this is causing an issue for some real program before we go adding special cases? I suppose it means backup and recursive copy tools need to be configured to skip it, but other filesystems have similar "magic" directories that shouldn't be copied, so it's not that odd. I agree it would be simpler to leave it alone.
            jhammond John Hammond added a comment -

            Is this really a problem? Shouldn't we wait for some sign that this is causing an issue for some real program before we go adding special cases?

            jhammond John Hammond added a comment - Is this really a problem? Shouldn't we wait for some sign that this is causing an issue for some real program before we go adding special cases?
            rread Robert Read added a comment -

            It would be good to include tests (if we don't have them already) that other uses of .lustre, such as open by fid from userspace, still work as well.

            rread Robert Read added a comment - It would be good to include tests (if we don't have them already) that other uses of .lustre, such as open by fid from userspace, still work as well.
            di.wang Di Wang added a comment - http://review.whamcloud.com/10286

            Currently, .lustre/lost+found is used for LFSCK, if we want to make .lustre to be invisible for readdir, then we need some especial tools to read the .lustre, then the administrator can check the orphans under .lustre/lost+found.

            yong.fan nasf (Inactive) added a comment - Currently, .lustre/lost+found is used for LFSCK, if we want to make .lustre to be invisible for readdir, then we need some especial tools to read the .lustre, then the administrator can check the orphans under .lustre/lost+found.

            People

              di.wang Di Wang
              di.wang Di Wang
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: