Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-10323

transient deleteOnExit failure in ViewFileSystem due to close() ordering

VotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Duplicate
    • 2.6.0, 2.7.4, 3.0.0-beta1
    • None
    • federation
    • None

    Description

      After switching to using a ViewFileSystem, fs.deleteOnExit calls began failing frequently, displaying this error on failure:

      16/04/21 13:56:24 INFO fs.FileSystem: Ignoring failure to deleteOnExit for path /tmp/delete_on_exit_test_123/a438afc0-a3ca-44f1-9eb5-010ca4a62d84

      Since FileSystem eats the error involved, it is difficult to be sure what the error is, but I believe what is happening is that the ViewFileSystem’s child FileSystems are being close()’d before the ViewFileSystem, due to the random order ClientFinalizer closes FileSystems; so then when the ViewFileSystem tries to close(), it tries to forward the delete() calls to the appropriate child, and fails because the child is already closed.

      I’m unsure how to write an actual Hadoop test to reproduce this, since it involves testing behavior on actual JVM shutdown. However, I can verify that while

      fs.deleteOnExit(randomTemporaryDir);

      

      regularly (~50% of the time) fails to delete the temporary directory, this code:

      ViewFileSystem viewfs = (ViewFileSystem)fs1;

      for (FileSystem fileSystem : viewfs.getChildFileSystems()) {
  
        if (fileSystem.exists(randomTemporaryDir)) {
    
          fileSystem.deleteOnExit(randomTemporaryDir);
  
        }
      
}

      

      always successfully deletes the temporary directory on JVM shutdown.

      I am not very familiar with FileSystem inheritance hierarchies, but at first glance I see two ways to fix this behavior:

      1) ViewFileSystem could forward deleteOnExit calls to the appropriate child FileSystem, and not hold onto that path itself.

      2) FileSystem.Cache.closeAll could first close all ViewFileSystems, then all other FileSystems.

      Would appreciate any thoughts of whether this seems accurate, and thoughts (or help) on the fix.

      Attachments

        1. HDFS-10323.001.patch
          3 kB
          Wenxin He
        2. HDFS-10323.002.patch
          6 kB
          Wenxin He
        3. HDFS-10323.003.patch
          6 kB
          Wenxin He

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            vincent he Wenxin He
            bpodgursky Ben Podgursky
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment