Link alla notizia: http://www.hwupgrade.it/news/sistemi-operativi/rilasciato-il-kernel-linux-412_69743.html

È stato finalmente rilasciato il kernel Linux 4.12, che porta con sé una quantità notevole di novità tra aggiornamenti e nuove introduzioni all'interno del codice. Tra le aggiunte si segnala il supporto alle schede GTX 1000 e Radeon Vega.

Click sul link per visualizzare la notizia.

Beh puoi provare a farti una partizioncina di test invece che reinstallare tutto... con LVM non dovrebbe neanche essere difficile dato che puoi farlo senza smontarla...

Devo riprovare a installare un sistema con Brtfs. Chissa' com'e' adesso (l'ultima volta che ci ho giocato era ancora in stato embrionale)

E' stabile, almeno io lo uso sul portatile con LVM in modalita' compressa per risparmiare spazio, pensavo di provarlo anche su un server che tiene tutti i backup. Mi piacerebbe provare anche XFS per vedere come controlla i fs anche in lettura.

Usando una scheda video AMD mi e' tornata voglia di compilare il kernel, oppure aspettero' un attimo per vedere quando esce in versione liquorix.

E' stabile, almeno io lo uso sul portatile con LVM in modalita' compressa per risparmiare spazio, pensavo di provarlo anche su un server che tiene tutti i backup. Mi piacerebbe provare anche XFS per vedere come controlla i fs anche in lettura.

Usando una scheda video AMD mi e' tornata voglia di compilare il kernel, oppure aspettero' un attimo per vedere quando esce in versione liquorix.

Che distro usi sul portatile?

Che distro usi sul portatile?

Debian Sid, col kernel standard, liquorix mi da' l'idea di aumentare i consumi.

Devo riprovare a installare un sistema con Brtfs. Chissa' com'e' adesso (l'ultima volta che ci ho giocato era ancora in stato embrionale)

Io lo uso ma non mi fido al 100%. Sono costretto a usarlo perché usando kernel recenti, era seccante gestire i package zfs.

In passato mi ha dato vari problemi, in particolare, usare BTRFS anche per la partizione root, per due volte mi ha corrotto il boot.

Se il tuo interesse sono i F/S di ultima generazione, ZFS è un'altro pianeta, sopratutto perché è prodotto da sviluppatori responsabili.

Gli sviluppatori di BTRFS hanno commesso errori di progettazione/pianificazione, ma non l'hanno voluto ammettere, arrivando alla situazione demenziale in cui, per un certo tempo, hanno negato il concetto stesso di stabilità del software.

