Linux: O_TMPFILE and insert inode hash rework #16772
Open
+68
−79
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Byproduct of investigation done for #16608 - these are the more optional bits, cosmetics, in hope to simplify reasoning about inode lifetime
Description
This change:
reworks inode hash insert so that its in topmost layer and with inode unlock in the same order as other Linux FS implementations do it
reworks
O_TMPFILE
creation to use new linux specificzp->z_is_tmpfile
, this fixes a potential unchecked error return value ofzpl_xattr_security_init
changes igrabs to zhold where it can
exchanges
truncate_setsize
fortruncate_inode_pages_final
inzpl_evict_inode
to followvfs.rst
's"the method has to use truncate_inode_pages_final()"
notes + questions:
not sure about the change from "working with inode" to "working with znode" in
zpl_link
, can remove that, that's a bit of a leftoverI'd like to eliminate the
txg_wait_synced
inzfs_link
in the tmpfile case, I'd log it as a new file creation, is that ok? edit: this probably won't work, or will be too much work, I have another idea:log the tmpfile creation at creation, log all the changes, acl/xattr/writes, if it comes to replay then put it to unlinked set replay all the changes and then the unlinked set get processed before mount anyway, right?
How Has This Been Tested?
Localy during development and via the bots also
Types of changes
Checklist:
Signed-off-by
.