nfsproxy: middleware chain hides CachingHandler and disables directory verifier caching
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 64/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- go
- Ambito
- backend, testing-qa
Direzione di ricerca
Inizia individuando le implementazioni e gli helper del middleware di tracing, metriche, logging e recovery, oltre a helpers.CachingHandler. Traccia il modo in cui viene assemblata la catena di middleware, poi esamina i test esistenti del middleware prima di aggiungere la copertura per la catena completa. Il lavoro è completato quando le chiamate al verifier, insieme ai relativi argomenti e valori restituiti, raggiungono il caching handler sottostante e il comportamento di recovery rimane invariato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Symptom
The NFS proxy's directory verifier cache is silently bypassed.
Paginated READDIR and READDIRPLUS requests cannot reuse the directory listing associated with the cookie verifier returned by the first page. Each subsequent request reads and sorts the directory again.
If the directory changes between pages, the newly calculated verifier differs from the verifier supplied by the client, causing go-nfs to return NFS3ERR_BAD_COOKIE:
if obj.Cookie > 0 && obj.CookieVerif > 0 && verifier != obj.CookieVerif {
return &NFSStatusError{NFSStatusBadCookie, nil}
}
Even when the directory does not change, the repeated ReadDir calls add unnecessary filesystem work for large paginated listings.
Root cause
The proxy creates a helpers.CachingHandler before applying its middleware:
handler = helpers.NewCachingHandler(handler, cacheLimit)
if config.Tracing {
handler = tracing.WrapWithTracing(handler, config)
}
if config.Metrics {
handler = metrics.WrapWithMetrics(handler, config)
}
if config.Logging {
handler = logged.WrapWithLogging(ctx, handler, config)
}
handler = recovery.WrapWithRecovery(ctx, handler)
go-nfs checks the outermost handler for the optional nfs.CachingHandler interface:
if vh, ok := userHandle.(CachingHandler); verifier != 0 && ok {
entries := vh.DataForVerifier(path, verifier)
if entries != nil {
return entries, verifier, nil
}
}
The tracing, metrics, logging, and recovery handlers only implement nfs.Handler. They do not expose or forward:
VerifierFor(path string, contents []fs.FileInfo) uint64
DataForVerifier(path string, verifier uint64) []fs.FileInfo
Because recovery middleware is always installed, the outermost handler never satisfies nfs.CachingHandler, regardless of whether tracing, metrics, or logging are enabled.
As a result, go-nfs never reaches the verifier cache maintained by helpers.CachingHandler:
func (c *CachingHandler) VerifierFor(path string, contents []fs.FileInfo) uint64 {
id := hashPathAndContents(path, contents)
c.activeVerifiers.Add(id, verifier{path, contents})
return id
}
func (c *CachingHandler) DataForVerifier(path string, id uint64) []fs.FileInfo {
if cache, ok := c.activeVerifiers.Get(id); ok {
return cache.contents
}
return nil
}
Why it matters
NFS directory cookies are indexes into the sorted directory listing:
cookie := uint64(i + 2)
For pagination to remain consistent, subsequent requests should use the same listing that produced the original cookie verifier.
Without verifier caching:
- Every page performs another
ReadDirand sort. - Insertions or removals can shift cookie indexes between pages.
- Directory changes can cause
NFS3ERR_BAD_COOKIE. - Large directory listings perform unnecessary repeated filesystem operations.
Proposed fix
Preserve nfs.CachingHandler through the complete middleware chain:
- Implement
VerifierForandDataForVerifieron the tracing handler. - Implement
VerifierForandDataForVerifieron the metrics handler. - Implement
VerifierForandDataForVerifieron the logging handler. - Implement
VerifierForandDataForVerifieron the recovery handler. - Forward both calls to the wrapped handler when it implements
nfs.CachingHandler. - Add compile-time assertions that each middleware implements
nfs.CachingHandler. - Preserve panic recovery around verifier operations in the recovery handler.
- Add a test covering the complete middleware chain and verifying that arguments and return values reach the underlying caching handler.
- Lingua principale
- Go
- Stelle
- 1.6k
- Fork
- 438
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di e2b-dev/runtime
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running state Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
Tutte le issue di e2b-dev/runtime
Issue simili
-
agentic-workflows
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
agentic-workflows
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
microsoft/agent-framework-go#1179 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
[Bug]: OLLAMA_KEEP_ALIVE="5m" / "24h" crashes Ollama embedding and vision models with ValueError Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
infiniflow/ragflow#20223 · 1 reazione ·
-
bug needs triage pkg/translator/faro
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
open-telemetry/opentelemetry-collector-contrib#51484 · 1 commento ·