Newsgroup: it.comp.os.linux.sys
Titolo: btrfs rebalance: atroce dubbio

sto per togliere un disco da un raid1 btrfs creato circa due anni 
addietro. 
Per farlo si puo' lanciare direttamente btrfs device delete /dev/xxx (che 
fa eventualmente il rebalancing), oppure, come ho fatto io, si può 
lanciare prima: 
btrfs balance /mount/point
 
Il risultato è che sta impiegando un sacco di tempo (e ancora lì che gira 
mentre sto scrivendo):
Mar 13 17:50:07 xxx kernel: [ 5842.590924] BTRFS info (device sdc1): 
relocating block group 743058702336 flags 17
Mar 13 17:50:15 xxx kernel: [ 5851.156535] BTRFS info (device sdc1): found 
7292 extents
 
perché? 
Domanda retorica: se si perde un disco che fine fanno i dati non 
sincronizzati? 
E' buona norma far girare btrfs balance in crontab? 
Avete esperienze di utilizzo di btrfs con raid? 
 
-- 
Massimiliano Adamo

 Avete esperienze di utilizzo di btrfs con raid?
 
Poca.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 (1) o ricostruibile dagli altri (5). 
 
eh, ma questo è quel che mi sarei aspettato e la norma è che tu usi 
'balance' *solo* quando aggiungi un nuovo device (per fare la 
'ricostruzione', 'resilvering'... chiamiamolo come ci pare). 
Ma, dopo due anni di egregio funzionamento, lancio il comando e lui inizia 
a controllare tutti gli extent e riposiziona tutti i cosiddetti chunks. 
La seconda volta che lancio il comando i chunk da riposizionare sono una 
infinità di meno e il tempo impiegato è pochissimissimo a confronto. 
A questo punto io deduco che i dati non erano in sync e un brivido mi 
corre lungo la schiena. 
 
C'è da dire che lo usano in facebook, e la cosa potrebbe essere 
consolante... ma probabilmente in facebook usano il raid hardware :)
 
resta comunque una grandissima figata. 
Alla fine per rompere il raid, bisogna riportare sullo stato di "single" i 
metadati, i dati e un'area (che non so bene cosa sia) che chiama system. 
Dopo aver bilanciato i dati, lancio il comando per ribilanciare metadati e 
system:
btrfs balance start --force -sconvert=single -mconvert=single /mount/point
 
e questo impiega veramente poco ... adesso (mentre ti scrivo sta ancora 
girando) ho lanciato il comando: 
btrfs device delete /dev/sdc1 /mount/point
 
stiamo a vedere .... 
 
OPS, ho finito il messaggio ed il comando è terminato adesso. Bye bye 
mirror :) 
 
non sono del tutto convinto di quel che ho visto... per darti una idea, il 
primo balance ha impiegato circa un'ora e mezza e il secondo moooltissimo 
meno. Vuol dire che i dati da spostare c'erano ed erano tanti. 
 
-- 
Massimiliano Adamo

 non sono del tutto convinto di quel che ho visto
 
non ci sto capendo una maz... "extent block groups" potrebbero essere gli 
spazi destinati alla memorizzazione degli extent. Per cui lui ha 
cominciato a riposizionare i "block groups"?
Ma i block groups, possono o meno contenere degli extent, ma se sono vuoti 
in entrambi i dischi non c'è nulla da riposizionare. 
 
Da un'altra parte, se li riposizioni, stai sincronizzando quelli del disco 
A, con quelli del disco B? Ma allora non stanno in sync? 
 
https://oss.oracle.com/~mason/btrfs/btrfs-design.html
 
 
 
-- 
Massimiliano Adamo

 non ci sto capendo una maz... 
 
trovato: 
http://bit.ly/1L8a18o
 
 
Quindi, conviene fare un balance, anche senza convertire le strutture e 
anche se no si ha un raid. 
Dopo un periodo di utilizzo si crea una discrepanza tra i byte utilizzati 
e lo spazio occupato, poiché non vengono liberati i chunk. E' una cosa un 
po' delirante, ma sicuramente meno delirante di un mirror che non mirrora. 
 
Per esempio, nel mio caso, anche senza mirror, dopo aver fatto il balance, 
ho ancora 1GB, su 1,7TB che non è libero: 
 
