-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HDFS-15689. allow/disallowSnapshot on EZ roots shouldn't fail due to trash provisioning/emptiness check #2472
Conversation
…trash provisioning/emptiness check Change-Id: Ic4bbdfad7aa4cb07082dc8b6ba1c50caa2769360
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @smengcl for working on this.
} catch (FileAlreadyExistsException ex) { | ||
// Don't throw on FileAlreadyExistsException since it is likely due to | ||
// admin allowing snapshot on an EZ root. | ||
LOG.warn(ex.getMessage()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are 2 approaches instead of just ignoring the FileAlreadyExists exception:
- we can just validate whether the existing Trash path is a directory and validate the permissions and not throw FileAlreadyExists exception itself in DistributedFileSystem.java#provisionSnapshotTrash
- If the trash path already exists with right permissions, we can check if the path is an encryption zone as well and throw FileAlreadyExists exception only if its not an encryption zone. Similar change will be required for making an snapshottable dir an encryption zone.
I am ok with either of the above approaches. I think just ignoring the exception here will not work in case. the existing path is not a directory or has right permissions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bshashikant for the comment.
I was intending to not change the behavior of DFS#provisionSnapshotTrash
but as I think again changing it should be fine since 3.4.0 is not released yet.
I'm in favor of (1). It makes sense to reuse the trash if it is configured correctly. I will update the PR a bit later.
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
Change-Id: I03ec3bcc547be656b5d568853d477ee433c51978
💔 -1 overall
This message was automatically generated. |
Change-Id: I11fb879dbf9a18bef286a1995506916dfd4fca60
💔 -1 overall
This message was automatically generated. |
@bshashikant Would you take another look? The new revision doesn't throw when the trash exists and has the correct permission. |
💔 -1 overall
This message was automatically generated. |
Thanks @smengcl . I think, we will run into the same problem while creating an encryption zone on a snapshottable dir and may need a similar fix there. Can you plz check? |
The reverse won't be a problem because encryption zone can only be created on empty directories. Once snapshot is enabled ( |
Thanks for the review @bshashikant . Will commit shortly. |
…trash provisioning/emptiness check (apache#2472) Ref.: CDPD-19485 (cherry picked from commit 235947e) Change-Id: Ibf231bc5179c36b1598b4e2789d8925a040c0978
https://issues.apache.org/jira/browse/HDFS-15689
See the jira description for details.
Will add UT in
TestDFSAdmin
later. Maybe also inTestEncryptionZones
.