How AI Designed a Storage Layout I'd Have Spent Days Planning Myself

Prompt Your Way to Linux: Una serie in 4 parti

Parte 1: Scegliere la distro → Parte 2: Storage e cifratura → Parte 3: Installazione manuale → Parte 4: Servizi e GPU

Se hai mai visto la partizione root riempirsi alle 3 di notte e il sistema bloccarsi completamente, lo sai già: il partizionamento predefinito è una trappola. Ma progettare un layout LVM cifrato per sei carichi di lavoro diversi su tre dischi fisici? È un'intera giornata di pianificazione solitaria, consultazione incrociata di documentazione, calcolo delle dimensioni e dubbi continui.

Ecco come lasciare che l'AI faccia il lavoro pesante nella progettazione dello storage, così non passi una giornata intera sepolto nelle man page. Fornirai i requisiti del tuo carico di lavoro, riceverai un'architettura completa con un ragionamento che puoi davvero seguire, e alla fine capirai ogni livello di ciò che stai costruendo.

Nella Parte 1 hai scelto la distro e mappato l'hardware. Ora arriva la parte in cui la maggior parte delle persone accetta le impostazioni predefinite sbagliate o si arrende del tutto: la progettazione dello storage.

Inizia dai Carichi di Lavoro, Non dalle Dimensioni delle Partizioni

Hai l'hardware mappato dalla Parte 1: diciamo un ThinkPad più vecchio con un'unità NVMe, un SSD e un HDD. Le specifiche ti dicono cosa è possibile. Ma i carichi di lavoro ti dicono cosa è necessario.

Ecco la mossa giusta. Non chiedere all'AI una tabella delle partizioni. Non specificare le dimensioni. Non dire "metti /home su una partizione separata." Descrivi invece comportamenti e requisiti e lascia che ne derivi l'architettura. Qualcosa del genere:

"Questa macchina eseguirà container Docker, PostgreSQL con TimescaleDB, Redis, Ollama per modelli AI locali, e archivierà artefatti di attacco da una rete honeypot. Ha anche bisogno di uno spazio di lavoro di analisi cifrato separato dal sistema operativo, e di uno storage di archivio cifrato per prove a lungo termine. Progetta la migliore strategia di partizionamento e cifratura per i tre dischi che abbiamo trovato."

Vedi la differenza? Stai consegnando vincoli e obiettivi, non microgestendo la soluzione. Se il ragionamento che ricevi è solido, lo sarà anche il progetto. E se una scelta non ha senso, lo noterai perché capisci cosa deve fare davvero la tua macchina.

Classificare i Carichi di Lavoro per Comportamento del Disco

La prima cosa da chiarire è la separazione dei carichi di lavoro per pattern di IO. Non per dimensione, non per importanza, ma per come ogni carico di lavoro accede effettivamente al disco.

Le Tre Corsie

• Alto IOPS, bassa latenza = NVMe. Qui vivono il sistema operativo, Docker, i database e i modelli AI. Questi carichi di lavoro eseguono molte letture e scritture casuali di piccole dimensioni. Hanno bisogno dello storage più veloce disponibile.
• Spazio scratch veloce, isolato = SSD. Lo spazio di lavoro di analisi va qui. Ha bisogno di una velocità decente per elaborare le catture ed eseguire gli strumenti, ma soprattutto deve essere separato dal disco del sistema operativo. Se il lavoro di analisi corrompe un filesystem o riempie un disco, il sistema operativo continua a funzionare.
• Grande capacità, scritture sequenziali = HDD. Storage di archivio a lungo termine per pcap, esportazioni di prove e backup. Le prestazioni di scrittura sequenziale vanno bene. La capacità conta più della velocità.

Questa separazione da sola previene il modo più comune di fallire: un carico di lavoro che affama un altro di IO del disco o di spazio.

Perché Ogni Servizio Ha il Suo Volume Logico

Non fermarti ai tre dischi. Sull'NVMe, suddividi lo spazio in sei volumi logici separati, ciascuno per un motivo specifico:

• /var/lib/docker viene isolato perché Docker consuma disco in modo imprevedibile. Una build di container impazzita o una cache di immagini dimenticata non dovrebbe poter riempire root.
• /var/lib/postgresql viene isolato per il dimensionamento indipendente, gli snapshot di backup e la futura ottimizzazione delle prestazioni. I database hanno pattern di IO unici che beneficiano di spazio dedicato.
• /var/lib/ollama viene isolato perché i modelli AI sono enormi e crescono in modo indipendente. Un singolo LLM può pesare 8 GB o più. Non vuoi che i download dei modelli competano con il sistema operativo per lo spazio.
• /home viene isolato in modo che i dati utente, i dotfile e le configurazioni personali sopravvivano alle reinstallazioni del sistema operativo.
• swap come proprio volume logico, dimensionato per supportare l'ibernazione se necessario.
• root (/) limitato a una dimensione fissa in modo che nulla al di fuori dei percorsi designati possa riempirlo. Se root si riempie, il sistema smette di funzionare. Limitarlo è una scelta progettuale difensiva.

La Cifratura Non è Opzionale

La cifratura non è opzionale qui, e il ragionamento è semplice. Questa è una macchina in formato laptop che funziona come workstation di sicurezza e archivia dati sensibili a riposo: catture honeypot, artefatti di attacco, risultati di analisi di rete. Se la macchina viene rubata, persa o dismessa, ogni disco deve essere illeggibile senza la passphrase.

La cifratura completa del disco con LUKS è il minimo indispensabile per questo caso d'uso. Punto.

Lascia Spazio di Manovra nel Gruppo di Volumi

Questo dettaglio distingue un buon progetto LVM da un lavoro amatoriale. Lascia circa il 5-10% del tuo gruppo di volumi non allocato. Non sprecato. Riservato. Ecco perché:

Con LVM, puoi espandere i volumi logici al volo senza riavviare. Se Docker ha bisogno di più spazio tra sei mesi, estendi il LV e ridimensiona il filesystem in pochi secondi. Se avessi allocato tutto in anticipo, dovresti ridurre un volume per espanderne un altro, e ridurre è lento, rischioso e a volte impossibile con certi filesystem.

Lo spazio di manovra intenzionale è una funzionalità, non uno spreco.

Il Modello Mentale del Livello di Storage

Questo modello mentale è la cosa più preziosa da portare via da questo intero capitolo. Non le dimensioni delle partizioni. Non i punti di mount. Questo stack a 8 livelli che spiega come funziona davvero lo storage Linux, dall'alto verso il basso.

La maggior parte degli errori che incontrerai durante l'installazione vera e propria, specialmente con fstab e crypttab nella Parte 3, derivano dal confondere questi livelli. Scrivere un UUID dal livello 2 dove era atteso il livello 6. Fare riferimento a un percorso dispositivo dal livello 3 in una configurazione che richiedeva il livello 1. Ogni errore di storage riconduce a un'incompatibilità di livello.

Metti questo stack tra i preferiti. Tatuatelo sull'avambraccio. Una volta che interiorizzate questi otto livelli, lo storage Linux smette di essere misterioso. Sono solo otto cose, ciascuna che fa un lavoro, collegate in ordine.

Il Layout NVMe Finale

Ecco il progetto completo per l'unità NVMe primaria:

NVMe Primario (nvme0n1)

All'interno del contenitore LUKS su nvme0n1p3:

nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (Gruppo di Volumi)

Dischi Secondari

SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis

HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive

Tre dischi cifrati. Sei volumi logici sul primario. Ogni carico di lavoro nella propria corsia. Niente condivide spazio con ciò con cui non dovrebbe.

Trasformare il Design in uno Script di Build

Una volta che il design è definito, il prompt successivo è semplice:

"Dammi i comandi esatti per costruire questo intero layout di archiviazione dall'ambiente Kali live. Supponi che tutti e tre i dischi possano essere cancellati."

Chiedi uno script shell completo: cancella le firme esistenti, crea tabelle di partizione GPT, suddividi le partizioni con sgdisk, crea container LUKS2 con impostazioni predefinite robuste, aprili, inizializza i volumi fisici LVM, crea il gruppo di volumi, alloca tutti e sei i volumi logici, formatta tutto, poi ripeti la configurazione LUKS per l'SSD e l'HDD.

Aspettati circa 80 righe. Ogni comando deve essere verificabile. Se qualcosa nello script non ti è chiaro, chiedi all'AI di spiegare quella riga specifica prima di eseguirla.

Cosa Andrà Storto (E Non Sarà il Design)

Avviso giusto: il design sarà solido. L'esecuzione ti darà filo da torcere. Ecco le trappole a cui prestare attenzione:

Terminazioni di riga Windows. Se scrivi lo script su una macchina Windows e lo trasferisci nell'ambiente live tramite USB, ogni riga termina con \r\n invece di \n. Bash si blocca su ogni singolo comando e i messaggi di errore sono criptici. Correggilo con sed -i 's/\r$//' script.sh prima di eseguire qualsiasi cosa.

Corruzione dello shebang. Correlato al problema delle terminazioni di riga. La riga #!/bin/bash riceve un ritorno a capo invisibile, quindi il kernel non riesce a trovare l'interprete. L'errore sembra indicare che lo script non esiste, anche se è chiaramente presente.

Confusione dei percorsi. L'USB viene montata in un percorso, ma stai facendo riferimento allo script da una directory di lavoro diversa. Il completamento con Tab e i percorsi relativi in un ambiente live sono inaffidabili quando stai gestendo più punti di mount. Usa percorsi assoluti.

Sintassi di esecuzione errata. Dimenticare ./ prima del nome dello script, o non impostare prima i permessi di esecuzione. Errori classici che non hanno nulla a che fare con il design dell'archiviazione e tutto con la memoria muscolare.

"L'AI può scrivere lo script, ma devi comunque capire quello che stai incollando. Se un comando non ti è chiaro, fermati e chiedi."

Una volta risolti i problemi di terminazioni di riga ed esecuzione, la build dell'archiviazione si completa in meno di due minuti. Ogni container LUKS si apre. Ogni struttura LVM viene creata correttamente. Ogni filesystem viene formattato. Il design regge.

Verifica Tutto con il Pattern Incolla-e-Controlla

Non dare per scontato il successo. Dopo che lo script termina, incolla l'output del terminale nell'AI e chiedi di verificare il risultato:

"Ecco il mio output di lsblk e lvs. È andato tutto bene?"

Incolla l'output grezzo del terminale e chiedi all'AI di analizzarlo riga per riga. Dovrebbe confermare: cryptnvme attivo, vgkali presente con sei volumi logici alle dimensioni corrette, filesystem corretti su ciascuno, dischi secondari cifrati e formattati.

Questo pattern incolla-e-verifica è una delle tecniche più utili per l'amministrazione di sistema con l'AI. Esegui un comando, incolli l'output e chiedi se la realtà corrisponde al piano. Individua problemi che ti sfuggirebbero perché sei troppo immerso nel lavoro:

• Un volume logico formattato accidentalmente con il tipo di filesystem sbagliato
• Un volume dimensionato in megabyte quando intendevi gigabyte
• Una partizione mancante che lo script ha saltato silenziosamente
• Un container LUKS che in realtà non si è aperto

Puoi farlo con quasi qualsiasi stato del sistema: lsblk, lvs, pvs, vgs, blkid, fdisk -l, cryptsetup status. Incollalo. Chiedi all'AI di verificarlo. È più veloce e più accurato che controllare tutto da soli.

Il Punto Chiave: Progetta dai Carichi di Lavoro, Non dai Default

Il layout di archiviazione qui non è stato scelto da un template o copiato da un post su un forum. È stato derivato dai requisiti effettivi del carico di lavoro. Docker ha bisogno di isolamento dello spazio. I database hanno bisogno di IO dedicato. I modelli AI hanno bisogno di spazio per crescere. Gli artefatti di sicurezza hanno bisogno di cifratura a riposo. Gli archivi hanno bisogno di capacità più che di velocità.

Ogni decisione risale a un requisito reale. Questa è la differenza tra un layout di archiviazione che dura sei mesi e uno che crolla al primo imprevisto.

Questo approccio funziona per qualsiasi build, non solo per le workstation di sicurezza. Di' all'AI cosa farà la macchina. Descrivi i servizi, i pattern dei dati, le aspettative di crescita, gli scenari di guasto che vuoi superare. Poi lascia che sia lei a capire come organizzare i dischi. Il ragionamento che ti mostra è più prezioso della tabella delle partizioni finale, perché capirai perché ogni scelta è stata fatta e quando potrebbe essere necessario cambiarla.

I tuoi dischi sono partizionati, cifrati e suddivisi in volumi logici. L'architettura è completata. Ora arriva la parte che mette davvero in difficoltà: installare un OS su tutto questo senza un installer grafico che ti guidi passo dopo passo.

In Parte 3: Installazione Manuale, monterai i volumi cifrati, farai il bootstrap di Kali da zero, configurerai fstab e crypttab affinché tutto si sblocchi all'avvio, e costruirai una configurazione funzionante del bootloader. È qui che il modello a 8 livelli viene messo alla prova sul serio, e dove un UUID sbagliato può lasciarti a fissare un prompt di salvataggio di GRUB. Portati un caffè.