Author Archives: giomba

Linux Day 2020

Il Linux Day è un’iniziativa distribuita dedicata alla promozione e alla divulgazione di GNU/Linux, del software libero, dell’utilizzo di sistemi aperti, dei dati liberamente fruibili e dei protocolli standard nell’ambito delle nuove tecnologie.

Abitualmente si compone di numerosi eventi locali, ma, date le circostanze eccezionali che il nostro Paese sta vivendo, in occasione della sua ventesima edizione il Linux Day si svolgerà online in forma di conferenza nazionale unificata virtuale: tanti talk in diretta, tante sessioni parallele, e la possibilità di entrare in contatto con appassionati, curiosi, professionisti e volontari in ogni parte d’Italia!

L’evento si articolerà su un intero fine settimana sabato 24 e domenica 25 ottobre 2020, per un totale di 6 aree tematiche e 60 tra interventi e relatori.

Tutti i dettagli sul programma sono consultabili qui.

Radio Libera: Linux e la radio

In collaborazione con l’Associazione Radioamatori Italiani (ARI) del territorio, mercoledì 7 ottobre 2020, alle 21.15, la serata sarà volta a divulgare l’uso di Linux nel settore della sperimentazione radioamatoriale. Durante la serata vedremo quali sono i punti di contatti tra questi due mondi, quello degli smanettoni software e quello degli smanettoni hardware.

Come possiamo usare una SDR su Linux? Quali sono i vantaggi dei programmi open source nel mondo HAM? Dozzine di programmi si trovano su GitHub, come posso usarli?

La serata, a carattere introduttivo, avrà poi lo scopo di unire le energie dei vari gruppi e avviare nuove sperimentazioni su packet radio AX.25 e webSDR.

La serata potrà essere seguita presso la nostra Officina Informatica Remota grazie ai mezzi liberi di teleconferenza messi a disposizione dal GARR e dal progetto iorestoacasa.work.

LVM Cache su SSD

Stanco delle prestazioni da bradipo dell’emulatore di Android e della (ahimé talvolta necessaria) macchina virtuale con Windows, che grattano di continuo sul disco meccanico della mia home directory, ho deciso che era giunto il momento di intervenire, per evitare di trovarsi catapultati negli anni 90 ogni due minuti.

Per risolvere il problema prestazionale esiste una soluzione molto semplice: comprare un nuovo disco a stato solido, abbastanza capiente. Questa soluzione però non è sicuramente delle più economiche.

La soluzione arzigogolata e nerd invece è: usare un piccolo disco SSD d’avanzo come cache per il disco meccanico.

Configurazione iniziale

Qualche mese fa mi è capitata una rocambolesca avventura per cui ho rischiato di perdere tutti i miei dati per colpa di un programmatore di firmware distratto. Certo, avevo un backup, ma non è la stessa cosa.

Quel giorno comprai dei dischi nuovi e mi feci un bel RAID1, come in figura.

Configurazione attuale, lenta

Questa configurazione avrebbe dovuto aiutarmi a prevenire perdite di dati, e anche a migliorare le performance in lettura dei dischi. Tuttavia, come ben presto si è rivelato, le cose non stavano affatto così, almeno quando i dischi venivano (ab)usati dalle sopraccitate applicazioni, particolarmente avide di random IO.

Il sistema operativo risiede comunque su un disco SSD a parte.

Nuova configurazione

Avendo un disco SSD d’avanzo, che avevo usato per rinsavire il computer portatile che mi ha accompagnato per numerosi viaggi in treno avanti e indietro per l’Università, ho quindi deciso di modificare la mia configurazione nel seguente modo.

Nuova configurazione desiderata

In questo modo, ogni volta che viene effettuato un accesso ad un file sul mio filesystem, LVM si preoccupa di controllare se, per caso, tale accesso può essere fatto anche per mezzo di una copia che si trova sul disco SSD.

Sì, LVM probabilmente potrebbe gestire direttamente anche il RAID, ma per il momento ho preferito riutilizzare le conoscenze già acquisite e continuare a sfruttare il RAID con mdadm.

La torre di Hanoi

