You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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: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).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.shim_dentry
is guarded by a global lock (g_dcache_lock
). Operations on a dentry (e.g. lookup, open, unlink) all takeg_dcache_lock
.shim_inode
holds file metadata (enough to answerstat()
). It has a per-object lock for mutable data.Plan
Rough draft, later steps might evolve.
shim_inode
, convertchroot
fs (PR [LibOS] Introduce inodes, rewrite chroot filesystem #5)d_ops
callbacks, make sure they take the global lock (g_dcache_lock
) (PR Takeg_dcache_lock
in dentry-related functions #282)shim_dentry.lock
(makeg_dcache_lock
the global lock for dentry access)shim_dentry.lock
in thefs_lock
module (POSIX locks) (PR [LibOS] fs_lock: Use a separate lock for all operations #283)shim_dentry.lock
in filesystem callbacks (PR Takeg_dcache_lock
in dentry-related functions #282)shim_dentry.data
andshim_dentry.lock
fields (PR Convertfifo
andsocket
filesystems to use inodes #414)tmpfs
to use inodes #297)pseudo
filesystem to use inodes #402)fifo
andsocket
filesystems to use inodes #414)shim_dentry
(PR [LibOS] Move fully to inodes #428)The text was updated successfully, but these errors were encountered: