Re: Shadow copies [Era brtfs]
Il giorno gio, 01/07/2021 alle 06.39 +0200, Piviul ha scritto: > Il 30/06/21 12:34, Piviul ha scritto: > > Ciao a tutti, sto per aggiornare un file server samba e stavo > > valutando se fosse il caso di usare brtfs al posto di ext4. Ho visto > > però che il progetto è ancora in beta... > > > > Essendo il filesystem un componente molto delicato soprattutto in un > > file server, secondo voi il progetto è ancora immaturo ed è meglio non > > utilizzarlo ancora in produzione o si può rischiare? > Grazie a tutti delle risposte... volevo valutare l'ipotesi di > implementare le shadow copies su samba; tempo fa avevo letto di brtfs > io mi trovo bene con rsnapshot da anni, non li rendo disponibili agli utenti, che quindi non sono autonomi, ma volendo è possibile farlo, mi pare di ricordare qualche guida in merito... Il tutto su ext4. Ciao P.
Shadow copies [Era brtfs]
Il 30/06/21 12:34, Piviul ha scritto: Ciao a tutti, sto per aggiornare un file server samba e stavo valutando se fosse il caso di usare brtfs al posto di ext4. Ho visto però che il progetto è ancora in beta... Essendo il filesystem un componente molto delicato soprattutto in un file server, secondo voi il progetto è ancora immaturo ed è meglio non utilizzarlo ancora in produzione o si può rischiare? Grazie a tutti delle risposte... volevo valutare l'ipotesi di implementare le shadow copies su samba; tempo fa avevo letto di brtfs come file system ma solo ora mi sono accorto che nel frattempo le cose sono cambiate... il vfs shadow_copy2 spinge molto su gpfs. Mi sa che devo studiare ancora un bel po'. Nel frattempo però se qualcuno ci si fosse già scontrato e volesse raccontare la sua esperienza... Grazie Piviul
Re: brtfs
Il 30/06/21 12:34, Piviul ha scritto: Ciao a tutti, sto per aggiornare un file server samba e stavo valutando se fosse il caso di usare brtfs al posto di ext4. Ho visto però che il progetto è ancora in beta... Essendo il filesystem un componente molto delicato soprattutto in un file server, secondo voi il progetto è ancora immaturo ed è meglio non utilizzarlo ancora in produzione o si può rischiare? Leggo in giro che btrfs è considerato stabile per diverse applicazioni. Ha inoltre diverse peculiarità interessanti oltre agli snapshot. Ad ogni modo ammetto di non essermi ancora preso il temo di studiarlo per bene. Ad ogni modo, perché valga la pena usarlo al posto di ext4, bisognerebbe implementare alcune delle sue peculiarità più interessanti e per sfruttarle non basta formattare il file system come abbiamo fatto finora con ext4. Se hai tempo e voglia di studiarlo imho può essere un buon investimento a medio-lungo termine (penso che diventerà sempre più rilevante nei prossimi anni, anche a causa dei problemi di licenza di ZFS che temo ci accompagneranno ancora a lungo). Ad ogni modo, se la funzionalità che ti interessa sono gli snapshot, immagino che tu sappia già che puoi ottenere lo stesso risultato usando LVM2 ;-) saluti, -gerlos
Re: brtfs
il Wed, 30 Jun 2021 13:57:36 +0200 Federico Di Gregorio ha scritto: | [...] | | Se non hai bisogno delle peculiarità di file system come brtfs o xfs (che so, una | tra tutte poter creare degli snapshot) non vedo motivo di preferirli a ext4. buon pomeriggio, mi permetto di quotare nello specifico la parte di cui sopra perchè anche io la penso esattamente come federico. rivolgendomi all'autore della discussione intendo dire che se non hai necessità precise che possano giustificare un cambiamento come quello ipotizzato io personalmente non mi avventurerei... ad ogni modo posso dire che BTRFS è ritenuto adeguatamente stabile da molti colleghi. in buona sostanza per come la vedo io è sempre preferibile limitare al minimo le possibili complicazioni in un contesto di produzione e utilizzare un file system che non si conosce (o non si conosce a fondo) è per l'appunto una potenziale complicazione non indifferente. in sostanza se la tua è una pura e semplice curiosità riguardo le possibilità e le interessanti (senza dubbio) caratteristiche di BTRFS puoi sempre provare in un ambiente di test prima di passare, eventualmente, in produzione. il tutto sempre imho s'intende. saluti. *** ║ «« WinterMute »» ║ -> https://www.debian.org/ «---» [bullseye/testing] ║ GNU Project ║ -> https://www.gnu.org/ ║ Kernel Archives ║ -> https://www.kernel.org/ ║ GPG FingerPrint ║ -> 38A4 5354 30C5 E86F 9AA8 B234 7227 D71D A547 39E0 *** pgp3UtufVHMro.pgp Description: Firma digitale OpenPGP
Re: brtfs
On 6/30/21 12:34 PM, Piviul wrote: Ciao a tutti, sto per aggiornare un file server samba e stavo valutando se fosse il caso di usare brtfs al posto di ext4. Ho visto però che il progetto è ancora in beta... Essendo il filesystem un componente molto delicato soprattutto in un file server, secondo voi il progetto è ancora immaturo ed è meglio non utilizzarlo ancora in produzione o si può rischiare? Il grosso vantaggio di ext4 è che è a "mantenimento" praticamente nullo. Nella stragrande maggioranza dei casi il tuo FS lavora per 10 anni e non ti ricordi neppure le opzioni che avevi dato al mkfs o l'ultima volta che fsck ha girato. Se non hai bisogno delle peculiarità di file system come brtfs o xfs (che so, una tra tutte poter creare degli snapshot) non vedo motivo di preferirli a ext4. federico
brtfs
Ciao a tutti, sto per aggiornare un file server samba e stavo valutando se fosse il caso di usare brtfs al posto di ext4. Ho visto però che il progetto è ancora in beta... Essendo il filesystem un componente molto delicato soprattutto in un file server, secondo voi il progetto è ancora immaturo ed è meglio non utilizzarlo ancora in produzione o si può rischiare? Grazie Piviul
systemd + brtfs + vrwtzv
Così, per stimolare un po' di sano sentimento anti-systemd (che su questa lista non manca mai) ecco un link ad alcune idee che io considero MOOOLTO interesanti. http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html La lettura è lunghina, ma ne vale la pena. federico -- Federico Di Gregorio federico.digrego...@dndg.it Di Nunzio Di Gregorio srl http://dndg.it We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.-- D.E.Knuth -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54044c1b.3020...@dndg.it
Re: systemd + brtfs + vrwtzv
Federico Di Gregorio writes:
Così, per stimolare un po' di sano sentimento anti-systemd (che su
questa lista non manca mai) ecco un link ad alcune idee che io considero
MOOOLTO interesanti.
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
Sono da internare.
Per carità, alcune idee non sono da buttare.
Ma...
Premessa
Io detesto cabale che mi impongono qualcosa, a meno che non mi abbiano
dimostrato di essere in grado di impormi qualcosa.
E qualcuno è in grado di impormi qualcosa quando io davanti a quel
qualcosa rimango impressionato dall'intelligenza della cosa - e della
persona che l'ha fatta.
Per mia sfiga, da studente universitario sono stato esposto a tante
belle testoline, da menti geniali veramente al di sopra della media
umana (i.e. gente che arriva al MIT e vince un premio che Leiserson(?)
aveva messo in palio oltre un anno prima), a gente in grado di
occupare ruoli come capo della ricerca in Nokia (quando non era di
M$), responsabili di prodotto della Mela (ruolo accettato solo in
cambio di poter scrivere ancora codice).
Quindi uno prima mi mostra di essere veramente un dio e io po accetto
la sua affermazione di essere un dio. Che gli dei li ho visti, e da
vicino.
Le proposte fatta
-
- Sostituire un app store ai repository di package.
Lo store va benissimo per gli end user end user end user, quelli per cui
un telefono non è dissimile da un televisore ed un frullatore: fanno la
cosa che devono fare, in maniera più o meno sfiziosa.
Ma per avere veramente senso, la perdita di libertà dell'app store
deve andare di pari passo con un forte controllo che il gestore dello
store deve fare sulle app per garantire al nostro utente di
elettrodomestici (idea di Jobs) di poter usare senza pericolo le app.
Da questo punto di vista va bene l'app store di Apple. Non ti garantisce
che l'app faccia quello che promette, solo che non vada in giro a fare
casini.
Ma uno store come quello di Apple genera dei ritardi dal rilascio da
parte del developer a quello della disponibilità per l'end user che
non è certo breve.
Uno store che dia spazio a cani e porci è una manna per i creatori
di malaware.
- Proposta per l'infrastruttura dello store.
In Apple giocano facile. Le app sono compilate statiche e si portano
dietro un'albero di directory con tutto quello che serve.
Quello che invece propongono per GNU/Linux ha senso si e senso no.
A rigor di logica funziona, sulla lavagna sembra funzionare. Ma non
funziona nel momento in cui ti rendi conto che certi runtime come
li pensano loro non esistono.
Un programmatore di Software Libero di solito va e prende tutte le
librerie che gli servono/piacciono e che non fanno a pugni come
licenza - se vuole rilasciare il programma.
Nella mia esperienza, i due file system che crescono maggiormente sono
/home
(credo che sia chiaro a tutti perché) e
/usr/local
dove vanno le cose che non trovi pacchettizzate, che una distribuzione
contiene tanto, ma non tutto. La mia /usr/local è 1/7 della /usr che
peraltro contiene un'altra cicciona (/usr/share con tutte quelle icone
carinissime).
L'architettura che propongono o rischia di portare a runtime ad un
orda di file system montati - qualcuno anche più di una volta e lo
stesso possono portare ad un sistema che per lo sviluppatore diventa
una piaga nel sedere.
Il difetto peggiore di Windows
--
Quello che percepisco come difetto peggiore di Windows è che obbliga
chi sviluppa a operare in un ambiente con le semplificazioni
dell'ambiente di chi con lo sviluppo non ha niente a che fare. È una
camicia di forza insopportabile per una persona che viene da Unix.
Forse mi infastidisce ancora di più della non libertà :).
Un ambiente basato su app è forse anche peggio di Windows per un ambiente
di vero computing. Se uno si limita al CaaT (Computer as a Toaster) un
ambiente del genere è più che sufficiente. Ma non per una persona che vuole
un computer per quello che è un computer, per questo tipo di utenti
è una camicia di forza.
Nonostante la possibile coesistenza (sul disco) di più sistemi. Preferisco
un antiquato partizionamento e aspettare che scenda dai P670 al mio PC :)
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_
//--\| | \| | Integralista GNUslamico
\/ coltivatore diretto di software
già sistemista a tempo (altrui) perso...
P.S.
Questo (di cui ho compreso il funzionamento by visual inspection)
main(){printf(unix[\021%six\012\0],(unix)[have]+fun-0x60);}
[David Korn, ATT Bell Labs, ioccc best One Liner, 1987]
e questo (che non decifrai la prima volta che lo lessi)
#define _ -F00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf(%1.3f\n,4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
