C.5. Holder di glock


Tabella C.5, «Flag holder di glock» mostra i significati dei diversi flag holder di glock.
Tabella C.5. Flag holder di glock
FlagNomeSignificato
aAsyncNon attendere il risultato di glock (il risultato verrà richiesto più avanti)
AQualsiasiQualsiasi modalità di blocco compatibile è accettabile
cNo cacheQuando unlocked, declassa immediatamente DLM lock
eNo expireIgnora le richieste di cancellazione successive di lock
EExactDeve avere una modalità lock esatta
FFirstImposta quando un holder è il primo a essere conferito per questo lock
HHolderIndica che il lock richiesto è stato conferito
pPrioritàMetti l'holder in cima alla coda
tProvaUn lock "try"
TTry 1CBUn lock "try" che invia una callback
MWaitImposta mentre in attesa del completamento della richiesta
I flag più importanti sono H (holder) e W (wait) come precedentemente indicato, poichè essi vengono conferiti rispettivamente in base alle richieste di lock conferite e richieste messe in coda. L'ordine degli holder nell'elenco è importante. Se si conferiscono alcuni holder, essi si troveranno sempre nei primi posti della coda, seguiti da qualsiasi altro holder.
In assenza di holder, il primo presente nell'elenco sarà colui che avvierà la modifica alla fase successiva. Poichè le richieste di declassamento hanno sempre una priorità più alta rispetto alle richieste del file system, questo processo potrebbe non sempre risultare in una modifica allo stato richiesto.
Il sottosistema di glock supporta due tipi di lock "try". Entrambi sono molto utili poichè permettono di modificare l'ordine normale dei lock (con operazioni idonee di back-off e retry), e possono essere usate per non utilizzare le risorse in uso da altri nodi. Il lock normale t (try) è semplicemente un lock "try" e non esegue alcuna azione speciale. T (try 1CB) invece, è simile al lock t ad eccezione del fatto che DLM invia una chiamata singola agli holder dei lock correnti non compatibili. Un tipo di utilizzo del lock T (try 1CB) è con iopen, utilizzati per una mediazione tra i nodi quando il conteggio i_nlink di un inode è zero, e per determinare i nodi responsabili per la modifica dell'assegnazione dell'inode. Il glock iopen normalmente presenta uno stato di shared (condiviso), ma se il conteggio i_nlink è zero e ->delete_inode() viene invocato, esso richiederà un lock esclusivo con l'insieme T (try 1CB). Il processo di modifica dell'assegnazione dell'inode continuerà se viene conferito un lock. In caso contrario, i nodi che impedivano il conferimento di un lock creeranno un glock con il flag D (demote), che verrà revisionato in ->drop_inode(), per assicurare che la modifica dell'assegnazione non venga dimenticata.
Ciò significa che agli inode con un conteggio di zero link, ma che risultano ancora aperti, verrà modificata l'allocazione dal nodo sul quale si è verificato l'ultimo close(). Altresì, quando il conteggio del link dell'inode viene diminuito fino a zero, l'inode sarà contrassegnato con uno stato speciale di zero link, ma ancora in uso nel bitmap del gruppo di risorse. Ciò funziona come l'elenco di orfani del file system3 ext3, e cioè permette a qualsiasi lettore del bitmap di sapere se è presente spazio disponibile in grado di essere recuperato.
Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.