Mi sono fatto prestare un disco meccanico di capienza identica ai miei dall’Officina Informatica del GOLEM.

Copiare tutto su quel disco e ricopiare di nuovo sul RAID? No, ho già trovato un disco col firmware buggato, e non desidero trovarne altri. Figuriamoci usare un disco usato di recupero!

Fare una specie di torre di Hanoi e rischiare comunque di perdere i dati per qualche errore umano (da me commesso)? Sì, facciamolo.

Mi sono quindi portato nella seguente situazione, installando il disco meccanico di passaggio, nominato sdd.

Vecchia e nuova configurazione (parziale) a confronto.
A sinistra l’array md0, a destra md1.

Poiché è molto facile fare confusione con i nomi, e poiché LVM permette di usare nomi mnemonici, ho assegnato i seguenti nomi autoesplicativi ai vari componenti del mio spazio di archiviazione.

  • picostorage: il gruppo virtuale;
  • slowdino: il volume sul vecchio lento dinosauro meccanico (il RAID1);
  • fastrabbit: il volume sul nuovo veloce disco SSD;
  • metaguy: il volume per i metadati;

Ho impostato la nuova configurazione, ma con un disco mancante (in rosso in figura).

# mdadm --create /dev/md1 --level=mirror --raid-devices=2 /dev/sdd missing
# pvcreate /dev/md1
# vgcreate picostorage /dev/md1
# lvcreate --name slowdino --size 1t picostorage /dev/md1
# mkfs.ext4 /dev/picostorage/slowdino

Dopodiché ho avviato la copia dei dati.

# mount /dev/picostorage/slowdino /mnt/dst
# rsync -av /home/* /mnt/dst

E, mentre copiava, conscio del fatto che avrebbe impiegato diverso tempo, mi sono preparato a inserire la cache.

# pvcreate /dev/sdc
# vgextend picostorage /dev/sdc
# lvcreate --name fastrabbit --size 64g picostorage /dev/sdc
# lvcreate --name metaguy --size 64m picostorage /dev/sdc
# lvconvert --type cache-pool --poolmetadata picostorage/metaguy picostorage/fastrabbit

Ho atteso la fine della copia dei miei dati, per evitare di abusare del povero disco SSD più del dovuto, dopodiché ho attivato la cache.

# lvconvert --type cache --cachepool picostorage/fastrabbit picostorage/slowdino

A questo punto, la cache è attiva. Non rimane che colmare il buco dell’array con uno dei dischi del vecchio array: simulo un guasto a uno dei dischi, lo rimuovo dall’array originale, cancello i metadati, e lo inserisco nel nuovo array.

# mdadm /dev/md0 -f /dev/sdb
# mdadm /dev/md0 -r /dev/sdb
# dd if=/dev/zero of=/dev/sdb bs=1M count=1
# mdadm /dev/md1 --add /dev/sdb

Mi trovo quindi in questa condizione, e attendo pazientemente che l’array su sdb venga ricostruito, controllandolo con mdstat.

Una volta ricostruito l’array correttamente su sdb e su sdd, ripeto l’operazione, simulando stavolta il fallimento di sdd, e inserendo nell’array sda. Al termine dell’operazione, mi trovo con i miei due dischi sda e sdb nella nuova configurazione, e posso restituire sdd al GOLEM.

In nessun momento di tutta questa procedura i miei dati sono stati su un disco soltanto, perciò si può dire che la procedura sia a prova di guasti hardware.

Non sono però sicuro che sia a prova di guasti umani, perciò non fatelo a casa. 🙂

Benchmark

Per verificare se davvero questa cache serve a qualcosa, faccio un veloce test.

$ fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=500M --readwrite=randrw --rwmixread=75

A fronte di circa 400 IOPS ottenute prima di installare la cache, adesso ne vengono fatte oltre 4000! 😮 Un risultato più che soddisfacente.

Anche durante l’uso delle applicazioni più avide, adesso la macchina risulta molto più fluida.

Il monitor di sistema mostra chiaramente i miglioramenti in lettura/scrittura dalla cache (in verde chiaro e fucsia), comparati con la lettura/scrittura dai dischi meccanici (in verde e rosso)

Manutenzione

Ogni tanto è bene controllare lo stato della cache e del RAID, e per questo ci vengono in aiuto i seguenti comandi:

# lvdisplay
# mdstat

Marzo 2020: dall’idea al circuito stampato

Posticipazione: su suggerimento delle autorità, e in via precauzionale per il contenimento della diffusione del nuovo Coronavirus, tutti gli incontri sono rimandati a data da destinarsi.

Visti i recenti sviluppi nell’attività di elettronica e open hardware portata avanti presso il GOLEM negli ultimi tempi, e grazie alla messa in funzione della fresa elettronica e della disponibilità della stampante 3D, per il mese di marzo 2020 è stato pianificato il seguente ciclo di serate a tema.

Scopo delle serate è analizzare il ciclo completo per la produzione di un circuito elettronico, facendo uso solo di strumenti opensource.

  • 10 marzo: Introduzione a KiCAD, software opensource di Electronic Design Automation, ossia di progettazione assistita al computer per circuiti elettronici. KiCAD permette di progettare ogni fase della realizzazione del circuito, dalla sua prima bozza, alla scelta e al posizionamento dei componenti, allo sbroglio delle piste, alla produzione dei file per lo stampaggio vero e proprio. Perché e come disegnare un circuito elettronico al computer? Come importare i componenti? Queste e altre le domande a cui cercheremo di dare risposta. Al termine della serata, il prodotto potrà essere mandato in stampa presso aziende specializzate tramite processi industriali, oppure potrà essere utilizzato la serata seguente.
  • 17 marzo: Introduzione a FlatCAM. Flatcam è un software che, a partire da file gerber o gcode, permette di passare all’incisione e all’intaglio vero e proprio del circuito tramite una macchina a controllo numerico. Al termine della serata, il prodotto potrà essere inciso tramite una CNC, come quella che abbiamo in officina, come vedremo nella serata successiva.
  • 24 marzo: Uso della fresa CNC del GOLEM. Il modo più veloce, economico e pulito per prototipizzare un circuito stampato, oggi, è tramite l’uso di una macchina a controllo numerico, che, partendo da delle basette completamente ricoperte di rame, le intaglia in maniera tale da ottenere le piste per il circuito stampato. La fresa, comandata dal sistema operativo a bassa latenza LinuxCNC, al termine della serata, produrrà il circuito stampato, sul quale sarà possibile saldare tutti i componenti, e potrà finalmente essere utilizzato. L’utilizzo della fresa sarà consentito solo al personale qualificato, che eventualmente provvederà a organizzare un corso per gli interessati.

Vi aspettiamo numerosi, come sempre, presso la nostra Officina Informatica, il martedì sera dalle 21.30! 🙂 E per qualunque informazione, siamo raggiungibili per mezzo dei nostri numerosi canali.

Rocambolesca riparazione di un hard disk Seagate

Connettore seriale TTL 3v3 di un disco Seagate

Quando il vostro hard disk improvvisamente smette di funzionare, senza aver mai dato nessun segnale premonitore, se è un Seagate forse potete sempre fare qualcosa.

Alcuni dischi Seagate Barracuda sono dotati di un firmware bacato (7200.11) che, in maniera del tutto casuale, va in blocco e impedisce del tutto la comunicazione SATA. In tale circostanza, il disco non viene più riconosciuto dal sistema operativo (fdisk, dmesg, syslog) né dal BIOS: appare insomma come se non fosse nemmeno attaccato al computer.

Si può tuttavia tentare un barbatrucco: resettare i dati SMART tramite l’interfaccia seriale di debug dell’hard disk. Questo metodo miracoloso dovrebbe dare il tempo necessario per ricopiare i preziosi dati su un altro supporto, possibilmente più affidabile.

In questa pagina archiviata (in inglese) si possono trovare tutte le istruzioni, da seguire alla lettera (non scherza, da seguire veramente alla lettera, compreso il collegare opportunamente tutte le masse).

Ora se volete scusarmi vado a casa a farmi venire un infarto.

Vincent Vega