Il file system Ceph (CephFS) è un file system POSIX compatibile che utilizza un cluster di storage Ceph per memorizzare i dati. CephFS utilizza lo stesso sistema di cluster dei dispositivi di blocco Ceph, storage oggetto Ceph con le API S3 e Swift o associazioni native (librados
).
Per utilizzare CephFS, deve essere presente un cluster di storage Ceph in esecuzione e almeno un server metadati Ceph in esecuzione.
Con SUSE Enterprise Storage 6, SUSE introduce il supporto ufficiale per molti scenari in cui si utilizza il componente CephFS distribuito e scalato. Questa voce descrive i limiti concreti e fornisce una guida per i casi d'uso suggeriti.
Una distribuzione CephFS supportata deve rispettare questi requisiti:
Almeno un Metadata Server. SUSE consiglia di distribuire diversi nodi con il ruolo MDS. Solo uno sarà attivo
e il resto passivo
. Ricordare di menzionare tutti i nodi MON nel comando mount
quando si monta il CephFS da un client.
I client sono SUSE Linux Enterprise Server 12 SP3 o versioni più recenti o SUSE Linux Enterprise Server 15 o versioni più recenti e utilizzano il driver del modulo cephfs
del kernel. Il modulo FUSE non è supportato.
Le quote CephFS sono supportate in SUSE Enterprise Storage 6 ed è possibile impostarle su qualsiasi sottodirectory del file system Ceph. La quota consente di limitare il numero di byte
o file
memorizzati al di sotto del punto specificato nella gerarchia della directory. Per ulteriori informazioni, vedere Sezione 19.6, «Impostazione delle quote CephFS».
CephFS supporta modifiche del layout del file come documentato in Sezione 11.3.4, «Layout di file». Tuttavia, mentre il file system è montato da qualsiasi client, i nuovi pool di dati potrebbero non venire aggiunti a un file system CephFS esistente (ceph mds add_data_pool
). Possono essere aggiunti solo mentre il file system non è montato.
Almeno un server di metadati. SUSE consiglia di distribuire diversi nodi con il ruolo MDS. Per default, i daemon MDS aggiuntivi iniziano come daemon di standby
, fungendo da backup per l'MDS attivo. Sono inoltre supportati più daemon MDS attivi (fare riferimento alla Sezione 11.3.2, «Dimensione cluster MDS»).
Il Metadata Server (MDS) Ceph memorizza i metadati per il CephFS. I dispositivi di blocco Ceph e lo storage oggetto Ceph non utilizzano MDS. I MDS consentono agli utenti del file system POSIX di eseguire comandi di base, come ls
o find
, senza caricare eccessivamente il cluster di storage Ceph.
È possibile distribuire MDS durante il processo di distribuzione iniziale del cluster come descritto in Sezione 5.3, «Distribuzione del cluster», oppure aggiungerlo a un cluster già distribuito come descritto in Sezione 2.1, «Aggiunta di nuovi nodi cluster».
Dopo aver distribuito MDS, consentire al servizio Ceph OSD/MDS
nelle impostazioni del firewall del server dove è distribuito MDS: avviare yast
, selezionare › › e nel menu a discesa selezionare . Se per il nodo Ceph MDS non è consentito traffico completo, il montaggio di un file system non riesce, anche se altre operazioni possono funzionare correttamente.
È possibile definire con precisione il comportamento di MDS inserendo opzioni pertinenti nel file di configurazione ceph.conf
.
Se è impostata su "true" (default), i monitor forzano l'attivazione della modalità di riproduzione in standby. Viene impostata nelle sezioni [mon]
o [global]
.
mds cache memory limit
Il limite di memoria software (in byte) che il MDS applica per la cache. Gli amministratori devono utilizzare questa invece della precedente impostazione mds cache size
. Il valore predefinito è 1 GB.
mds cache reservation
La prenotazione della cache (memoria o nodi) da mantenere per la cache MDS. Il MDS, quando inizia a toccare la prenotazione, revoca le capacità del client finché la dimensione della cache si riduce per ripristinare la riserva. Il default è 0,05.
Numero di inode da memorizzare nella cache. Un valore pari a 0 (default) indica un numero illimitato. Si consiglia di utilizzare mds cache memory limit
per limitare la quantità di memoria utilizzata dalla cache MDS.
Punto di inserimento di nuovi elementi nell'LRU della cache (a partire dall'alto). Il valore di default è 0.7.
Frazione della directory modificata prima che Ceph esegua il commit tramite un aggiornamento completo al posto di uno parziale. Il valore di default è 0,5.
Dimensioni massime di un aggiornamento della directory prima che Ceph lo suddivida in transazioni più piccole. Il valore di default è 90 MB.
Half-life della temperatura della cache MDS. Il valore di default è 5.
Frequenza espressa in secondi dei messaggi beacon inviati al monitor. Il valore di default è 4.
Intervallo senza beacon prima che Ceph dichiari lento un MDS e possibilmente lo sostituisca. Il valore di default è 15.
Permanenza nel black list degli MDS con errori nella mappa OSD. Questa impostazione consente di controllare il tempo di permanenza dei daemon MDS con errori nel black list della mappa OSD. Non influisce sulla permanenza nel back list degli elementi aggiunti manualmente da un amministratore. Ad esempio, il comando ceph osd blacklist add
utilizzerà il tempo di black list di default. Il valore di default è 24 * 60.
Intervallo di tempo espresso in secondi da attendere per la riconnessione dei client durante il riavvio di MDS. Il valore di default è 45.
Frequenza di esecuzione dei task periodici interni da parte di MDS. Il valore di default è 5.
Intervallo di tempo minimo espresso in secondi in cui tentare di evitare la propagazione delle statistiche ricorsive nell'albero. Il valore di default è 1.
Rapidità di propagazione delle modifiche dirstat. Il valore di default è 5.
Quantità di numeri inode da preallocare per sessione client. Il valore di default è 1000.
Determina se MDS deve consentire ai client di visualizzare i risultati delle richieste prima di eseguire il commit sul journal. L'impostazione di default è "true".
Utilizza la mappa semplice per gli aggiornamenti della directory. L'impostazione di default è "true".
Funzione da utilizzare per l'hashing dei file sui frammenti della directory. Il valore di default è 2 (ovvero "rjenkins").
Determina se MDS deve tentare di ignorare gli eventi del journal danneggiati durante la riproduzione del journal. L'impostazione di default è "false".
Numero massimo di eventi nel journal prima dell'avvio della limitazione. Impostarla a 1 (default), per disabilitare i limiti.
Numero massimo di segmenti (oggetti) nel journal prima dell'avvio della limitazione. Impostarla a -1 per disabilitare i limiti. Il valore di default è 30.
Numero massimo di segmenti da estinguere in parallelo. Il valore di default è 20.
Numero massimo di inode in un evento EOpen. Il valore di default è 100.
Determina la frequenza di campionamento della temperatura della directory per le decisioni di frammentazione. Il valore di default è 3.
Temperatura massima prima che Ceph tenti di replicare i metadati su altri nodi. Il valore di default è 8000.
Temperatura minima prima che Ceph interrompa la replica dei metadati su altri nodi. Il valore di default è 0.
Dimensioni massime della directory prima che MDS suddivida un frammento di directory in bit più piccoli. Il valore di default è 10000.
Temperatura di lettura della directory massima prima che Ceph suddivida un frammento di directory. Il valore di default è 25000.
Temperatura di scrittura della directory massima prima che Ceph suddivida un frammento di directory. Il valore di default è 10000.
Numero di bit in base a cui suddividere un frammento di directory. Il valore di default è 3.
Dimensioni minime della directory prima che Ceph tenti di unire i frammenti di directory adiacenti. Il valore di default è 50.
Frequenza espressa in secondi degli scambi di workload tra MDS. Il valore di default è 10.
Ritardo espresso in secondi tra la capacità di suddivisione o unione di un frammento e l'esecuzione della modifica della frammentazione. Il valore di default è 5.
Rapporto in base al quale i frammenti possono superare le dimensioni di suddivisione prima che venga eseguita immediatamente una suddivisione ignorando l'intervallo di frammentazione. Il valore di default è 1.5.
Dimensioni massime di un frammento prima che eventuali nuove voci vengano rifiutate con ENOSPC. Il valore di default è 100000.
Temperatura minima prima che Ceph riesegua la migrazione di un sottoalbero al relativo albero superiore. Il valore di default è 0.
Metodo di calcolo del carico MDS:
0 = Ibrido.
1 = Velocità e latenza della richiesta.
2 = Carico della CPU.
Il valore di default è 0.
Temperatura minima del sottoalbero prima che Ceph esegua la migrazione. Il valore di default è 0.1.
Temperatura minima del sottoalbero prima che Ceph esegua la ricerca di un sottoalbero. Il valore di default è 0.2.
Frazione minima delle dimensioni di destinazione di un sottoalbero da accettare. Il valore di default è 0,8.
Frazione massima delle dimensioni di destinazione di un sottoalbero da accettare. Il valore di default è 1.2.
Ceph eseguirà la migrazione dei sottoalberi superiori a tale frazione delle dimensioni di destinazione del sottoalbero. Il valore di default è 0.3.
Ceph ignorerà i sottoalberi inferiori a tale frazione delle dimensioni di destinazione del sottoalbero. Il valore di default è 0,001.
Numero minimo di iterazioni del servizio di bilanciamento prima che Ceph rimuova una destinazione MDS meno recente dalla mappa MDS. Il valore di default è 5.
Numero massimo di iterazioni del servizio di bilanciamento prima che Ceph rimuova una destinazione MDS meno recente dalla mappa MDS. Il valore di default è 10.
Intervallo di polling del journal quando in modalità di riproduzione in standby ("hot standby"). Il valore di default è 1.
Intervallo di polling della cache durante la chiusura di MDS. Il valore di default è 0.
Ceph unirà o suddividerà in frammenti le directory in modo casuale. Il valore di default è 0.
Ceph eseguirà il dump dei contenuti della cache MDS in un file su ciascuna mappa MDS. L'impostazione di default è "false".
Ceph eseguirà il dump dei contenuti della cache MDS in un file dopo essere rientrato nella cache durante il processo di recupero. L'impostazione di default è "false".
Un daemon MDS andrà in standby per un altro daemon MDS il cui nome è specificato in questa impostazione.
Un daemon MDS andrà in standby per un altro daemon MDS di questa classificazione. Il valore di default è -1.
Determina se un daemon MDS Ceph deve effettuare il polling e riprodurre il log di un MDS attivo ("hot standby"). L'impostazione di default è "false".
Imposta il numero minimo di capacità che un client può sospendere. Il valore di default è 100.
Imposta il rapporto massimo di capacità correnti che possono essere richiamate durante la pressione della cache MDS. Il valore di default è 0,8.
Frequenza con cui aggiornare l'oggetto di intestazione del journal. Il valore di default è 15.
Numero di intervalli di striping per la lettura in avanti durante la riproduzione del journal. Il valore di default è 10.
Numero di intervalli di striping da azzerare prima della posizione di scrittura. Il valore di default è 10.
Latenza aggiuntiva massima espressa in secondi impostata in modo artificiale. Il valore di default è 0,001.
Numero massimo di byte in base a cui ritardare lo svuotamento. Il valore di default è 0.
Se si ha un cluster di storage Ceph in stato corretto con almeno un server metadati Ceph, è possibile creare e montare il file system Ceph. Accertare che il client disponga di connettività di rete e di un corretto portachiavi di autenticazione.
Un CephFS richiede almeno due pool RADOS: uno per i dati e uno per i metadati. Quando si configurano tali pool, considerare:
L'utilizzo di un più alto livello di replica per il pool metadati, in quanto eventuali perdite di dati in questo pool possono rendere l'intero file system inaccessibile.
L'utilizzo di storage a più bassa latenza, come i SSD per il pool di metadati, in quanto verrà migliorata la latenza osservata delle operazioni del file system sui client.
Quando si assegna un role-mds
in policy.cfg
, i pool richiesti vengono creati automaticamente. È possibile creare manualmente i pool cephfs_data
e cephfs_metadata
per l'ottimizzazione delle prestazioni manuali prima di configurare il Metadata Server. DeepSea non crea questi pool se esistono già.
Per ulteriori informazioni sulla gestione dei pool, vedere Capitolo 11, Gestione di pool di memorizzazione.
Per creare i due pool richiesti, ad esempio "cephfs_data" e "cephfs_metadata", con le impostazioni di default da utilizzare con CephFS, eseguire i comandi indicati:
cephadm@adm >
ceph osd pool create cephfs_data pg_numcephadm@adm >
ceph osd pool create cephfs_metadata pg_num
È possibile utilizzare i pool EC invece dei pool replicati. Si consiglia di utilizzare solo pool EC per requisiti di basse prestazioni e accesso casuale non frequente, ad esempio storage a freddo, backup, archiviazione. CephFS sui pool EC richiede l'attivazione di BlueStore e il pool deve avere l'opzione allow_ec_overwrite
impostata. È possibile impostare questa opzione eseguendo ceph osd pool set ec_pool allow_ec_overwrites true
.
La codifica di cancellazione aggiunge significativo overhead alle operazioni del file system, in particolare i piccoli aggiornamenti. Questo overhead è inerente all'impiego della codifica di cancellazione come meccanismo di tolleranza dell'errore. Questa penalità è un compromesso per overhead di spazio di storage sensibilmente ridotto.
Quando si creano i pool, è possibile abilitare il file system con il comando ceph fs new
:
cephadm@adm >
ceph fs new fs_name metadata_pool_name data_pool_name
Ad esempio:
cephadm@adm >
ceph fs new cephfs cephfs_metadata cephfs_data
È possibile controllare che il file system sia stato creato elencando tutti i CephFS disponibili:
cephadm@adm >
ceph
fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
Dopo aver creato il file system, il MDS sarà in grado di entrare in uno stato attivo. Ad esempio, in un singolo sistema MDS:
cephadm@adm >
ceph
mds stat
e5: 1/1/1 up
Ulteriori informazioni su task specifici, ad esempio montaggio, smontaggio e impostazione CephFS avanzata, sono disponibili in Capitolo 19, File system in cluster.
Un'istanza CephFS può essere servita da più daemon MDS attivi. Tutti i daemon MDS attivi assegnati a un'istanza CephFS distribuiscono la struttura di directory del file system tra di loro e perciò aumentano il carico dei client concorrenti. Per aggiungere un daemon MDS attivo a un'istanza CephFS, ne è necessario uno di standby di riserva. Avviare un daemon aggiuntivo o utilizzare un'istanza standby esistente.
Il comando seguente visualizza il numero corrente di daemon MDS attivi e passivi.
cephadm@adm >
ceph mds stat
Il comando seguente imposta il numero di MDS attivi a due in un'istanza del file system.
cephadm@adm >
ceph fs set fs_name max_mds 2
Per ridurre il cluster MDS prima di un aggiornamento, sono necessari due passaggi. Innanzitutto, impostare max_mds
in modo che rimanga solo un'istanza:
cephadm@adm >
ceph fs set fs_name max_mds 1
disattivare quindi esplicitamente gli altri daemon MDS attivi:
cephadm@adm >
ceph mds deactivate fs_name:rank
dove rank è il numero di un daemon MDS attivo di un'istanza del file system, compreso tra 0 e max_mds
-1.
Si consiglia di lasciare almeno un MDS come daemon di standby.
Durante gli aggiornamenti di Ceph, i flag della caratteristica su un'istanza del file system possono cambiare (di solito aggiungendo nuove caratteristiche). I daemon incompatibili (ad esempio le versioni precedenti) non sono in grado di funzionare con una caratteristica incompatibile impostata e rifiutano di avviarsi. Questo significa che l'aggiornamento e il riavvio di un daemon può provocare l'arresto e il rifiuto di avvio di tutti gli altri daemon non ancora aggiornati. Per questo motivo, si consiglia di ridurre il cluster MDS attivo alla dimensione uno e di interrompere tutti i daemon in standby prima di aggiornare Ceph. I passaggi manuali di questa procedura di aggiornamento sono i seguenti:
Aggiornare i pacchetti relativi al Ceph con zypper
.
Ridurre a un'istanza il cluster MDS attivo come descritto sopra e interrompere tutti i daemon MDS di standby tramite le relative unità systemd
su tutti gli altri nodi:
cephadm@mds >
systemctl stop ceph-mds\*.service ceph-mds.target
Riavviare quindi solo il singolo daemon MDS rimanente, provocandone il riavvio con il binario aggiornato.
cephadm@mds >
systemctl restart ceph-mds\*.service ceph-mds.target
Riavviare tutti gli altri daemon MDS e reimpostare l'impostazione max_mds
desiderata.
cephadm@mds >
systemctl start ceph-mds.target
Se si utilizza DeepSea, seguire questa procedura nel caso in cui il pacchetto ceph sia stato aggiornato durante le fasi 0 e 4. È possibile eseguire questa procedura mentre i client hanno l'istanza CephFS montata e l'I/O è in corso. Tenere tuttavia presente che vi sarà una breve pausa di I/O durante il riavvio del MDS. I client si ripristinano automaticamente.
È opportuno ridurre al massimo possibile il carico di I/O prima di aggiornare un cluster MDS. Un cluster MDS inattivo passa più rapidamente attraverso questa procedura di aggiornamento. Al contrario, su un cluster molto carico con più daemon MDS è essenziale ridurre il carico in anticipo per impedire di travolgere un singolo daemon MDS da I/O ininterrotti.
Tramite il layout dei file è possibile controllare in che modo i relativi contenuti vengono mappati agli oggetti Ceph RADOS. È possibile leggere il e scrivere sul layout di un file utilizzando gli attributi estesi virtuali ( o xattrs).
Il nome degli attributi xattrs di layout è diverso, a seconda se si tratta di un file normale o di una directory. Gli attributi xattrs di layout dei file normali sono denominati ceph.file.layout
, mentre quelli delle directory sono chiamati ceph.dir.layout
. Laddove negli esempi si fa riferimento a ceph.file.layout
, sostituire la parte .dir.
come opportuno nel caso delle directory.
Sono riconosciuti i seguenti campi di attributo:
ID o nome di un pool RADOS in cui verranno memorizzati gli oggetti dati del file.
Spazio dei nomi RADOS all'interno di un pool di dati su verranno scritti gli oggetti. È vuoto per default, per indicare uno spazio dei nomi di default.
Dimensioni espresse in byte di un blocco di dati utilizzato nella distribuzione RAID 0 (Striping) di un file. Tutte le unità di striping di un file hanno le stesse dimensioni. L'ultima unità di striping in genere è incompleta: rappresenta i dati nella parte finale del file e lo "spazio" inutilizzato, fino a raggiungere le dimensioni definite per l'unità di striping.
Numero di unità di striping consecutive che costituiscono uno "segmento" RAID 0 (Striping) dei dati del file.
Dimensioni espresse in byte degli oggetti RADOS in cui i dati del file sono suddivisi in porzioni.
RADOS applica un limite configurabile alle dimensioni dell'oggetto. Se si aumentano le dimensioni dell'oggetto CephFS oltre tale limite, le operazioni di scrittura potrebbero non riuscire. L'impostazione OSD è osd_max_object_size
, pari a 128 MB per default. Gli oggetti RADOS di dimensioni molto elevate potrebbero impedire un normale svolgimento delle operazioni del cluster, pertanto non si consiglia di aumentare il limite delle dimensioni dell'oggetto oltre quello di default.
getfattr
#
Utilizzare il comando getfattr
per leggere come stringa singola le informazioni sul layout di un file file
di esempio:
root #
touch fileroot #
getfattr -n ceph.file.layout file # file: file ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430
Per leggere i singoli campi di layout:
root #
getfattr -n ceph.file.layout.pool file # file: file ceph.file.layout.pool="cephfs_data"root #
getfattr -n ceph.file.layout.stripe_unit file # file: file ceph.file.layout.stripe_unit="4194304"
Durante la lettura dei layout, in genere il pool viene indicato con il nome. Tuttavia, nei rari casi in cui i pool sono appena stati creati, potrebbe venire invece restituito un ID.
Le directory non disporranno di un layout esplicito finché questo non viene personalizzato. Se il layout non è mai stato modificato, i tentativi di lettura non riusciranno e di conseguenza verrà utilizzato il layout della directory antenato successiva con un layout esplicito.
root #
mkdir dirroot #
getfattr -n ceph.dir.layout dir dir: ceph.dir.layout: No such attributeroot #
setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"
setfattr
#
Utilizzare il comando setfattr
per modificare i campi di layout di un file file
di esempio:
cephadm@adm >
ceph osd lspools 0 rbd 1 cephfs_data 2 cephfs_metadataroot #
setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot #
setfattr -n ceph.file.layout.stripe_count -v 8 file # Setting pool by ID:root #
setfattr -n ceph.file.layout.pool -v 1 file # Setting pool by name:root #
setfattr -n ceph.file.layout.pool -v cephfs_data file
Quando i campi di layout di un file vengono modificati tramite setfattr
, questo file deve essere vuoto, altrimenti si verificherà un errore.
Se si desidera rimuovere un layout esplicito da una directory mydir
di esempio e ripristinare l'ereditarietà del layout del relativo antenato, eseguire quanto riportato di seguito:
root #
setfattr -x ceph.dir.layout mydir
Allo stesso modo, se è stato impostato l'attributo "pool_namespace" e si desidera modificare il layout per utilizzare invece lo spazio dei nomi di default, eseguire:
# Create a directory and set a namespace on itroot #
mkdir mydirroot #
setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot #
getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons" # Clear the namespace from the directory's layoutroot #
setfattr -x ceph.dir.layout.pool_namespace mydirroot #
getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"
Quando vengono creati, i file ereditano il layout della relativa directory superiore. Tuttavia, le successive modifiche al layout della directory superiore non vengono applicate a quelle secondarie:
root #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # file1 inherits its parent's layoutroot #
touch dir/file1root #
getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # update the layout of the directory before creating a second fileroot #
setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot #
touch dir/file2 # file1's layout is unchangedroot #
getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # ...while file2 has the parent directory's new layoutroot #
getfattr -n ceph.file.layout dir/file2 # file: dir/file2 ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
I file creati come discendenti della directory ereditano anche il suo layout se non è stato impostato nessun layout per le directory intermedie:
root #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root #
mkdir dir/childdirroot #
getfattr -n ceph.dir.layout dir/childdir dir/childdir: ceph.dir.layout: No such attributeroot #
touch dir/childdir/grandchildroot #
getfattr -n ceph.file.layout dir/childdir/grandchild # file: dir/childdir/grandchild ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Prima che sia possibile utilizzare un pool con CephFS, è necessario aggiungerlo al server di metadati:
cephadm@adm >
ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm >
ceph fs ls # Pool should now show up .... data pools: [cephfs_data cephfs_data_ssd ]
Assicurarsi che le chiavi cephx in uso consentano al client di accedere a questo nuovo pool.
È quindi possibile aggiornare il layout su una directory in CephFS per utilizzare il pool aggiunto:
root #
mkdir /mnt/cephfs/myssddirroot #
setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir
Tutti i nuovi file creati all'interno di tale directory erediteranno il suo layout e posizioneranno i dati nel pool appena aggiunto. Il numero di oggetti nel pool di dati primario potrebbe continuare ad aumentare, anche se i file vengono creati nel pool appena aggiunto. Si tratta di un comportamento normale: i dati del file vengono memorizzati nel pool specificato dal layout, ma una piccola quantità di metadati viene conservata nel pool di dati primario per tutti i file.