# btrfs fi sh /srv
Label: 'store'  uuid: d46eb49b-57da-42be-9953-2157f62bb230
	Total devices 1 FS bytes used 125.05GiB
	devid    1 size 1.66TiB used 126.03GiB path /dev/sdb1
 
 
quisquilie... ma lanciamo il comando ugualmente... 
1 chunk nel mio caso corrisponde a 1GB, infatti con 126GB, dice: 
7 out of about 127 chunks balanced (8 considered),  94% left
E alla fine si libera un po' di spazio. 
 
ma non è proprio così. A volte i dati vengono cancellati, ma i chunk 
restano occupati! Oggi ho migrato 1TB sul NAS e lui la prima volta ha 
iniziato a contare a 0 a 1028. 
 
p.s.: mi fa sorridere che il tipo del blog non conosce il comando watch 
 
while :; do btrfs balance status -v /mnt/btrfs_pool1; sleep 60; done
traduzione:
watch -n 60 btrfs balance status -v /mnt/btrfs_pool1  
 
 
 
FAI UNA COSA GIUSTO PER TOGLIERTI LA CURIOSITA':
Sul tuo PC lancia # btrfs fi sh /
e controlla la discrepanza tra "used" nella seconda riga e "used" nella 
terza riga. 
Su un altro PC dove non l'ho mai lanciato questo è il risultato (che ha 
dell'incredibile):
Label: 'root'  uuid: 0c915cc9-6456-4951-ba65-573facf21e8c
	Total devices 1 FS bytes used 14.41GiB
	devid    1 size 48.00GiB used 31.27GiB path /dev/sda5
 
 
-- 
Massimiliano Adamo

 Sul tuo PC lancia # btrfs fi sh /
 
ultra-sbattimento della serata: ho lanciato questo comando su un altro 
computer e ho trovato lo spazio al 100%. 
 
c'è solo un modo che funziona per risolvere in maniera non distruttiva:
 
 
1. provare diverse opzioni per il parametro "dusage". Non aiuta.
 
1. apt-btrfs-snapshot delete xxx Cancella gli snapshot creati da ubuntu/
debian durante gli upgrade ma non aiuta.
 
2. formattare ... no comment.
 
2. come ho fatto io: 
 - aggiungere un altro device in modalità concatenato (JBOD, senza raid):
   "btrfs device add /dev/sdx /"
   lanciare: "btrfs balance start /"
   questa volta funziona
   lanciare: "btrfs device delete /dev/sdx /"
   andare a letto che s'è fatto tardi
 
mettere in cron un btrfs balance che giri almeno una volta al mese... ma 
anche no, perché non trattandosi di un sever, potrebbe essere spento 
mentre il comando sta girando. 
 
 
 
-- 
Massimiliano Adamo

 mentre sto scrivendo):
 
