[OpenAFS-devel] Questions regarding low-level FUSE backend for OpenAFS (GSoC 2026)

[Devesh Bhardwaj (B23CS1014)]

--0000000000001e7613064d9991c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear OpenAFS Mentors,

My name is Devesh Bhardwaj, and I am a B.Tech undergraduate in Computer
Science with a strong interest in distributed systems and filesystem
design. I am keen to contribute to OpenAFS, particularly the project
focused on implementing a low-level FUSE backend, and I have been studying
the existing architecture of the OpenAFS cache manager and its interaction
with various VFS backends.

I would like to seek clarification on a few design aspects of the proposed
low-level FUSE integration:

   1. In the low-level FUSE API, operations are primarily inode-based,
   requiring stable inode numbers (node IDs) to be maintained across the
   lifetime of filesystem objects. Given that OpenAFS internally identifies
   files using file identifiers (FIDs) and supports operations such as
   renames, moves across directories, and deletions, what would be the
   recommended strategy to ensure stable and consistent inode mappings?
   Specifically, should the inode number be derived deterministically from =
the
   FID (e.g., via hashing or encoding), or should a separate mapping layer =
be
   maintained to handle lifecycle events and ensure uniqueness and persiste=
nce?
   2. The current FUSE implementations in OpenAFS rely on file IDs for
   object identification. Transitioning to a low-level FUSE interface would
   require adapting this model to inode-based lookups and reference countin=
g
   semantics (e.g., lookup, forget, and generation numbers). What would be =
the
   expected approach for bridging this gap? In particular, how should we
   handle inode reference management, caching, and consistency with the AFS
   cache manager=E2=80=99s existing mechanisms?

Additionally, I have been considering the possibility of developing an
inspection or debugging tool for OpenAFS that could provide visibility into
the internal state of the cache manager. Such a tool could expose
information such as cache validation status, callback state, file
versioning, and access patterns, potentially aiding both developers and
users in understanding system behavior and diagnosing issues. I would
appreciate any insights on whether similar tooling already exists within
the OpenAFS ecosystem, or if this could be a valuable area for contribution=
.

Thank you for your time and guidance. I look forward to your feedback.

Best regards,
Devesh Bhardwaj

--0000000000001e7613064d9991c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"gmail-isSelectedEnd">Dear OpenAFS Mentors,</p>=
<p class=3D"gmail-isSelectedEnd">My name is Devesh Bhardwaj, and I am a B.T=
ech undergraduate in Computer Science with a strong interest in distributed=
 systems and filesystem design. I am keen to contribute to OpenAFS, particu=
larly the project focused on implementing a low-level FUSE backend, and I h=
ave been studying the existing architecture of the OpenAFS cache manager an=
d its interaction with various VFS backends.</p><p class=3D"gmail-isSelecte=
dEnd">I would like to seek clarification on a few design aspects of the pro=
posed low-level FUSE integration:</p><ol start=3D"1"><li>In the low-level F=
USE API, operations are primarily inode-based, requiring stable inode numbe=
rs (node IDs) to be maintained across the lifetime of filesystem objects. G=
iven that OpenAFS internally identifies files using file identifiers (FIDs)=
 and supports operations such as renames, moves across directories, and del=
etions, what would be the recommended strategy to ensure stable and consist=
ent inode mappings? Specifically, should the inode number be derived determ=
inistically from the FID (e.g., via hashing or encoding), or should a separ=
ate mapping layer be maintained to handle lifecycle events and ensure uniqu=
eness and persistence?</li><li>The current FUSE implementations in OpenAFS =
rely on file IDs for object identification. Transitioning to a low-level FU=
SE interface would require adapting this model to inode-based lookups and r=
eference counting semantics (e.g., lookup, forget, and generation numbers).=
 What would be the expected approach for bridging this gap? In particular, =
how should we handle inode reference management, caching, and consistency w=
ith the AFS cache manager=E2=80=99s existing mechanisms?</li></ol><p class=
=3D"gmail-isSelectedEnd">Additionally, I have been considering the possibil=
ity of developing an inspection or debugging tool for OpenAFS that could pr=
ovide visibility into the internal state of the cache manager. Such a tool =
could expose information such as cache validation status, callback state, f=
ile versioning, and access patterns, potentially aiding both developers and=
 users in understanding system behavior and diagnosing issues. I would appr=
eciate any insights on whether similar tooling already exists within the Op=
enAFS ecosystem, or if this could be a valuable area for contribution.</p><=
p class=3D"gmail-isSelectedEnd">Thank you for your time and guidance. I loo=
k forward to your feedback.</p><p>Best regards,<br>Devesh Bhardwaj</p></div=
>

--0000000000001e7613064d9991c9--