Announcement

Collapse
No announcement yet.

FANOTIFY API To Become More Useful With The Linux 5.1 Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • FANOTIFY API To Become More Useful With The Linux 5.1 Kernel

    Phoronix: FANOTIFY API To Become More Useful With The Linux 5.1 Kernel

    The fanotify API that is used for monitoring/intercepting file-system events is set to tack on a few more features with the upcoming Linux 5.1 kernel cycle...

    http://www.phoronix.com/scan.php?pag...y-Improvements

  • #2
    I was curious about the behaviour of "moving" files on Linux, so I looked up the syscall for doing it. It's "rename()".

    Details here:

    Code:
    man 2 rename
    The documentation makes sense to me except for this one part of the man page. It says:

    If newpath exists but the operation fails for some reason rename() guarantees to leave an instance of newpath in place.
    What does that mean?

    Does it leave the original file at the location newpath untouched? Does it ensure there is something left at newpath (IE either the file being renamed XOR the original file that was already present at newpath)?

    I think the sensible thing for the rename() call to do in the event of a failure, is to:
    • ensure that the file referenced by oldpath remains linked at oldpath.
    • return an error code
    • ideally the error code should be specific to the actual thing that went wrong (IE it's not just a generic IT_BROKE error).


    I was also surprised to see that the man page did not explain whether the rename operation works across different file systems. Presumably on a single file system, it will do an unlink() and link() operation. When rename()ing a file across 2 different file systems, presumably it will copy the file across link()ing it in the new location and then unlink() it in the old location.

    Comment


    • #3
      fanotify/inotify have always been useless with many use cases simply because you have to register each file and directory you want to watch, you cannot register to also watch all subdirectories as well. If you need to monitor tens of thousands of files, this gets ridiculous quickly. A very limited API.

      Comment


      • #4
        Originally posted by jpg44 View Post
        fanotify/inotify have always been useless with many use cases simply because you have to register each file and directory you want to watch, you cannot register to also watch all subdirectories as well. If you need to monitor tens of thousands of files, this gets ridiculous quickly. A very limited API.
        Each directory yes, but not each file, when you listen to a directory you get the events for all its files automatically.

        Comment


        • #5
          Originally posted by cybertraveler View Post
          I was also surprised to see that the man page did not explain whether the rename operation works across different file systems. Presumably on a single file system, it will do an unlink() and link() operation. When rename()ing a file across 2 different file systems, presumably it will copy the file across link()ing it in the new location and then unlink() it in the old location.
          It's also interesting that sendfile(2) works across filesystems, but copy_file_range(2) fails.

          Comment


          • #6
            Originally posted by jpg44 View Post
            fanotify/inotify have always been useless with many use cases simply because you have to register each file and directory you want to watch, you cannot register to also watch all subdirectories as well. If you need to monitor tens of thousands of files, this gets ridiculous quickly. A very limited API.
            Amen.

            Comment


            • #7
              Originally posted by cybertraveler View Post
              What does that mean?
              it means that rename is atomic. it will either do nothing or rename completely
              Originally posted by cybertraveler View Post
              I was also surprised to see that the man page did not explain whether the rename operation works across different file systems.
              obviously it doesn't. not even across different mounts of same filesystem
              Originally posted by cybertraveler View Post
              Presumably on a single file system, it will do an unlink() and link() operation.
              wrong. that wouldn't be atomic
              Originally posted by cybertraveler View Post
              When rename()ing a file across 2 different file systems, presumably it will copy the file across link()ing it in the new location and then unlink() it in the old location.
              rename would just fail. /bin/mv would then do open,open,read,write,unlink,close. but that's not one syscall and i've ignored (extended) attributes

              Comment


              • #8
                Originally posted by cl333r View Post
                It's also interesting that sendfile(2) works across filesystems, but copy_file_range(2) fails.
                maybe this has something to do with senfile being able to work with not filesystems at all. like literally requiring second descriptor to be a socket before 2.6.33? sendfile does copy, copy_file_range does reflink, which requires one filesystem

                Comment


                • #9
                  Originally posted by cybertraveler View Post
                  I was also surprised to see that the man page did not explain whether the rename operation works across different file systems.
                  The man page says in the ERRORS section:

                  Code:
                         EXDEV  oldpath and newpath are not on the same mounted filesystem.  (Linux permits a filesys‐
                                tem to be mounted at multiple points, but rename()  does  not  work  across  different
                                mount points, even if the same filesystem is mounted on both.)
                  You are asking good questions though; reading man pages critically and questioning behaviour is good practice. For example, that way the PostgreSQL fsync() bug could have been avoided.

                  Comment


                  • #10
                    Originally posted by nh2_ View Post

                    The man page says in the ERRORS section:

                    Code:
                    EXDEV oldpath and newpath are not on the same mounted filesystem. (Linux permits a filesys‐
                    tem to be mounted at multiple points, but rename() does not work across different
                    mount points, even if the same filesystem is mounted on both.)
                    You are asking good questions though; reading man pages critically and questioning behaviour is good practice. For example, that way the PostgreSQL fsync() bug could have been avoided.
                    Ah, nice spot. Thanks.

                    Comment

                    Working...
                    X