Discussioni sul sistema operativo Linux
 

btrfs rebalance: atroce dubbio

Max_Adamo 13 Mar 2015 17:58
sto per togliere un disco da un raid1 btrfs creato circa due anni
addietro.
Per farlo si puo' lanciare direttamente btrfs device delete /dev ******* (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 ******* kernel: [ 5842.590924] BTRFS info (device sdc1):
relocating block group 743058702336 flags 17
Mar 13 17:50:15 ******* 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
THe_ZiPMaN 13 Mar 2015 20:15
On 03/13/2015 05:58 PM, Max_Adamo wrote:
> Il risultato è che sta impiegando un sacco di tempo (e ancora lì che gira
> mentre sto scrivendo):

Normale... deve spostare tutti i files altrove.

> perché?
> Domanda retorica: se si perde un disco che fine fanno i dati non
> sincronizzati?

Cosa vorrebbe dire questo? Il raid di btrfs distribuisce gli extend su
più device, in modo che ciascun extent sia presente su almeno due device
(1) o ricostruibile dagli altri (5). La differenza tra il raid classico
e btrfs è che il primo lo fa solo a livello di blocchi omologhi e i
device devono essere identici, il secondo distribuisce come cavolo vuole
e lo può fare tra device totalemente differenti (con le ovvie
controindicazioni).
Il ribilanciamento serve per ridistribuire/copiare i blocchi di un
device sui rimanenti (p.es. per convertire quel volume in un volume raid
di livello diverso).

> E' buona norma far girare btrfs balance in crontab?

No. Non serve a nulla se non a perdere tempo e rischiare di perdere dati.

> 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
Max_Adamo 13 Mar 2015 20:40
Il Fri, 13 Mar 2015 20:15:15 +0100, THe_ZiPMaN ha scritto:

> On 03/13/2015 05:58 PM, Max_Adamo wrote:
>> Il risultato è che sta impiegando un sacco di tempo (e ancora lì che
>> gira mentre sto scrivendo):
>
> Normale... deve spostare tutti i files altrove.
>
>> perché?
>> Domanda retorica: se si perde un disco che fine fanno i dati non
>> sincronizzati?
>
> Cosa vorrebbe dire questo? Il raid di btrfs distribuisce gli extend su
> più device, in modo che ciascun extent sia presente su almeno due device
> (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 *****ware :)

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
Max_Adamo 13 Mar 2015 20:58
Il Fri, 13 Mar 2015 19:40:35 +0000, Max_Adamo ha scritto:

> 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
Max_Adamo 13 Mar 2015 22:13
Il Fri, 13 Mar 2015 19:58:08 +0000, Max_Adamo ha scritto:

> Il Fri, 13 Mar 2015 19:40:35 +0000, Max_Adamo ha scritto:
>
>> non sono del tutto convinto di quel che ho visto
>
> 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
Max_Adamo 14 Mar 2015 00:51
Il Fri, 13 Mar 2015 21:13:22 +0000, Max_Adamo ha scritto:

> 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 ******* 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
Enrico Bianchi 14 Mar 2015 13:27
Max_Adamo wrote:

> Il risultato è che sta impiegando un sacco di tempo (e ancora lì che gira
> 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
Max_Adamo 14 Mar 2015 15:25
Il Sat, 14 Mar 2015 13:27:20 +0100, Enrico Bianchi ha scritto:

> Max_Adamo wrote:
>
>> Il risultato è che sta impiegando un sacco di tempo (e ancora lì che
>> gira 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 ;)

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 i*****zie 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
Max_Adamo 14 Mar 2015 16:40
Il Sat, 14 Mar 2015 15:47:42 +0100, Piergiorgio Sartor ha scritto:

> On 2015-03-14 15:25, Max_Adamo wrote:
> [...]
>> 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
>
> Il che piu` che un vantaggio, mi sembra un problema.
>
>> 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ò è
>
> Perche` un disco non e` un disco.
> Posso fare un PV con zram oppure md, oppure LUKS, oppure un ******* ..

spostiamo un attimo l'attenzione su ZFS (o su btrfs quando supporterà
l'encryption), e allora scopriamo che LUKS serve più.
il ******* potrebbe essere /dev/loopX, ma sia il ******* sia zram non mi
sembrano use case tali da giustificare questo tipo di scelta, che a mio
avviso oggi sembra essere un po' superata.

Cioè, eviterei di subordinare le mie scelte al PV per via di zram. O no?

>> inutile e mentre btrfs si gestisce internamente questi processi, con
>> lvm devi fare tutti questi passaggi.
>
> Il discorso e` che, a prescindere, un sistema "stacked" e` migliore di
> uno integrato.

quindi zfs e btrfs hanno peggiorato le cose? mmmhhh ...

> Quindi, escludendo i casi in cui serve per un motivo specifico (ripeto,
> 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
Max_Adamo 14 Mar 2015 19:05
Il Sat, 14 Mar 2015 18:22:25 +0100, Piergiorgio Sartor ha scritto:

> [...]
>> quindi zfs e btrfs hanno peggiorato le cose? mmmhhh ...
>
> Si, in generale.
> 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
Max_Adamo 14 Mar 2015 19:45
Il Sat, 14 Mar 2015 18:05:47 +0000, Max_Adamo ha scritto:

> Il Sat, 14 Mar 2015 18:22:25 +0100, Piergiorgio Sartor ha scritto:
>
>> [...]
>>> quindi zfs e btrfs hanno peggiorato le cose? mmmhhh ...
>>
>> Si, in generale.
>> 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...",

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
Max_Adamo 14 Mar 2015 20:18
Il Sat, 14 Mar 2015 20:16:21 +0100, Piergiorgio Sartor ha scritto:

> On 2015-03-14 19:45, Max_Adamo wrote:
> [...]
>> 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?
>
> 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.

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
Max_Adamo 14 Mar 2015 22:49
Il Sat, 14 Mar 2015 20:40:42 +0100, Piergiorgio Sartor ha scritto:

> 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.

guarda che questo è quel che uso anche io oggi negli ambienti di
produzione, ma si tratta di roba novecentesca che non ha un futuro.
Per dirtene una:
XFS è diventato il filesystem di default in red hat 20 anni dopo la sua
prima comparsa.
BRFS è diventato il filesystem di default su suse 13.2 mentre non è ancora
del tutto stabile.

> 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.

Solo per questo? E del resto invece che te ne pare:

The main Btrfs features available at the moment include:

Extent based ******* storage
2^64 byte == 16 EiB maximum ******* size
Space-efficient packing of small files
Space-efficient indexed directories
Dynamic inode allocation
Writable snapshots, read-only snapshots
Subvolumes (separate ******* filesystem roots)
Checksums on data and metadata (crc32c)
Compression (zlib and LZO)
Integrated multiple device support
******* Striping, ******* Mirroring, ******* 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 ******* 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) ******* 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
Max_Adamo 15 Mar 2015 00:47
Il Sat, 14 Mar 2015 23:24:06 +0100, Piergiorgio Sartor ha scritto:

> On 2015-03-14 22:49, Max_Adamo wrote:
> [...]
>> guarda che questo è quel che uso anche io oggi negli ambienti di
>> produzione, ma si tratta di roba novecentesca che non ha un futuro.
>
> Ovviamente no, perche` prima o poi qualcuno trovera` una soluzione
> migliore.
> Che non e` ne` zfs ne btrfs, pero`.
>
>> Per dirtene una:
>> XFS è diventato il filesystem di default in red hat 20 anni dopo la sua
>> prima comparsa.
>> BRFS è diventato il filesystem di default su suse 13.2 mentre non è
>> ancora del tutto stabile.
>
> E questo cosa dovrebbe significare?
> Che in RH sono piu` cauti si Suse?
> Direi di si, visto che *Fedora*, che e` sempre bleeding edge, non ha
> ancora btrfa di default, anche se promesso da almeno due release (forse
> 3).

traduzione: gli piace, ma attendono che diventi stabile. Personalmente
sembra anche a me un po' prematuro usarlo sui server e mi stupisce che
facebook lo faccia. Il problema con i chunks per esempio è palese e non so
fino a che punto è fattibile di usare in produzione server con il kernel
3.6.18

> 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.

ci mancherebbe che conosci qualsiasi tool (pure io ho incontrato questo
tool ieri per la prima volta), ma per tua informazione: apt-btrfs *non* ha
nulla a che vedere con il progetto btrfs.
E' un tool che consiste di alcuni script in python sviluppati dalla
comunità Ubuntu, che può piacere o meno. Ma non c'entra in questo senso.

secondo me avrebbe un pochettino più senso se l'intaller creasse un
subvolume montato su /etc.... ma mi pare che la via migliore siano i
sistemi di versioning, come avviene con etckeeper.

> Il punto e`, che anche tu vuoi il tool "migliore",
> e non quello "integrato".

vedi sopra ;) ci mancherebbe che la comunità btrfs si mettesse a
sviluppare tool che hanno poco a che vedere con il discorso storage.

> 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.

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
Enrico Bianchi 15 Mar 2015 14:18
Max_Adamo wrote:

> 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
Max_Adamo 15 Mar 2015 14:29
Il Sun, 15 Mar 2015 14:18:15 +0100, Enrico Bianchi ha scritto:

> Max_Adamo wrote:
>
>> 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... ;)

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
Enrico Bianchi 15 Mar 2015 14:41
Max_Adamo wrote:

> mi stupisce che
> 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
Max_Adamo 15 Mar 2015 19:16
Il Sun, 15 Mar 2015 14:41:21 +0100, Enrico Bianchi ha scritto:

> Max_Adamo wrote:
>
>> mi stupisce che
>> 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)

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
Enrico Bianchi 16 Mar 2015 23:17
Max_Adamo wrote:

> facebook contribuisce al progetto btrfs...

Questo mi fa piacere saperlo, pensavo che il contributo fosse ad una via

> 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...

Questo lo reputo un non problema, proprio perche` dietro ha fior fiore di
sviluppatori, percio` non mi stupirebbe sapere che ha un team dedicato alla
gestione dell'integrazione di btrfs nei loro sistemi

> e
> 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
Max_Adamo 17 Mar 2015 18:53
Il Mon, 16 Mar 2015 23:17:01 +0100, Enrico Bianchi ha scritto:

> Max_Adamo wrote:
>
>> facebook contribuisce al progetto btrfs...
>
> Questo mi fa piacere saperlo, pensavo che il contributo fosse ad una via



>> 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...
>
> Questo lo reputo un non problema, proprio perche` dietro ha fior fiore
> di sviluppatori, percio` non mi stupirebbe sapere che ha un team
> dedicato alla gestione dell'integrazione di btrfs nei loro sistemi
>
>> e
>> 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)

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
Max_Adamo 17 Mar 2015 19:04
Il Tue, 17 Mar 2015 17:53:54 +0000, Max_Adamo ha scritto:

> Anni di errori ci hanno insegnato che dobbiamo prendere le classi cosi
> come sono. Al massimo conviene integrare le proprie patch.

se così non fosse l'open source sarebbe morto da un pezzo.

--
Massimiliano Adamo
Max_Adamo 17 Mar 2015 19:07
Il Tue, 17 Mar 2015 18:04:32 +0000, Max_Adamo ha scritto:

> Il Tue, 17 Mar 2015 17:53:54 +0000, Max_Adamo ha scritto:
>
>> Anni di errori ci hanno insegnato che dobbiamo prendere le classi cosi
>> come sono. Al massimo conviene integrare le proprie patch.
>
> se così non fosse l'open source sarebbe morto da un pezzo.


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
Paolo Costamagna 18 Mag 2015 12:23
Dopo dura riflessione, Max_Adamo ha scritto :
> Il Sun, 15 Mar 2015 14:18:15 +0100, Enrico Bianchi ha scritto:
>
>> Max_Adamo wrote:
>>
>>> 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... ;)
>
> 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.

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
Enrico Bianchi 19 Mag 2015 00:37
Paolo Costamagna wrote:

> Anche al TECHUS

Per favore, non nominamo Techus, che mi ribolle il sangue >:(

Un Enrico scottato dal supporto alle C10GTR :'(
Paolo Costamagna 22 Mag 2015 18:33
Enrico Bianchi ha detto questo martedì :
> Paolo Costamagna wrote:
>
>> Anche al TECHUS
>
> Per favore, non nominamo Techus, che mi ribolle il sangue >:(
>
> Un Enrico scottato dal supporto alle C10GTR :'(

Allora per fortuna che non ho mai avuto bisogno del loro supporto!
Magica astinenza tennica Techus!

:D

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sul sistema operativo Linux | Tutti i gruppi | it.comp.os.linux.sys | Notizie e discussioni linux | Linux Mobile | Servizio di consultazione news.