Skip to content
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

Inodes #279

Closed
pwmarcz opened this issue Dec 14, 2021 · 1 comment
Closed

Inodes #279

pwmarcz opened this issue Dec 14, 2021 · 1 comment
Assignees

Comments

@pwmarcz
Copy link
Contributor

pwmarcz commented Dec 14, 2021

Parent issue: #24

This is an issue to track the inodes rewrite project, mostly for myself to keep my thoughts in order.

Motivation

Currently Gramine uses shim_dentry as both "directory entry" and "file metadata" object. This is inconvenient for several reasons:

  • It's hard or even impossible to implement unlink and rename correctly: if we we unlink/rename a file that is open, things often break. Old implementation had a hacky workaround that essentially copied file metadata to a handle, but it worked only partially.
  • Locking is weird and broken. There's a global lock (g_dcache_lock) but also a per-object lock (shim_dentry.lock), and many operations do not use locks at all (FS-related operations are racy and need proper locking graphene#944).
  • The shim_dentry structure is complicated. I think splitting it into dentry and inode will make both structures much simpler, and the interactions more manageable.

Goal

  • shim_dentry is a mapping from name to inode. It doesn't contain file information or filesystem-specific data.
  • All access to shim_dentry is guarded by a global lock (g_dcache_lock). Operations on a dentry (e.g. lookup, open, unlink) all take g_dcache_lock.
  • shim_inode holds file metadata (enough to answer stat()). It has a per-object lock for mutable data.

Plan

Rough draft, later steps might evolve.

@pwmarcz
Copy link
Contributor Author

pwmarcz commented Mar 23, 2022

This is now done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant