Category Archives: Recensione

Filesystem cifrati (parte 2)

Su un PC con CPU Intel i7-4790K (dotata di accelerazione hardware per l’algoritmo di cifratura aes), 16GB di RAM ed hard disk Seagate Barracuda 7200 da 500GB il supporto per la cifratura integrato nel filesystem ext4 è stato quello che si è comportato meglio in assoluto, con velocità in scrittura praticamente identiche a quelle di ext4 con la cifratura disabilitata. dm-crypt/LUKS è stato più veloce di ZFS con file sotto ai 5 GB. gocryptfs come prevedibile, in quanto strumento user-space, è stato il filesystem più lento tra i 4.

Dettagli del test

Sono state create 3 partizioni sul disco:

  • una formattata con ext4 (con due cartelle da cifrare rispettivamente con FScrypt e gocryptfs),
  • un volume dm-crypt/LUKS formattato in ext4
    # cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 /dev/sdc2
    # cryptsetup open /dev/sdc2 lukspart
    # mkfs.ext4 /dev/mapper/lukspart
  • un pool ZFS col dataset cifrato
    zpool create tank /dev/sdc3
    zfs create -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=prompt tank/encrypted_data
    zfs load-key tank/encrypted_data
    zfs mount tank/encrypted_data

Ho generato con dd 3 file rispettivamente da 1GB, 5GB e 10GB contenenti bit casuali

dd if=/dev/urandom of=testfile1G bs=1G count=1 oflag=direct
dd if=/dev/urandom of=testfile5G bs=1M count=5120 oflag=direct
dd if=/dev/urandom of=testfile10G bs=2M count=5120 oflag=direct

Con rsync ho misurato la velocità di trasferimento di questi file nelle varie partizioni o directory cifrate e per confronto anche con la semplice copia in una partizione ext4 non cifrata. Dopo ogni copia, per pulire la cache ho lanciato il comando “echo 3 > /proc/sys/vm/drop_caches”

time rsync --progress testfile1G /mnt/“filesystemcifrato“
time rsync --progress testfile5G /mnt/“filesystemcifrato“
time rsync --progress testfile10G /mnt/“filesystemcifrato“

Velocità in lettura

Per completezza ho misurato anche le velocità di lettura col comando:

time dd if=testfile5G of=/dev/null bs=1G count=1

Filesystem cifrati (parte 1)

Microsoft supporta la cifratura del disco da Windows 7 e da Windows 11 è attivata di default.
Anche Linux la supporta da moltissimo tempo e svariati progetti si sono susseguiti o affiancati nel tempo: il pionieristico CFS (1993), loop-AES (2001), cryptoloop (2002), dm-crypt (2003), EncFS (2003) e eCryptFS (2006).

Al momento le principali implementazioni crittografiche opensource disponibili su Linux sono:

  • dm-crypt/LUKS: tuttora lo standard della crittografia del disco su Linux. Funziona a livello di block device ed è trasparente per il filesystem (stile LVM), permette quindi la cifratura di interi dischi, partizioni o volumi logici.
  • fscrypt (2016): un framework di crittografia che opera a livello di file e directory anziché di device come LUKS. È integrato direttamente nel filesystem ext4 e F2FS (a “breve” dovrebbe utilizzabile anche su Btrfs). È utile se ci si vuol limitare a proteggere specifiche directory, magari per non sovraccaricare il sistema cifrando l’intero disco.
  • gocryptfs (2015): a differenza dei precedenti funziona in user-space tramite tramite FUSE. Come FScrypt permette la creazione di directory cifrate, ma al contrario di quest’ultimo non consente l’oscuramento dei metadati (timestamp, permessi).
  • ZFS (2019): permette di cifrare i dataset (sottovolumi). Purtroppo non essendo integrato nel kernel Linux è supportato nativamente da poche distribuzioni (Gentoo, NixOS, Proxmox…).

Quale scegliere?
Se si vuole cifrare l’intero disco probabilmente dm-crypt/LUKS è la scelta ideale, se si utilizza ext4 e ci si accontenta di cifrare solo qualche directory forse è FScrypt l’opzione migliore, se non si può fare a meno di un filesystem moderno come btrfs (che però manca ancora il supporto della cifratura) la soluzione più semplice è qualcosa che operi in user-space come gocryptfs. Se siete abbastanza avventurosi con ZFS potrete godere di una miriade di funzionalità, crittografia compresa.

Ma come si comportano sul campo questi filesystem?

Ho deciso di metterli alla prova su un Seagate Barracuda 7200 da 500GB su un moderno Intel i7-4790K con 16GB di RAM e su un più stagionato Pentium Dual-Core E5800 con 4GB RAM.

A breve l’esito dei test…

Ci faccio un serverino (parte 2)

C’eravamo lasciati con una domanda: quale fosse il sistema operativo migliore per spremere al meglio quel Pentium 200 con 48MB RAM, hard disk da 2GB e scheda ethernet NE2000.

Il collo di bottiglia di quel bolide era la scheda di rete ISA a 10Mbit e tutti i sistemi operativi provati hanno superato abbondantemente il limite di trasferimento di 900 KB/s di quella scheda, quindi probabilmente anche DOS non ci avrebbe sfigurato.
Per dare comunque un senso a questo test, ho installato sulla replica di quel PC una scheda di rete RTL8139C PCI a 100 Mbps ed ho provato a spremerlo con alcuni trai principali OS per server disponibili all’epoca:

  • Windows 2000 Server: facciamo lo sforzo di fantasia di immaginare uno studente 19enne con $999 da buttare investire per il sistema operativo del suo serverino domestico
  • Debian Woody 3.0 (kernel 2.4.18): la distribuzione più di cool disponibile in quel momento
  • Linux Mandrake 9.0 Dolphin (kernel 2.4.19): la distribuzione che usavo sul desktop di tutti i giorni
  • OpenBSD 3.1: perché davvero la usai su quel PC (anche se non quella specifica versione), per vedere come si comporta un sistema BSD su quell’hardware e perché il suo sistema di base comprende server web ed ftp, così non devo ingrullire a cercare pacchetti su mirror di mirror di mirror sperando che il sysadmin si sia scordato di cancellarli
  • SCO Openserver 5.0.6: nello stesso mondo immaginario in cui posso spendere due milioni di lire per Windows server non ho difficoltà a tirare fuori un milione e mezzo per acquistare la licenza base dello SCO UNIX

Come avevo già fatto per il test su macchina virtuale, anche qui ho misurato la velocità di trasmissione via http col tool ab con un carico di 100 connessioni simultanee per un totale di 10000 connessioni caricando un documento da 18,6 KB. Per verificare la velocità massima di trasferimento via ftp ho invece eseguito 5 upload e 5 download di un file da 100 MB, ho fatto la media dei tempi e ne ho calcolato la velocità.

Con mia grande sorpresa Windows 2000 ha battuto la concorrenza in 2 prove su 3: distribuzione di pagine html statiche e upload via ftp (apprezzate l’onestà perché avrei potuto insabbiare tutto). Mandrake, pur essendo una distribuzione orientata all’uso desktop, si è comportata molto bene superando Debian in ben 2 prove. La cosa che più mi ha infastidito di Mandrake è stata il suo lunghissimo tempo di avvio: quasi 2 minuti contro i 30 secondi circa di tutti gli altri sistemi operativi. OpenBSD si è difeso bene mantenendo valori intermedi in tutte le prove. SCO Openserver, come già era successo nei test su macchina virtuale, è stato il sistema operativo più lento in tutte le prove. A titolo informativo segnalo che SCO è stato di gran lunga il più lento nel processo di installazione, durato oltre un’ora e mezzo, ed è stato l’unico sistema operativo a non supportare nativamente l’RTL8139.

Classifiche

WEB server
1) Windows 2000
2) Debian Woody
3) Linux Mandrake 9.0
4) OpenBSD 3.1
5) SCO Openserver 5.0.6

FTP-UPLOAD
1) Windows 2000
2) Linux Mandrake 9.0
3) OpenBSD 3.1
4) Debian Woody
5) SCO Openserver 5.0.6

FTP-DOWNLOAD
1) Mandrake 9.0
2) OpenBSD 3.1
3) Debian Woody
4) Windows 2000
5) SCO Openserver 5.0.6

WINDOWS 2000
IIS/5.0
WEB UP: 4600 KB/s

FTP RX: 4100 KB/s
FTP TX: 2800 KB/s		Mandrake 9.0 (2.4.19)
Apache/1.3.26
WEB UP: 3180 KB/s
Proftpd 1.2.5
FTP RX: 3600 KB/s
FTP TX: 4950 KB/s		Debian Woody (2.4.18)
Apache/1.3.26
WEB UP: 3560
Proftpd 1.2.4+1.2.5RC
FTP RX: 2425
FTP TX: 3028
OpenBSD 3.1
Apache/1.3.24
WEB UP: 1595 KB/s
OpenBSD FTPD
FTP RX: 2450
FTP TX: 3550		SCO Openserver 5.0.6
Netscape-FastTrack/2.01
WEB UP: 1315 KB/s
WU-FTP2.1+SCO-2.6.1
FTP RX: 1845
FTP TX: 1806

Ethernet negli anni ’90, tra lusso e made in China

Nel 1995, se avevi bisogno di mettere in rete dei computer, era molto probabile che finissi per acquistare, alla “modica” cifra di 150-200 mila Lire, una 3Com 509 EtherLink III. Era considerata la scheda di rete ISA a 10 Mbps più affidabile e performante dell’epoca, anche perché la 3Com vantava un pedigree di tutto rispetto: fu infatti fondata da Robert Metcalfe, uno degli inventori del protocollo Ethernet.

Pochi anni più tardi, Novell (leader del mercato delle reti aziendali con il suo sistema operativo NetWare) decise di dare una spintarella (disinteressata) al mercato delle schede di rete, introducendo due modelli a basso costo: la NE1000 (ISA, 10 Mbps) e la NE2000 (PCI, 10/100 Mbps). Ebbero anche un’idea tanto semplice quanto efficace: rilasciarne pubblicamente le specifiche per permettere a qualsiasi azienda di produrne dei cloni.

Tra questi, uno dei più diffusi fu la RTL8019AS, realizzata dalla taiwanese Realtek a partire dal 1996. Prodotto economico (costava circa 50-60 mila Lire) che manteneva lo standard ISA a 10 Mbps offrendo così una soluzione accessibile per espandere le reti locali.

Questa strategia contribuì enormemente alla diffusione delle LAN e di conseguenza di NetWare, almeno fino all’avvento di Windows NT4. Tuttavia, era opinione diffusa che questi cloni fossero di qualità inferiore rispetto alle più blasonate 3Com che pare avessero un controller integrato che svolgeva gran parte del lavoro di elaborazione, riducendo così il carico sulla CPU del computer e migliorando le prestazioni complessive. Si alimentò quindi un tediosissimo dibattito tra prestazioni e convenienza che giunse al termine soltanto verso il 2000, con l’uscita della Realtek 8139, la prima scheda di rete 100Mbit universalmente riconosciuta come economica e performante.

Ma quanto c’era di vero in quelle affermazioni e quanto invece era FUD? Un dato oggettivamente vero era che a differenza delle 3Com alcune NE1000 non erano Plug&Play e poteva occorrere un’utility DOS o lo spostamento manuale di alcuni jumpers per configurarne IO e IRQ

Per verificare il resto ho deciso di rispolverare un Pentium 133 di quell’epoca, equipaggiato con 64MB RAM, 128 di Swap e Debian Woody con kernel 2.4.18. Ci ho montato simultaneamente tutte e 4 schede di rete in questione ed ognuna è stata messa alla prova trasferendovi in upload (TX) ed in download (RX) per 10 volte un file da 100MB via ftp.
Per non aggiungere ulteriori variabili, il server ftp non si trovava sul P133. Ho anche effettuato anche svariate misurazioni in RX tramite http ed i valori ottenuti sono risultati perfettamente in linea con quelli registrati via ftp.

  • 3Com EtherLink III 3C509 (ISA, 10 Mbps), modulo 3c509: RX 736 KB/s, TX 905 KB/s
  • RTL8019AS (ISA, 10 Mbps), modulo ne: RX 703 KB/s, TX 940 KB/s
  • RTL8029AS (PCI, 10 Mbps), modulo ne2k-pci: RX 735 KB/s, TX 989 KB/s
  • RTL8139C (PCI, 100 Mbps), modulo 8139too: RX 2425 KB/s, TX 3028 KB/s
    (Da notare come in tutti i casi la velocità in trasmissione sia risultata maggiore di quella in ricezione di quasi 1/3)

Attraverso il tool iperf ho misurato le velocità di trasmissione e ricezione sul protocollo UDP (così da bypassare eventuali latenze legate al TCP)
iperf -c 192.168.178.xxx -u -b 1000M -l 1470 -t 10 -i 1

  • 3Com 509 ISA: RX 9.56 Mbits/sec, TX 9.89 Mbits/sec
  • RTL8019AS ISA: RX 9.56 Mbits/sec, TX 9.44 Mbits/sec
  • RTL8029AS PCI: RX 9.56 Mbits/sec, TX 9.51 Mbits/sec
  • RTL8139C PCI: RX 62.2 Mbits/sec, TX 93.4 Mbits/sec

Al contrario di quanto veniva detto la scheda RTL8019AS, il clone NE su ISA, ha ottenuto velocità in trasmissione e ricezione paragonabili a quelle della famigerata 3Com ed al suo successore RTL8029AS su BUS PCI.
Chissà se effettuando i test su un 386 o 486 sarebbe potuto risultare più evidente il fantomatico maggiore carico sulla CPU di una NE compatibile rispetto alla 3Com. A quanto pare con Linux anche un P133 con 64MB di RAM era già in grado di compensare le presunte incolmabili inefficienze dell’economica RTL8019.

The old good Linux vs Windows

Leave a reply

Tra la fine degli anni ’90 ed i primi del 2000, sul web e nelle riviste di informatica, erano piuttosto popolari benchmark in cui venivano confrontate le prestazioni tra server Windows e Linux. Inizialmente l’interesse era rivolto soprattutto al trasferimento di file tramite SMB, poi col diffondersi sempre più prepotente delle dot.com, l’attenzione deviò verso i server web.

Spesso i primi test erano direttamente o indirettamente sponsorizzati da Microsoft, fino a quando (circa nel 2001) Linux con Samba iniziò a battere Windows sul suo stesso campo, vale a dire nelle performance sul file sharing via smb [1]. Gli amanti dell’argomento potranno trovare pane per i loro denti a questo indirizzo.

Ma tornando a noi… quando una persona con tratti di personalità ossessiva e paranoide è anche amante del retrocomputing ci sta che dopo un quarto di secolo possa voler controllare se quei test corrispondessero al vero o se fossero stati un mero esercizio di fantasia. Una quindicina di anni fa avevo già dato sfoggio di certe mie discutibili fissazioni in questo test, ma adesso ho deciso di rilanciare con un confronto a 5 tra i sistemi operativi per server più diffusi nel 2001:

  • Windows NT4: $800-$1.200
  • Windows 2000: $999
  • RedHat 7.1: scaricabile gratuitamente, $59.95 versione CD-ROM completa dei manuali cartacei, $79.95-$199 CD-ROM + manuali + vari livelli di supporto tecnico
  • Slackware 8: scaricabile gratuitamente, $39.95 versione CD-ROM, $199 CD-ROM + manuali cartacei
  • SCO Openserver 5.0.6: $695-$1,395

Per pigrizia praticità ho effettuato tutte le prove su una macchina Virtualbox con le seguenti caratteristiche: 1xCPU 2GHz, 512MB RAM, HD IDE PIIX4 da 8 GB, scheda di rete AMD PCNET-FastIII.

Per misurare le performance dei server web ho usato il tool ab effettuando un carico di 100 connessioni simultanee per un totale di 10000 connessioni con un documento da 18,6 KB.