Sai, e` per questi motivi che mi affido ancora al buon vecchio mdadm + lvm o 
che, al massimo, andrei di zfs on linux ;)
 
Enrico


dopo un paio di anni di utilizzo (domestico!) potrei fare diverse 
osservazioni su 'sto coso... 
1. va detto che ci sono aziende (tipo facebook) che lo usano in 
produzione... quindi, insomma... un po' di rispetto dobbiamo 
portarglielo :)
2. devo dire che non mi è chiaro cosa succede se il disco lavora con lo 
spazio dei chunk al 100%. Va comunque detto che quando sei al 100% non ne 
esci, il balance fallisce e devi aggiungere un disco, fare il balance e 
poi toglierlo.
3. adesso ho capito meglio la questione dei "misbalanced chunks", che non 
è relativa ai raid, ma a qualsiasi filesystem btrfs.  
4. non so se le idiozie possono essere annoverate tra i bug o ci vuole una 
categoria a parte. Ubuntu, quando viene installato con btrfs, crea 
automaticamente dei subvolume. Successivamente, quando fai l'upgrade alla 
release successiva, ti crea uno snapshot del subolune root. Questi snapshot 
vengono svecchiati dopo 90 giorni da una entry nel cron. 
/etc/cron.weekly/apt-btrfs-snapshot che cancella snapshot più veccchi di 
90 giorni. Peccato che sul mio serverino questo pacchetto che crea questo 
cron non era presente e mi sono trovato snapshot di vecchi di due anni. Lo 
snapshot, man man che cresce il delta, occupa il 100%: così mi sono 
ritrovato il sistema installato 3 volte :) Può essere che io ho rimosso un 
metapacchetto e il pacchetto è saltato ?? Ma se faccio apt-cache show, non 
vedo associazione ai "Task:" .... mah. 
Fra l'altro vorrei capire cosa succede in caso di fallimento di un upgrade, 
visto che nessuno ti avvisa che è stato creato uno snapshot! :) 
 
Per il resto bisogna dire che è un gran bel prodotto. L'uso delle quote 
per determinare l'assegnazione dello spazio ai subvolumi non è il massimo 
(qui vince LVM), ma nel complesso "spacca!" :) Disassemblamento del RAID 
(online!!!), conversione del RAID online (!!!), compressione, checksum.... 
e sono tutte operazioni semplicissime.... mentre con mdadm la vedo un po' 
dura a convertire un raid (leggo che con un po' di artifici si fa) .... 
fail, remove, add e poi reboot. Di certo non lo fai online. 
 
Poi mi piace tanto che sono state eliminate tutte le astrazioni più 
inutili. Tu non hai metadevice (md0, /dev/vghhh/lll). Dopo aver fatto il 
raid puoi montare indifferentemente /dev/sda o /dev/sdb. L'importante che 
non li monti entrambi :) 
Tutti gli incapsulamenti logici (md, pv, vg, lv) sono pippe che non hanno 
molto senso. Con lvm devi fare anche creare il PV, perché non capisce che 
un disco è un disco. Fare queste operazioni non è difficile, però è 
inutile e mentre btrfs si gestisce internamente questi processi, con lvm 
devi fare tutti questi passaggi. 
 
-- 
Massimiliano Adamo

 devi fare tutti questi passaggi. 
 
Il discorso e` che, a prescindere, un sistema
"stacked" e` migliore di uno integrato.
 
Ora, chiaramente, vi possono essere situazioni
in cui un sistema integrato risulta necessario.
Spesso per motivi di prestazioni.
 
In generale, pero`, e` un errore.
 
Per prima cosa, tutta la flessibilita` che si
puo` avere e` *solo* quella prevista dal
sistema stesso, non e` possibile fare meglio.
 
Secondo, tutti i bug si accumulano in un unico
posto (il che cresce esponenzialmente con la
complessita`, quindi con l'integrazione).
 
I due punti di cui sopra, ovviamente, portano
a varie conseguenze, tipo che se un layer del
sistema integrato a un "difetto" (bug, feature
incomplete, etc.), non puo` essere cambiato con
uno alternativo.
 
Quindi, escludendo i casi in cui serve per un
motivo specifico (ripeto, tipicamente prestazioni)
e` meglio avere i vari moduli separati.
 
bye,
 
-- 
 
piergiorgio

 tipicamente prestazioni) e` meglio avere i vari moduli separati.
 
se per te 'zram' viene prima delle prestazioni, allora vuol dire che ti 
trovi bene con LVM + PVM + LUKS + partizioni + filesystem. 
Per quel che mi riguarda, se le prestazioni migliorano e lo sbattimento 
diminuisce io preferisco una sola interfaccia.  
 
-- 
Massimiliano Adamo

 diminuisce io preferisco una sola interfaccia.  
 
Per prima cosa, bisogna *dimostrare* che vi
sia un vantaggio di prestazioni.
Ho scritto che *tipicamente* l'integrazione
e` fatta per quel motivo.
Non ho nessuna misura relativa a un RAID
btrfs vs md + LV (tra l'altro, btrfs usa lo
stesso codice di md, per cui si dovrebbe
proprio vedere la lentezza/velocita` delle
due soluzioni).
 
Secondo, non fa nessuna differenza una
interfaccia con 1000 parametri, oppure 10 con
100 parametri ognuna.
E` solo una questione di abitudine.
 
Non credo che btrfs sia piu` "facile", a meno
che, come scrivevo prima, non abbia ridotto le
possibilita`, cioe` la flessibilita`, di tutto
lo storage.
Il che, di nuovo, puo` andar bene per certi casi,
ma, in *generale*, no.
 
Vi sono, chiaramente, cose che magari possono
dare *realmente* fastidio in un sistema stacked.
Per es., il read-ahead, come va configurato?
Per ogni device?
Solo quello top?
Solo quello bottom?
 
bye,
 
-- 
 
piergiorgio

 Poi vi possono essere casi particolari in cui vanno benissimo.
 
letto tutto, ma taglio e riassumo. 
tu parli di "casi particolari".
Citiamo il caso per nulla particolare di "btrfs device delete...", "btrfs 
device add -dconvert=raid1" .... poi ci ripensi: "ma no, lo voglio raid10" 
e allora lanci -dconvert=raid10, e fai tutto al volo con un solo comando, 
con i dati sempre accessibili.  
Ti sembra un caso strano, un caso limite? Una cosa che nessuno mai 
farebbe? Ti sembra un vantaggio da poco? Qualcosa da poter sacrificare 
sull'altare di zram? :) 
E' qui che la complessità dello stack diventa insormontabile... e non è 
più questione che bisogna studiare sintassi dissimili tra loro tra i vari 
pezzi dello stack, ma è questione che con quell "accrocchio" questa cosa 
non si potrà mai fare. 
 
Ciò detto, oggi quasi nessuno usa il raid software, anche per questi 
motivi, ma uno storage a pool che effettua tutte le operazioni online, 
come zfs o btrfs, potrebbe cambiare le carte in tavola. 
Quindi mi difendi qualcosa che nessuno usa per diverse ragioni... oltre, 
come citato da te, che l'introduzione di quei layer crea per forza un 
problema di prestazioni. 
 
Ci vuole ancora un po' di tempo: 
- partire dal kernel 3.18 il problema dei chunk sarà risolto (io mi 
chiedo, ma che kernel usano in facebook??)
- bisogna attendere che i raid 5 e 6 diventino stabili. 
- magari potrà arrivare una piccola semplificazione sui quota_group
A quel punto un un bel ciaone a ext4 e lvm non glielo toglierà nessuno.... 
e se non lavori con storage esterno, potresti seriamente valutare un raid 
software di questo tipo, che è estremamente flessibile. 
 
-- 
Massimiliano Adamo

 Citiamo il caso per nulla particolare di "btrfs device delete...",
 
un'altra cosa che ho scoperto proprio, dopo aver installato il pacchetto 
apt-btrfs-snapshot install postix:
$ apt-get install postfix 
....blahblah...
Continuare? [S/n] 
Supported
Create a snapshot of '/tmp/apt-btrfs-snapshot-mp-fd2c8fvz/@' in '/tmp/apt-
btrfs-snapshot-mp-fd2c8fvz/@apt-snapshot-2015-03-14_19:40:56'
 
mi salve le configurazioni precedenti con uno snapshot... a me sembra più 
utile di zram, anche se è una cosa che non mi interessa e ho cancellato 
gli snapshot e rimosso il pacchetto che li crea :) A questo punto 
preferisco etckeeper che fa la stessa cosa con git. Però, con btrfs le vie 
del mondo sono infinite ... altro che zram :P O non sei d'accordo? 
 
-- 
Massimiliano Adamo

 letto tutto, ma taglio e riassumo. 
[...]
Anche io... :-)
 
Il discorso che faccio io e` un altro, comunque.
 
Tu, quando compri un PC, vuoi scegliere che
scheda video, che CPU, quanta RAM, che HDD
verranno installati?
 
Quello e` un sistema stacked.
 
Vi sono casi in cui quella flessibilta` e`
ridotta od eliminata. Videogame, laptop,
smartphone, per varie ragioni (costi e
prestazioni), ma resta il fatto che potersi
configurare il PC e` un grande vantaggio.
 
E nessuno si lamenta che c'e` PCIe, SATA,
DDR3/4/5, etc. come interfacce diverse.
 
Lo stesso discorso, a maggior ragione, vale
per il software.
 
In *generale* e` meglio averlo modulare.
 
bye,
 
-- 
 
piergiorgio

 del mondo sono infinite ... altro che zram :P O non sei d'accordo? 
 
Quella e` una feature del fs, non del fatto
che hai RAID, LVM e fs integrati.
 
Non c'entra nulla con il discorso che stiamo
facendo, poiche` puo` benissimo essere
aggiunta anche in ext5 (o quello che potrebbe
essere), ovvero FAT.
 
bye,
 
-- 
 
piergiorgio


no. Tu hai integrato nel FS cio che fai normalmente con LVM e non ciò che 
potresti fare con ext5 o fat. Pertanto per farlo nel tuo caso deve avere 
tutto lo stack in piedi. In questo caso ti basta un semplice filesystem. 
 
-- 
Massimiliano Adamo

 tutto lo stack in piedi. In questo caso ti basta un semplice filesystem. 
 
In ogni caso ti basta un semplice fs, non
ti serve btrfs ne` zfs.
 
Esistono altri fs che supportano lo snapshot.
E *nulla* vieta di creare un VVVFAT con snapshot.
 
LVM ha quella feature, ma non e` dipendente
dal volume manager, anzi, avere lo snapshot
in LVM non e` proprio ottimale.
 
D'altro canto, il fatto che LVM lo faccia e`
solo un vantaggio, poiche` posso avere quella
feature con *qualunque* fs, non solo con uno
specifico.
 
Posso fare snapshot con LVM avendo xfs, che e`
il fs of choice per chi vuole prestazioni.
Questo e` il vantaggio di un sistema stacked,
posso scegliere i componenti migliori ed avere
un sistema ottimale.
 
Un sistema integrato e` ottimale solo per il
contesto di integrazione per il quale e`
concepito.
Infatti zfs (e forse btrfs) e` concepito per
garantire la sicurezza dei dati, *non* le
prestazioni, come xfs o jfs.
 
bye,
 
-- 
 
piergiorgio

 dati, *non* le prestazioni, come xfs o jfs.
 
Solo per questo? E del resto invece che te ne pare:
 
The main Btrfs features available at the moment include:
 
Extent based file storage
2^64 byte == 16 EiB maximum file size
Space-efficient packing of small files
Space-efficient indexed directories
Dynamic inode allocation
Writable snapshots, read-only snapshots
Subvolumes (separate internal filesystem roots)
Checksums on data and metadata (crc32c)
Compression (zlib and LZO)
Integrated multiple device support
    File Striping, File Mirroring, File Striping+Mirroring, Striping with 
Single and Dual Parity implementations 
SSD (Flash storage) awareness (TRIM/Discard for reporting free blocks for 
reuse) and optimizations (e.g. avoiding unnecessary seek optimizations, 
sending writes in clusters, even if they are from unrelated files. This 
results in larger write operations and faster write throughput)
Efficient Incremental Backup
Background scrub process for finding and fixing errors on files with 
redundant copies
Online filesystem defragmentation
Offline filesystem check
Conversion of existing ext3/4 file systems
Seed devices. Create a (readonly) filesystem that acts as a template to 
seed other Btrfs filesystems. The original filesystem and devices are 
included as a readonly starting point for the new filesystem. Using copy 
on write, all modifications are stored on different devices; the original 
is unchanged.
Subvolume-aware quota support
Send/receive of subvolume changes
    Efficient incremental filesystem mirroring 
Batch, or out-of-band deduplication (happens after writes, not during) 
 
Additional features in development, or planned, include:
 
Very fast offline filesystem check
Object-level mirroring and striping
Alternative checksum algorithms
Online filesystem check
Other compression methods (snappy, LZ4)
Hot data tracking and moving to faster devices (currently being pushed as 
a generic feature available through VFS)
In-band deduplication (happens during writes) 
 
 
 
 
-- 
Massimiliano Adamo

 Solo per questo? E del resto invece che te ne pare:
[...]
 
Per prima cosa ho scritto "zfs" e *forse* "btrfs".
Quindi, e` inutile che mi metti una lista di
feature di btrfs.
 
Secondo, sono tutte feature per storage security,
non performance, cosi` come per "zfs".
 
D'altro canto, tu predichi bene e razzoli male,
se usi, nonostante btrfs, etckeeper.
 
Visto che il sistema integrato e` cosi ottimale,
avresti gia` dovuto eliminare il tool stacked.
 
Se non lo hai fatto, vuol dire che ti trovi
bene con un'interfaccia diversa, con un sistema
non integrato, etc.
 
Il punto e`, che anche tu vuoi il tool "migliore",
e non quello "integrato".
E fino a quando btrfs non sara` cosi` buono come
etckeeper userai quest'ultimo.
Cosa fai se btrfs non sara` mai cosi` buono?
 
Questo e` il problema di fondo, tu accetti un
compromesso (btrfs) quando ti fa comodo, non
perche` sia "meglio" in assoluto.
Il che, come scritto piu` volte, e` una ragione
valida, ma non venirmi a raccontare che avere
tutto integrato in un unico sw sia meglio, perche`
questo non e` assolutamente vero.
 
bye,
 
-- 
 
piergiorgio

 questo non e` assolutamente vero.
 
non è solo questione di avere integrate le cose. Come scritto anche io più 
volte è questione che lo stack eterogeneo non ti consente di fare certe 
operazioni online.  
 
 
-- 
Massimiliano Adamo

 Ciò detto, oggi quasi nessuno usa il raid software
 
Eccetto quelli che usano un Qnap, un Synology o un server fatto con FreeNAS, 
OpenMediaVault e cose del genere... ;)
 
Enrico


si hai ragione (e ci avevo pensato!) anche il mio nas western digital usa 
un raid software con ext4. 
Ed il mio NAS è addirittura come dicono loro, un prodotto "prosumer", ma 
chiaramente un prodotto "consumer" o "small office" non ha il controller 
raid, e oggi nessuno si vuole impelagare con un filesystem non del tutto 
stabile. 
 
-- 
Massimiliano Adamo

 facebook lo faccia.
 
A me stupisce che non venga colto un concetto semplice: FAcebook puo` usare 
quello che vuole perche` dietro ha un esercito di sviluppatori da dedicare 
alla manutenzione e alla gestione del progetto, ovvero e` molto probabile 
che la versione di Btrfs usata da Facebook sia una versione pesantemente 
patchata per funzionare come serve a loro (lo fanno per MySQL, lo fanno per 
PHP, non vedo perche` non debbano farlo per Btrfs)
 
Enrico


facebook contribuisce al progetto btrfs... mi risulta difficile pensare 
che si tengano le patch per loro, perché diventerebbe un fork, che 
potrebbero non riuscire ad integrare con tutti i nuovi rilasci... e 
perderebbero il vantaggio dell'open source. 
 
-- 
Massimiliano Adamo

 perderebbero il vantaggio dell'open source.
 
