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

lfs find --printf fails on FIFOs and special files

Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.16.0
    • None
    • None
    • 3
    • 9223372036854775807

    Description

      $ mkfifo myfifo
$ lfs find myfifo
myfifo 
$ lfs find myfifo --printf "%p\n"
** command hangs **
^C

$ sudo mknod mychardev c 1 5
$ lfs find mychardev
mychardev
$ lfs find mychardev --printf "%p\n"
lfs: failed for 'mychardev': Inappropriate ioctl for device

      Attachments

        Issue Links

          is related to

          New Feature - A new feature of the product, which has yet to be developed. LU-11872 Request for option not to follow symlink when setting project ID

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Improvement - An improvement or enhancement to an existing feature or task. LU-18889 "lfs find -printf" optimization

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Improvement - An improvement or enhancement to an existing feature or task. LU-15837 "lfs find -printf" improvements

          • Major - Major loss of function.
          • Resolved

          Activity

            [LU-16808] lfs find --printf fails on FIFOs and special files
            pjones Peter Jones added a comment -

            Landed for 2.16

            pjones Peter Jones added a comment - Landed for 2.16
            gerrit Gerrit Updater added a comment -

            "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50916/
            Subject: LU-16808 lfs: return invalid=-1 if no projid retrieved
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: 8d09b3e77744973d10d2029028d7e6f14591bc6d

            gerrit Gerrit Updater added a comment - "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50916/ Subject: LU-16808 lfs: return invalid=-1 if no projid retrieved Project: fs/lustre-release Branch: master Current Patch Set: Commit: 8d09b3e77744973d10d2029028d7e6f14591bc6d
            gerrit Gerrit Updater added a comment -

            "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50905/
            Subject: LU-16808 lfs: lfs find --printf won't hang on special files
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: f47f816a5b1deabc1d501332a1a30af205d22515

            gerrit Gerrit Updater added a comment - "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50905/ Subject: LU-16808 lfs: lfs find --printf won't hang on special files Project: fs/lustre-release Branch: master Current Patch Set: Commit: f47f816a5b1deabc1d501332a1a30af205d22515
            adilger Andreas Dilger added a comment -

            Getting the projid on the symlink target is intentional behavior (LU-11872).

            adilger Andreas Dilger added a comment - Getting the projid on the symlink target is intentional behavior ( LU-11872 ).
            bertschinger Thomas Bertschinger added a comment -

            I noticed another (potential) issue with symlinks and the project ID. For most attributes it appears lfs find uses data from the symlink itself, but for project ID, lfs find seems to use the value from the target:

            $ touch file20 && lfs project -p 20 file20
$ ln -s file20 link21 && lfs project -p 21 link21

$ lfs project .
   20 - ./file20
   21 - ./link21

# including %s in the format string to demonstrate that lfs find uses values from the link itself (and not the target) for attributes other than project id
$ lfs find . --printf "%p %s %LP\n"
. 4096 0
./file20 0 20
./link21 6 20

            Would we expect that lfs find would use the value from the link in this case?

            Interestingly, I ran a quick test on ext4 and found that (at least in my setup) projid on symlinks did not work:

            ext4-mount $ touch file20 && chattr -p 20 file20
ext4-mount $ ln -s file20 link21
 
ext4-mount $ chattr -p 21 link21
chattr: Operation not supported while reading flags on link21

ext4-mount $ lsattr -p .
    0 --------------e------- ./lost+found
lsattr: Operation not supported While reading flags on ./link21
   20 --------------e------- ./file20

            I am not sure what the "expected" behavior of projid and symlinks is so I don't know if the lfs find behavior above is problematic.

            @adilger any thoughts on this? If the current behavior is wrong should I submit a ticket for this?

            bertschinger Thomas Bertschinger added a comment - I noticed another (potential) issue with symlinks and the project ID. For most attributes it appears lfs find uses data from the symlink itself, but for project ID, lfs find seems to use the value from the target: $ touch file20 && lfs project -p 20 file20 $ ln -s file20 link21 && lfs project -p 21 link21 $ lfs project .    20 - ./file20    21 - ./link21 # including %s in the format string to demonstrate that lfs find uses values from the link itself (and not the target) for attributes other than project id $ lfs find . --printf "%p %s %LP\n" . 4096 0 ./file20 0 20 ./link21 6 20 Would we expect that lfs find would use the value from the link in this case? Interestingly, I ran a quick test on ext4 and found that (at least in my setup) projid on symlinks did not work: ext4-mount $ touch file20 && chattr -p 20 file20 ext4-mount $ ln -s file20 link21 ext4-mount $ chattr -p 21 link21 chattr: Operation not supported while reading flags on link21 ext4-mount $ lsattr -p .     0 --------------e------- ./lost+found lsattr: Operation not supported While reading flags on ./link21    20 --------------e------- ./file20 I am not sure what the "expected" behavior of projid and symlinks is so I don't know if the lfs find behavior above is problematic. @adilger any thoughts on this? If the current behavior is wrong should I submit a ticket for this?
            gerrit Gerrit Updater added a comment -

            "Zhenyu Xu <bobijam@hotmail.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50916
            Subject: LU-16808 lfs: return error if projid cannot be retrieved
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 37871eccbaafe1e2b7a07dd74070ef7ba2d40751

            gerrit Gerrit Updater added a comment - "Zhenyu Xu <bobijam@hotmail.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50916 Subject: LU-16808 lfs: return error if projid cannot be retrieved Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 37871eccbaafe1e2b7a07dd74070ef7ba2d40751
            gerrit Gerrit Updater added a comment -

            "Zhenyu Xu <bobijam@hotmail.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50905
            Subject: LU-16808 lfs: lfs find --printf won't hang on special files
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 935a7716d744d2c2009a363f0b1bdbaee84d0895

            gerrit Gerrit Updater added a comment - "Zhenyu Xu <bobijam@hotmail.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50905 Subject: LU-16808 lfs: lfs find --printf won't hang on special files Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 935a7716d744d2c2009a363f0b1bdbaee84d0895

            People

              bobijam Zhenyu Xu
              bertschinger Thomas Bertschinger
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: