Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
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
| Flag | Nome | Significato |
|---|---|---|
| a | Async | Non attendere il risultato di glock (il risultato verrà richiesto più avanti) |
| A | Qualsiasi | Qualsiasi modalità di blocco compatibile è accettabile |
| c | No cache | Quando unlocked, declassa immediatamente DLM lock |
| e | No expire | Ignora le richieste di cancellazione successive di lock |
| E | Exact | Deve avere una modalità lock esatta |
| F | First | Imposta quando un holder è il primo a essere conferito per questo lock |
| H | Holder | Indica che il lock richiesto è stato conferito |
| p | Priorità | Metti l'holder in cima alla coda |
| t | Prova | Un lock "try" |
| T | Try 1CB | Un lock "try" che invia una callback |
| M | Wait | Imposta 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.