Il vantaggio dell'open source spesso significa avere un punto di partenza. 
Pensa ad esempio al tuo NAS, la partenza e` il kernel linux ed alcuni tool 
di gestione, mentre l'arrivo e` l'intero ambiente integrato e proprietario 
(la gui del NAS non e` FLOSS)
 
Enrico


a proposito di nas....
 
These companies are currently working on adding Btrfs to production 
products:
 
    Netgear (ReadyNAS products) 
 
a quanto pare anche i nas consumer stanno cominciando ad usarlo. 
 
per il resto secondo me stiamo provando a ipotizzare l'ignoto. 
 
Cio', quel che tu dici può anche essere vero. Noi nel nostro piccolo noi 
lo abbiamo fatto con le classi Puppet, modificando pesantemente quelle di 
puppetlabs forge  ed è stato il più grande errore della nostra vita. Fare 
il merge tra le nostre patch interne ed i nuovo rilasci è praticamente 
impossibile, ed è stato stupido precludersi la possibilità di usufruire 
dei contributi di una pletora di sviluppatori. 
Anni di errori ci hanno insegnato che dobbiamo prendere le classi cosi 
come sono. Al massimo conviene integrare le proprie patch. 
 
-- 
Massimiliano Adamo

 come sono. Al massimo conviene integrare le proprie patch.
 
se così non fosse l'open source sarebbe morto da un pezzo. 
 
-- 
Massimiliano Adamo


The following companies have contributed and/or contribute to Btrfs 
(sorted alphabetically):
 
    Facebook
    Fujitsu
    Fusion-IO
    Intel
    Linux Foundation
    Netgear
    Novell/SUSE
    Oracle
    Red Hat
    STRATO AG 
 
 
-- 
Massimiliano Adamo

Dopo dura riflessione, Max_Adamo ha scritto :

Anche al TECHUS, su questo nas che io ho in produzione fa scegliere 
btrfs... Di default ha ancora comunque ext3
 
http://italian.thecus.com/product.php?PROD_ID=83
 

 Anche al TECHUS
 
Per favore, non nominamo Techus, che mi ribolle il sangue >:(
 
Un Enrico scottato dal supporto alle C10GTR :'(

Enrico Bianchi ha detto questo martedì :

Allora per fortuna che non ho mai avuto bisogno del loro supporto! 
Magica astinenza tennica Techus!
 
:D