Costruito dai Primi Principi

Nessun runtime. Nessun garbage collector. Nessun overhead di framework. Ogni riga di Flashstor è scritta in C11 per il massimo controllo su memoria, I/O e risorse di sistema.

Fondamenta Tecnologiche

Quattro pilastri di eccellenza ingegneristica

C11 (ISO/IEC 9899:2011)
Standard C moderno con tipi _Atomic, static_assert, struct anonime. Conforme POSIX con -Wall -Wextra -Wpedantic. Compilato con protezioni stack, FORTIFY_SOURCE=3 e RELRO completo.
Intel ISA-L e ISA-L Crypto
Erasure coding accelerato SIMD (Reed-Solomon su GF(2^8)) con AVX2/AVX-512 e crittografia AES-256-GCM accelerata hardware via AESNI. Fino a 65x più veloce del C puro.
Event Loop epoll / kqueue
I/O event-driven nativo: epoll su Linux, kqueue su BSD/macOS, event ports su SunOS. Pool di thread worker configurabile con pool I/O dedicato per operazioni sugli shard.
HTTP/2 via nghttp2
Supporto completo HTTP/2 su TLS (h2 via ALPN) e cleartext (h2c). Keep-alive HTTP/1.1 con max richieste per connessione configurabile (default: 1.000).

Ciclo di Vita della Richiesta

Ogni richiesta S3 segue una pipeline deterministica a quattro fasi

1

Accettazione e Parsing

La event loop accetta la connessione tramite epoll/kqueue. Gli header HTTP vengono analizzati in buffer arena pre-allocati. Timeout anti-slowloris applicato alla ricezione degli header. La richiesta viene instradata al gestore tramite tabella di dispatch.

2

Autenticazione e Autorizzazione

Firma SigV4 verificata con CRYPTO_memcmp timing-safe. Policy IAM valutate nel contesto della richiesta con cache epoch per thread (hit rate quasi 100% su connessioni keep-alive). Token STS validati.

3

Esecuzione e Risposta

L'operazione viene inviata al gestore. I dati vengono frammentati tramite routing CRC32, codificati con erasure coding ISA-L SIMD e scritti sui dischi in parallelo tramite pool di thread I/O. La risposta viene assemblata con invio zero-copy writev().

4

Pulizia e Riciclo

L'allocatore arena libera in blocco tutta la memoria per-richiesta in una singola operazione — zero chiamate free() individuali. La connessione viene restituita alla event loop per il riutilizzo keep-alive. Voce di audit log asincrona accodata nel ring buffer SPSC lock-free.

Memoria

Allocazione Arena: Zero Frammentazione per Design

Ogni connessione ottiene un allocatore arena dedicato con blocchi riutilizzabili da 64 KiB. Tutte le allocazioni per-richiesta avvengono all'interno dell'arena. Quando la richiesta è completata, l'intera arena viene resettata in O(1) — nessuna chiamata free() per oggetto, nessuna frammentazione, nessun GC.

  • Blocchi arena da 64 KiB — riutilizzati tra le richieste, mai restituiti al SO
  • ~75 KiB di base per connessione (arena + buffer I/O)
  • Deallocazione in blocco al completamento della richiesta — singolo reset del puntatore
  • Modalità debug: tracciamento per-allocazione con rilevamento perdite
// Allocatore arena — semplificato
arena_t *a = arena_create(65536);
// Fast bump allocation
void *buf = arena_alloc(a, size);
void *hdr = arena_alloc(a, hdr_sz);
// Request complete — free everything
arena_reset(a); // O(1), no free()

Architettura Cluster Distribuita

Erasure set distribuiti tra i nodi con consenso basato su quorum

Nodo Gateway

Accetta richieste S3 API, esegue autenticazione SigV4, instrada le operazioni verso l'erasure set corretto tramite hashing deterministico basato su CRC32.

Nodo Storage

Gestisce i dischi locali con implementazione vtable xl_storage. Gestisce erasure coding, verifica bitrot e I/O a livello di shard con operazioni disco parallele.

Nodo Peer

Storage remoto accessibile tramite vtable rest_storage su HTTP. Partecipa al locking distribuito, quorum dei metadati e replica tra nodi.

Canali di Comunicazione

Port 9000
S3 API
API REST S3 lato client con supporto HTTP/1.1 e HTTP/2.
Port 9001
Admin API
API di gestione con autenticazione bearer token HMAC-SHA256 per operazioni cluster.
Port Internal
Peer RPC
Comunicazione REST inter-nodo per locking distribuito, sincronizzazione metadati e replica dati.
Sicurezza

Modello di Separazione dei Privilegi

Flashstor segue il principio del minimo privilegio con un ciclo di vita della sicurezza a quattro fasi che minimizza la superficie di attacco a runtime.

Phase 1

Inizializzazione come Root

  • • Bind della porta privilegiata (es. 443 per HTTPS)
  • • Caricamento certificati TLS da --certs-dir
  • • Inizializzazione tabelle di dispatch ISA-L SIMD
Phase 2

Rilascio dei Privilegi

  • • Passaggio a FLASHSTORE_RUN_USER / FLASHSTORE_RUN_GROUP
  • • Impostazione PR_SET_NO_NEW_PRIVS su Linux (impedisce la ri-escalation)
  • • Utilizzo del modello capabilities su SunOS/illumos
Phase 3

Hardening a Runtime

  • • RELRO completo — nessuna voce GOT scrivibile dopo l'avvio
  • • -fstack-protector-strong con protezione stack canary
  • • Control-Flow Integrity (-fcf-protection su x86_64)
  • • -D_FORTIFY_SOURCE=3 per il rilevamento di buffer overflow
Phase 4

Audit e Monitoraggio

  • • Log di audit JSON asincroni tramite ring buffer SPSC lock-free
  • • ID di traccia per-richiesta con tempi delle operazioni
  • • Metriche Prometheus per eventi rilevanti per la sicurezza

Domande Tecniche? Parliamo di Architettura.

Il nostro team è disponibile per discussioni tecniche approfondite su gestione della memoria, modelli I/O, sicurezza e progettazione di sistemi distribuiti.

Richiedi Demo Vedi Prestazioni