Attualmente BTRFS ha una pagina per lo status (https://btrfs.wiki.kernel.org/index.php/Status), dove trovi vari status ridicoli come "piuttosto OK" (anche per configurazioni RAID, non so se mi spiego...).

Sono essenzialmente dei pagliacci, che hanno avuto la fortuna che la licenza del concorrente (ZFS) non è compatibile con il kernel Linux, e che non esistono alternative reali; altrimenti, di BTRFS non ne parlerebbe nessuno.

Se non usi kernel molto recenti, in Ubuntu basta installare il package zfsutils-linux; una configurazione molto semplice ed efficace è di usare ext4 per root, e ZFS per /home.

Sono essenzialmente dei pagliacci, che hanno avuto la fortuna che la licenza del concorrente (ZFS) non è compatibile con il kernel Linux, e che non esistono alternative reali; altrimenti, di BTRFS non ne parlerebbe nessuno.


Certo che deve essere incoraggiante per chi sviluppa software libero sentirsi dare dei pagliacci da gente che utilizza il loro software per lavoro e senza dare nulla in cambio... Sono sicuro che con 30.000 lire (manco gratis) lo sapresti fare meglio e non lo fai solo per non togliere visibilita' a questi poveri sfigati...

Certo che deve essere incoraggiante per chi sviluppa software libero sentirsi dare dei pagliacci da gente che utilizza il loro software per lavoro e senza dare nulla in cambio... Sono sicuro che con 30.000 lire (manco gratis) lo sapresti fare meglio e non lo fai solo per non togliere visibilita' a questi poveri sfigati...

Credo che, ad oggi, BTRFS sia sviluppato principalmente da gente pagata da Facebook &co.

Certo che deve essere incoraggiante per chi sviluppa software libero sentirsi dare dei pagliacci da gente che utilizza il loro software per lavoro e senza dare nulla in cambio... Sono sicuro che con 30.000 lire (manco gratis) lo sapresti fare meglio e non lo fai solo per non togliere visibilita' a questi poveri sfigati...
si, ma cmq non è che basta rilasciare qualcosa di libero xx essere automaticamente dei geni e gran mecenati.
se io scrivessi un kernel e lo rilasciassi open, sarei cmq un coglione, perchè non funzionerebbe nulla :p

Io lo uso ma non mi fido al 100%. Sono costretto a usarlo perché usando kernel recenti, era seccante gestire i package zfs.

In passato mi ha dato vari problemi, in particolare, usare BTRFS anche per la partizione root, per due volte mi ha corrotto il boot.

Se il tuo interesse sono i F/S di ultima generazione, ZFS è un'altro pianeta, sopratutto perché è prodotto da sviluppatori responsabili.

Gli sviluppatori di BTRFS hanno commesso errori di progettazione/pianificazione, ma non l'hanno voluto ammettere, arrivando alla situazione demenziale in cui, per un certo tempo, hanno negato il concetto stesso di stabilità del software.

Attualmente BTRFS ha una pagina per lo status (https://btrfs.wiki.kernel.org/index.php/Status), dove trovi vari status ridicoli come "piuttosto OK" (anche per configurazioni RAID, non so se mi spiego...).

Sono essenzialmente dei pagliacci, che hanno avuto la fortuna che la licenza del concorrente (ZFS) non è compatibile con il kernel Linux, e che non esistono alternative reali; altrimenti, di BTRFS non ne parlerebbe nessuno.

Se non usi kernel molto recenti, in Ubuntu basta installare il package zfsutils-linux; una configurazione molto semplice ed efficace è di usare ext4 per root, e ZFS per /home.

Strano, btrfs è file system usato di default da openSuse dalla 42.1 in poi, per la precisione btrfs per Root e XFS per /home. In particolare per gli SSD

Escluso il problema "MALI" ormai allwinner e' supportata al 100% , vecchi tablet che avevo con l A10/A31 prendono nuova vita, peccato che non esista una distribuzione specifica per tablet orientata al touch ma leggera.

si, ma cmq non è che basta rilasciare qualcosa di libero xx essere automaticamente dei geni e gran mecenati.
se io scrivessi un kernel e lo rilasciassi open, sarei cmq un coglione, perchè non funzionerebbe nulla :p

Non ti darei comunque del pagliaccio, semplicemente se avessi le capacita' e il software mi serve proverei a contribuire, altrimenti guardo alternative che soddisfino di piu' I miei bisogni...

Vorrei vedere se sarebbe in grado di dirglielo in faccia invece di sparare sentenze su un forum... Su internet la liberta' di parola purtroppo e' diventata la liberta' di criticare e sputare sentenze...

Strano, btrfs è file system usato di default da openSuse dalla 42.1 in poi, per la precisione btrfs per Root e XFS per /home. In particolare per gli SSD
il meglio per SSD non era F2FS di samsung?

Non ti darei comunque del pagliaccio, semplicemente se avessi le capacita' e il software mi serve proverei a contribuire, altrimenti guardo alternative che soddisfino di piu' I miei bisogni...

Vorrei vedere se sarebbe in grado di dirglielo in faccia invece di sparare sentenze su un forum... Su internet la liberta' di parola purtroppo e' diventata la liberta' di criticare e sputare sentenze...
io comunque trovo indecente che venga rilasciato sw non più che stabile con la scusa che "tanto si può aggiornare dopo".
che sia open o closed. chiaramente closed e a pagamento lo reputo ancora peggio.

Degno di nota anche questo commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e5268d57bb2ec9c82cf8758fa97a2f04ea9d1b

Non hi ancora provato ma dovrebbe fixare lo schermo nero con la gtx 970 e i nouveau. Con la mia ho sempre evitato le rolling distro per questo motivo (sono costretto ad usare nomodeset e installare i driver Nvidia, che funzionano ottimamente ma con i continui aggiornamenti del kernel vanno spesso reinstallati).

Strano, btrfs è file system usato di default da openSuse dalla 42.1 in poi, per la precisione btrfs per Root e XFS per /home. In particolare per gli SSD

ho utilizzato BTRFS per oltre un anno su openSUSE ma soprattutto su ubuntu, per tornare ultimamente ad ext4. Motivo: una amplificazione delle scritture a disco "mostruosa" (r.i.p. Villaggio), non ho fatto una misurazione precisa delle differenze ma ad occhio parliamo da un minimo di 3x ad oltre 10x a seconda dei casi, tutto ciò visto durante gli aggiornamenti di ubuntu. E se non ricordo male per installare opera browser (che non è altro che un chromium custom) mi scriveva ~2 (o 1?) giga per 50 mega di pacchetto!
purtroppo non ho tempo di fare delle misurazioni esatte, ma se qualcuno ha voglia...
ps: ho lavorato sulla stessa installazione spostata da un fs ad un altro.

Io comunque anche prima di UEFI facevo sempre una partizione di /boot da qualche centinaio di MB in ext4, poi dopo raid / lvm / fs strani. Oppure se mega raid un raid mirror piccolo in ext4 senza lvm con ext4 e basta per l'OS...

Pero' voglio provare XFS: c'e' qualche controindicazione a piazzarlo su un LV?
Dovrei per forza metterlo su un block device?

Strano, btrfs è file system usato di default da openSuse dalla 42.1 in poi, per la precisione btrfs per Root e XFS per /home. In particolare per gli SSD

Fino a non molto tempo fa, BTRFS ha avuto problemi molto seri con il RAID (5).

Se fossi il distributore, non userei di default un F/S con molte aree descritte come "mostly OK", ma evidentemente è una situazione accettabile per la maggior parte degli utenti.

Non ti darei comunque del pagliaccio, semplicemente se avessi le capacita' e il software mi serve proverei a contribuire, altrimenti guardo alternative che soddisfino di piu' I miei bisogni...

Vorrei vedere se sarebbe in grado di dirglielo in faccia invece di sparare sentenze su un forum... Su internet la liberta' di parola purtroppo e' diventata la liberta' di criticare e sputare sentenze...

Mah, non avrei problemi a dirglielo in faccia; sono sviluppatori molto irresponsabili, e nel campo dell'ingegneria, non ammettere i propri errori è un problema molto serio.

Produrre software instabile per design spacciandolo per stabile comporta perdite, come minimo di tempo, significative per gli utenti.

Se ammettessero che non è un software stabile, o che almeno che al tempo non lo fosse, mi starebbe benissimo - in fin dei conti, i F/S sono sistemi molto complessi, ma qui la situazione è differente.

Debian Sid, col kernel standard, liquorix mi da' l'idea di aumentare i consumi.
prova xanmod, a me sembra piu performante, forse è solo una impressione.

ho utilizzato BTRFS per oltre un anno su openSUSE ma soprattutto su ubuntu, per tornare ultimamente ad ext4. Motivo: una amplificazione delle scritture a disco "mostruosa" (r.i.p. Villaggio), non ho fatto una misurazione precisa delle differenze ma ad occhio parliamo da un minimo di 3x ad oltre 10x a seconda dei casi, tutto ciò visto durante gli aggiornamenti di ubuntu. E se non ricordo male per installare opera browser (che non è altro che un chromium custom) mi scriveva ~2 (o 1?) giga per 50 mega di pacchetto!
purtroppo non ho tempo di fare delle misurazioni esatte, ma se qualcuno ha voglia...
ps: ho lavorato sulla stessa installazione spostata da un fs ad un altro.

Come misuri l'amplificazione delle scritture? Parli di SSD o HDD? Non so se sia possible con gli SSD (ma non lo escludo).

ho utilizzato BTRFS per oltre un anno su openSUSE ma soprattutto su ubuntu, per tornare ultimamente ad ext4. Motivo: una amplificazione delle scritture a disco "mostruosa" (r.i.p. Villaggio), non ho fatto una misurazione precisa delle differenze ma ad occhio parliamo da un minimo di 3x ad oltre 10x a seconda dei casi, tutto ciò visto durante gli aggiornamenti di ubuntu. E se non ricordo male per installare opera browser (che non è altro che un chromium custom) mi scriveva ~2 (o 1?) giga per 50 mega di pacchetto!
purtroppo non ho tempo di fare delle misurazioni esatte, ma se qualcuno ha voglia...
ps: ho lavorato sulla stessa installazione spostata da un fs ad un altro.

Causato da cosa? Immagino dalla frammentazione? Già mi pare di ricordare che ext4 soffrisse di più problemi di frammentazione di ext3 o ricordo male io?

Come misuri l'amplificazione delle scritture? Parli di SSD o HDD? Non so se sia possible con gli SSD (ma non lo escludo).

Dovrebbe essere il wear leveling count*size SSD/byte scritti, almeno in modo approssimativo...

prova xanmod, a me sembra piu performante, forse è solo una impressione.

Interessante, e' piu' avanti di Liquorix come release. Vediamo come si mette con AMD (firmware / DRI).
Faccio uno snapshot e la provo prossimamente, thanks.

Come misuri l'amplificazione delle scritture? Parli di SSD o HDD? Non so se sia possible con gli SSD (ma non lo escludo).

Pur avendo utilizzato un ssd NON parlo della "write amplification" in senso stretto, ma dei dati scritti dal s.o. (verificabili con "iotop -a" ed iostat).

mi era venuta la curiosità di capire quanti dati scrivevo sul ssd in un determinato periodo di tempo ed aiutato dai programmi di cui sopra (visualizzando e salvando in ram i risultati), scopri che durante gli aggiornamenti (synaptic) downloadavo un tot MB in ram (/var/apt/cache ed altre cartelle le ho in zram), duque nessuna scrittura a disco, mentre quando partiva l'installazione (preceduta da apt-btrfs-snapshot) mi scriveva una enormità di dati (come detto 1 o 2 gb) a fronte di quanto scaricato (46 mb di opera)
così ho copiato il contenuto della snapshot preinstallazione in una partizione ext4 ed ho rifatto l'aggiornamento di opera (dallo stesso stato) che è risultato essere di poche centinaia di mega...

Causato da cosa? Immagino dalla frammentazione? Già mi pare di ricordare che ext4 soffrisse di più problemi di frammentazione di ext3 o ricordo male io?

no, in questo caso non centra la frammentazione, un filesystem decente pieno al 20% di fatto non frammenta.

credo che ci siano un paio di fattori:
- principalmente il copy-on-write: quando si modifica un file, in base a delle euristiche, esso può anche essere riscritto completamente
- secondariamente la duplicazione e la gestione dei metadati

se avessi un po' di tempo calcolerei esattamente la differenza...

...mi era venuta la curiosità di capire quanti dati scrivevo sul ssd in un determinato periodo di tempo ...
test molto interessante. sarebbe bello capirne le cause, che siano metadati mi pare assurdo, sono una enormità rispetto ai dati scritti.
è vero che magari sono milioni di piccolissimi file (quindo ogniuno coi suoi metadati
è vero che magari con un ssd viene riscritta più di una cella per motivi suoi interi (ma non credo che il dato venga fornito "all'estero" del disco, sono logiche interne)
è vero che magari ci sono problemi di allineamento dei cluster...
ma 2 GB a fronte di 50MB mi pare fuori di testa.
no, in questo caso non centra la frammentazione, un filesystem decente pieno al 20% di fatto non frammenta.
più che del FS, del driver che lo gestisce.
x es. NTFS viene scritto in modo molto diverso se fatto da windows o da linux (win mette i file tutti di seguito "a nastro", linux li sparpaglia per tutta la partizione frammentando pazzescamente lo spazio libero.)

Interessante, e' piu' avanti di Liquorix come release. Vediamo come si mette con AMD (firmware / DRI).
Faccio uno snapshot e la provo prossimamente, thanks.
di nulla
io lo usavo tempo fa su Ubuntu
poi essendo passato da qualche mese solo a Fedora sto usando quello di default, ma non mi dispiacerebbe avere xanmod anche su Fedora.

in teoria (e anche in pratica) si potrebbe ricompilare per Fedora ma non ho abbastanza conoscenze/tempo/voglia, quindi aspetto che esca una versione ufficiale di questo kernel.

test molto interessante. sarebbe bello capirne le cause, che siano metadati mi pare assurdo, sono una enormità rispetto ai dati scritti.
è vero che magari sono milioni di piccolissimi file (quindo ogniuno coi suoi metadati
è vero che magari con un ssd viene riscritta più di una cella per motivi suoi interi (ma non credo che il dato venga fornito "all'estero" del disco, sono logiche interne)
è vero che magari ci sono problemi di allineamento dei cluster...
ma 2 GB a fronte di 50MB mi pare fuori di testa.
avrei voluto anche capire se fosse possibile intervenire su qualche parametro delle euristiche in modo da limitare la copy-on-write al minimo col fine di generare extent solo per i dati modificati così da tornare su btrfs
NON credo sia nei parametri di mount, dovrei cercare...


più che del FS, del driver che lo gestisce.
x es. NTFS viene scritto in modo molto diverso se fatto da windows o da linux (win mette i file tutti di seguito "a nastro", linux li sparpaglia per tutta la partizione frammentando pazzescamente lo spazio libero.)

si giusto

il meglio per SSD non era F2FS di samsung?

Sinceramente non saprei, ma in un anno e mezzo di utilizzo su un SSD 240 evo di Samsung, con btrfs non ho avuto alcun problema.

ho utilizzato BTRFS per oltre un anno su openSUSE ma soprattutto su ubuntu, per tornare ultimamente ad ext4. Motivo: una amplificazione delle scritture a disco "mostruosa" (r.i.p. Villaggio), non ho fatto una misurazione precisa delle differenze ma ad occhio parliamo da un minimo di 3x ad oltre 10x a seconda dei casi, tutto ciò visto durante gli aggiornamenti di ubuntu. E se non ricordo male per installare opera browser (che non è altro che un chromium custom) mi scriveva ~2 (o 1?) giga per 50 mega di pacchetto!
purtroppo non ho tempo di fare delle misurazioni esatte, ma se qualcuno ha voglia...
ps: ho lavorato sulla stessa installazione spostata da un fs ad un altro.

Non mi sono accorto di queste amplificazioni delle scritture su disco sinceramente, anche perchè un SSD è comunque velocissimo rispetto un HD tradizionale, è difficile rendersi conto di scritture frequenti o anomale, e io provengo da un HD meccanico.

Forse le scritture continue sono dovute alle istantanee continue in fase di scrittura o al mirroring dei metadati? soluzione adottate da questo file system per proteggere i dati, in fondo questo è il suo scopo.. chiedo, non sono esperto..