IIS è andato meglio di quanto immaginassi, sia su NT4 che su Windows 2000 ha sopportato molto meglio i maggiori carichi di traffico rispetto ad Apache 1.3.19 e al Netscape FastTrack 2.01. Interessante notare come IIS/3 su NT4 sia andato meglio del suo successore su Windows 2000! Apache è invece riuscito ad essere competitivo solo dalla versione 1.3.20 (rilasciata a maggio 2001), quella presente di serie sulla Slackware 8 uscita a luglio, ma non ancora disponibile per RedHat 7.1 che invece era stata rilasciata a marzo. Ho voluto testare anche l’accoppiata RedHat 7.1 – Apache 1.3.27 dato che nel 2003 questa versione fu rilasciata come aggiornamento ufficiale e (casualmente?) ha dimostrato di essere (anche se non di molto) il web server più veloce tra quelli esaminati.

  1. RedHat 7.1 / Apache 1.3.27: 3.505 secondi
  2. Slackware 8 / Apache/1.3.20: 3.584 secondi
  3. MS Windows NT4-IIS/3.0: 3.616 secondi
  4. MS Windows 2000-IIS/5.0: 4.979 secondi
  5. RedHat 7.1 / Apache 1.3.19: 8.966 secondi
  6. SCO Openserver 5.0.6 / Netscape-FastTrack/2.01: 16.529 secondi

Per quanto riguarda i test di velocità di trasferimento via FTP ho utilizzato il semplice comando time.

  • Prova 1: Upload di un file da 1,35 GB
  1. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 9.75 secondi
  2. MS Windows NT4-IIS/3.0: 10.79 sescondi
  3. MS Windows 2000-IIS/5.0: 14.29 secondi
  4. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 16.11 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 73.44 secondi
  • Prova 2: download di un file da 1,35 GB
  1. MS Windows NT4-IIS/3.0: 14.49 secondi
  2. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 18.72 secondi
  3. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 24.26 secondi
  4. MS Windows 2000-IIS/5.0: 33.10 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 55.04 secondi

Prova 3: upload simultaneo di 10 file da 90MB

  1. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 9.67 secondi
  2. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 12.12 secondi
  3. MS Windows NT4-IIS/3.0: 13.26 secondi
  4. MS Windows 2000-IIS/5.0: 13.29 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 44.65 secondi

Prova 4: download simultaneo di 10 file da 90MB

  1. RedHat 7.1 / Wu-ftpd 2.6.1 (xinetd): 6.30 secondi
  2. MS Windows NT4-IIS/3.0: 11.56 secondi
  3. Slackware 8 / ProFTPD 1.2.2rc3 (inetd): 16.45 secondi
  4. MS Windows 2000-IIS/5.0: 20.12 secondi
  5. SCO Openserver 5.0.6 / Wu-ftpd 2.4.2: 34.75 secondi

SCO Openserver è stata la sorpresa negativa di questa batteria di test. Per chi non lo conoscesse si tratta di un sistema UNIX proprietario per macchine x86 standard basato sul SystemV 3.2 dell’AT&T e rifinito con l’aggiunta di varie applicazioni opensource come Wu-FTPd e proprietarie come appunto Netscape-FastTrack. In tutte le situazioni SCO Openserver 5.0.6 si è dimostrato molto più lento rispetto a tutti gli altri concorrenti, c’è da sperare che l’assistenza tecnica di SCO fosse oltremodo fantastica per giustificarne la preferenza rispetto ad un qualsiasi sistema Linux.
Il 2001 è stato probabilmente l’anno in cui, a livello server, Linux ha raggiunto e probabilmente superato Windows in termini di prestazioni. Mentre il sistema operativo di Redmond non è drasticamente migliorato dal ’96 al 2000, la comunità opensource ha fatto passi da gigante per rendere sempre più competitivi gli applicativi liberi nei settori più strategici di Internet: web server, server ftp, mail server, router-firewall e database service.

Hardware e tempo permettendo in futuro potrebbero uscire retro-recensioni di sistemi della prima metà degli anni ’90, stay tuned!