UFFICIALE L'OT di Linux e altri OS

Pubblicità
@lele.deb quell'errore non dovrebbe essere tipico di una errata masterizzazione dell'usb, dovrebbe essere la combinazione di ryzen mobo gigabyte e kernel 4.10-4.11.1; c'è chi risolve col kernel 4.11.2, c'è chi mettendo iommu=soft come parametro kernel, c'è chi aggiornando il bios.
ovviamente fatto salvo che se uno ha un sistema bios deve masterizzare bios, se uefi in uefi.:ok:
 
lele.deb ha detto:
Come masterizzi l'ISO su USB? hai aggiornato il BIOS? sei in UEFI mode? Kubuntu 17.04 va benissimo per ryzen, va bene anche la 16.04.3 LTS che ha il kernel 4.10.
Clicca per espandere...
Ho provato varie iso masterizzate con i vari programmi consigliati sulla wiki ufficiale di Ubuntu su vari supporti USB in diverse prese USB del PC. Il BIOS è alla versione f5, l'ultima per la mia mobo. Uefi mode non c'è sul mio BIOS. Le uniche impostazioni potrebbero essere queste ma non ho ben capito a che si riferiscono
cac6573af83a5e8b6c0808db46ef2c05.jpg


Inviato dal mio MI MAX utilizzando Tapatalk
 
BombaroloContro ha detto:
Ho provato varie iso masterizzate con i vari programmi consigliati sulla wiki ufficiale di Ubuntu su vari supporti USB in diverse prese USB del PC. Il BIOS è alla versione f5, l'ultima per la mia mobo. Uefi mode non c'è sul mio BIOS. Le uniche impostazioni potrebbero essere queste ma non ho ben capito a che si riferiscono
cac6573af83a5e8b6c0808db46ef2c05.jpg


Inviato dal mio MI MAX utilizzando Tapatalk
Clicca per espandere...
Ok, togliamo il dubbio UEFI: scarica Rufus, e masterizza l'ISO di Kubuntu con rufus, schema di partizionamento devi scegliere GPT/UEFI. Poi controlla se ci sono aggiornamenti per il tuo BIOS.
 
rebellion ha detto:
@lele.deb quell'errore non dovrebbe essere tipico di una errata masterizzazione dell'usb, dovrebbe essere la combinazione di ryzen mobo gigabyte e kernel 4.10-4.11.1; c'è chi risolve col kernel 4.11.2, c'è chi mettendo iommu=soft come parametro kernel, c'è chi aggiornando il bios.
ovviamente fatto salvo che se uno ha un sistema bios deve masterizzare bios, se uefi in uefi.:ok:
Clicca per espandere...
Sicuramente il problema, secondo me, è un problemi di firmware del BIOs, basta aggiornare, se c'è l'aggiornamento, però visto che ci siamo facciamo fare l'installazione correttamente in UEFI.
Phoronix i bench li ha fatti su Ryzen anche con Ubuntu 1+6.0.4.3 che ha kernel 4.10, quindi non è un problema di kernel.
 
Sto masterizzando la uso con Rufus. Speriamo bene, anche perché ho già l'ultimo firmware per la mia mobo quindi non è possibile risolvere con un aggiornamento

Inviato dal mio MI MAX utilizzando Tapatalk
 
lele.deb ha detto:
Ok, togliamo il dubbio UEFI: scarica Rufus, e masterizza l'ISO di Kubuntu con rufus, schema di partizionamento devi scegliere GPT/UEFI. Poi controlla se ci sono aggiornamenti per il tuo BIOS.
Clicca per espandere...
lele ma l'opzione di controllo di avvio su storage è su legacy, quindi su rufus non dovrebbe impostare lo schema di partizionamento mbr?
 
rebellion ha detto:
lele ma l'opzione di controllo di avvio su storage è su legacy, quindi su rufus non dovrebbe impostare lo schema di partizionamento mbr?
Clicca per espandere...
Niente da fare. Ho provato diverse volte sia masterizzando in gpt che in MBR, sia come ISO che come DD. Sono anche riuscito a fare una foto ad uno dei primi errori che da(scompare subito per via degli infiniti irq trap che compaiono dopo). Un altro errore che mi compare dopo un po' di questi è "error to start Journal service"
71f109ecb0e93019767424d8e8f0cc82.jpg


Inviato dal mio MI MAX utilizzando Tapatalk
 
@lele.deb un parere più tecnico:
Di quella lista, in realtà solo SUSE e Oracle lo deployano in produzione seriamente. E anzi, per ora Oracle si limita a fornirlo come scelta alternativa al default XFS, mentre solo SUSE lo offre come soluzione di punta.
Canonical ha scelto ZFS per il backend in LXD, e lo fornisce nel suo kernel, mentre gli altri all'atto pratico si mantengono molto ma molto sul vago sulla sua adozione o lo usano in contesti ristretti e controllati, come Facebook.

Sul motivo per il quale ZFS sia migliore:
Innanzi tutto, partiamo dal design. Quando ZFS venne progettato lo si pensò come uno storage system che doveva rendere obsoleto completamente LVM, Veritas e simili.
Da qui il file system venne studiato per sostituire la gestione dei singoli device fisici con degli storage pool virtuali, che sarebbero stati gli unici entry point del sysadmin.
Questo voleva dire che il pool doveva poter gestire qualsiasi tipo di use case, dai normali subvolumi ai block device (ZVOL).
Con ZFS infatti è addirittura possibile creare un block device a spaziatura preallocata e formattarlo con un file system specifico.
Quindi sopra un pool ZFS puoi avere, ad esempio, un volume ext4. Questa tecnica viene sfruttata per creare volumi di swap e dump usati dal sistema operativo, ed è utile quando si necessita di un file system specifico per i software in produzione senza dover andare ad operare sulle partizione dei singoli volumi fisici.
Questo fu oggetto di critica nel mondo Linux, che definì ZFS un rampant layer violation, perché di fatto eliminava la struttura a strati che prevedeva, partendo dal basso, volume manager -> file system, sostituendola con un solo strato vm+fs.

Btrfs non ha mai avuto un volume manager reale.
Non ha un concetto vero e proprio di storage pool, tant'è che un pool con /dev/sda1 /dev/sda2 e /dev/sda3 viene sempre e comunque gestito device per device.
Inoltre, essendo che non ha un volume manager completo integrato, non riesce a gestire block device nel pool. Quindi non puoi creare volumi pre-allocati formattati diversamente.
Puoi solo gestire i subvolumi, che sono directory trattate come file system indipendenti la cui dimensione viene gestita lato quote disco.

E proprio sulla questione quote disco, entriamo in un nuovo capitolo delle non-funzionalità di Btrfs.
Le quote disco sono ancora malfunzionanti e non usabili in produzione, il che vuol dire che ad oggi non esiste alcun modo sicuro per gestire la dimensione di un subvolume in pool.
Sempre per i subvolumi, non c'è ancora un modo sano per montarli singolarmente con opzioni di mount proprie.
Un dataset su ZFS (l'equivalente dei subvolumi di Btrfs) può essere montato in un punto specifico con opzioni indipendenti, proprio come un normale block device. Ed il montaggio naturalmente prevede che il dataset parent non mostri il figlio, poiché quest'ultimo è stato montato in un altro punto. Su Btrfs niente di tutto questo è possibile.

Btrfs non ha un formato definito, poiché è un fs in continua evoluzione. Il che vuol dire che chi lo deploya si assume il rischio di avere un pool non montabile dopo l'aggiornamento del kernel, in quanto il formato viene aggiornato al primo montaggio dopo l'upgrade.

Btrfs non è stato pensato per essere usato in contesti di storage sharati con ambienti non-UNIX.
ZFS ha la possibilità di gestire i singoli dataset con case insensitive, case sensitive e mixed case.

Sempre per la questione storage, ZFS si integra con CIFS e SMB, e se combinato con le modalità di case, lo rende la migliore soluzione come back-end per share da montare su volumi Windows.

ZFS può essere usato come back-end per il Volume Shadow System su client Windows. Btrfs no e non ci sono piani per integrarlo.

E queste sono solo un pizzico di differenze. Potremmo andare avanti per ore e ore.

La lista che tu hai fornito non solo è marketing ma a stento riesce ad essere la metà delle funzionalità realmente fornite.
Pensa alla bitrot protection. Btrfs è ancora prono alla corruzione dei dati e non ha funzionalità di self-healing funzionanti al 100% e né tanto meno un fsck stabile.
La lista dovrebbe essere quella dei vantaggi di btrfs su zfs che hai postato tu qualche giorno fa.
In caso di domande puoi chiedere direttamente all'utente sotto la news di redhat postata da me
 
AES ha detto:
@lele.deb un parere più tecnico:
Di quella lista, in realtà solo SUSE e Oracle lo deployano in produzione seriamente. E anzi, per ora Oracle si limita a fornirlo come scelta alternativa al default XFS, mentre solo SUSE lo offre come soluzione di punta.
Canonical ha scelto ZFS per il backend in LXD, e lo fornisce nel suo kernel, mentre gli altri all'atto pratico si mantengono molto ma molto sul vago sulla sua adozione o lo usano in contesti ristretti e controllati, come Facebook.

Sul motivo per il quale ZFS sia migliore:
Innanzi tutto, partiamo dal design. Quando ZFS venne progettato lo si pensò come uno storage system che doveva rendere obsoleto completamente LVM, Veritas e simili.
Da qui il file system venne studiato per sostituire la gestione dei singoli device fisici con degli storage pool virtuali, che sarebbero stati gli unici entry point del sysadmin.
Questo voleva dire che il pool doveva poter gestire qualsiasi tipo di use case, dai normali subvolumi ai block device (ZVOL).
Con ZFS infatti è addirittura possibile creare un block device a spaziatura preallocata e formattarlo con un file system specifico.
Quindi sopra un pool ZFS puoi avere, ad esempio, un volume ext4. Questa tecnica viene sfruttata per creare volumi di swap e dump usati dal sistema operativo, ed è utile quando si necessita di un file system specifico per i software in produzione senza dover andare ad operare sulle partizione dei singoli volumi fisici.
Questo fu oggetto di critica nel mondo Linux, che definì ZFS un rampant layer violation, perché di fatto eliminava la struttura a strati che prevedeva, partendo dal basso, volume manager -> file system, sostituendola con un solo strato vm+fs.

Btrfs non ha mai avuto un volume manager reale.
Non ha un concetto vero e proprio di storage pool, tant'è che un pool con /dev/sda1 /dev/sda2 e /dev/sda3 viene sempre e comunque gestito device per device.
Inoltre, essendo che non ha un volume manager completo integrato, non riesce a gestire block device nel pool. Quindi non puoi creare volumi pre-allocati formattati diversamente.
Puoi solo gestire i subvolumi, che sono directory trattate come file system indipendenti la cui dimensione viene gestita lato quote disco.

E proprio sulla questione quote disco, entriamo in un nuovo capitolo delle non-funzionalità di Btrfs.
Le quote disco sono ancora malfunzionanti e non usabili in produzione, il che vuol dire che ad oggi non esiste alcun modo sicuro per gestire la dimensione di un subvolume in pool.
Sempre per i subvolumi, non c'è ancora un modo sano per montarli singolarmente con opzioni di mount proprie.
Un dataset su ZFS (l'equivalente dei subvolumi di Btrfs) può essere montato in un punto specifico con opzioni indipendenti, proprio come un normale block device. Ed il montaggio naturalmente prevede che il dataset parent non mostri il figlio, poiché quest'ultimo è stato montato in un altro punto. Su Btrfs niente di tutto questo è possibile.

Btrfs non ha un formato definito, poiché è un fs in continua evoluzione. Il che vuol dire che chi lo deploya si assume il rischio di avere un pool non montabile dopo l'aggiornamento del kernel, in quanto il formato viene aggiornato al primo montaggio dopo l'upgrade.

Btrfs non è stato pensato per essere usato in contesti di storage sharati con ambienti non-UNIX.
ZFS ha la possibilità di gestire i singoli dataset con case insensitive, case sensitive e mixed case.

Sempre per la questione storage, ZFS si integra con CIFS e SMB, e se combinato con le modalità di case, lo rende la migliore soluzione come back-end per share da montare su volumi Windows.

ZFS può essere usato come back-end per il Volume Shadow System su client Windows. Btrfs no e non ci sono piani per integrarlo.

E queste sono solo un pizzico di differenze. Potremmo andare avanti per ore e ore.

La lista che tu hai fornito non solo è marketing ma a stento riesce ad essere la metà delle funzionalità realmente fornite.
Pensa alla bitrot protection. Btrfs è ancora prono alla corruzione dei dati e non ha funzionalità di self-healing funzionanti al 100% e né tanto meno un fsck stabile.
La lista dovrebbe essere quella dei vantaggi di btrfs su zfs che hai postato tu qualche giorno fa.
In caso di domande puoi chiedere direttamente all'utente sotto la news di redhat postata da me
Clicca per espandere...
Quale news postata da te? non la vedo. Comunque, il problema della corruzione dei dati era sul raid 5/6, risolto, almeno è in test al momento e quindi unstable. sul fatto che Btrfs non è pronto per la produzione ed ha alcuni problemi, è ovvio, infatti ti avevo scritto quando Btrfs sarà stabile in tutte le sue funzioni e pronto al 100%.
Sul fatto che Facebook non lo usa in produzione, è una sua parola, contro quella postata da un suo dipendente, sviluppatore di Btrfs Chris Mason, se vuole smentire pure lui...
Poi non posso confrontarmi con un sysadmin esperto, dovrebbe farlo lui con uno altrettanto esperto in produzione sui server etc... e che usa Btrfs.
LXD in molti lo usano anche con Btrfs, e Canonical ha il tool btrfs-progs nel main (supportato Canonical) e sulla mailing list di LXD sono in molti che chiedono aiuto con Btrfs.
I subvol su Btrfs li puoi montare con opzioni di mount diverse...
Ecco delle opzioni di muont diverse su Suse...
IMG_20170409_185814.webp

Come vedi nei subvol dove vanno le VM e nei database, viene disattivato il COW... Sicuro che usa Btrfs ed è aggiornato su Btrfs?
 
lele.deb ha detto:
Quale news postata da te? non la vedo. Comunque, il problema della corruzione dei dati era sul raid 5/6, risolto, almeno è in test al momento e quindi unstable. sul fatto che Btrfs non è pronto per la produzione ed ha alcuni problemi, è ovvio, infatti ti avevo scritto quando Btrfs sarà stabile in tutte le sue funzioni e pronto al 100%.
Sul fatto che Facebook non lo usa in produzione, è una sua parola, contro quella postata da un suo dipendente, sviluppatore di Btrfs Chris Mason, se vuole smentire pure lui...
Poi non posso confrontarmi con un sysadmin esperto, dovrebbe farlo lui con uno altrettanto esperto in produzione sui server etc... e che usa Btrfs.
LXD in molti lo usano anche con Btrfs, e Canonical ha il tool btrfs-progs nel main (supportato Canonical) e sulla mailing list di LXD sono in molti che chiedono aiuto con Btrfs.
I subvol su Btrfs li puoi montare con opzioni di mount diverse...
Ecco delle opzioni di muont diverse su Suse...
Visualizza allegato 256485

Come vedi nei subvol dove vanno le VM e nei database, viene disattivato il COW... Sicuro che usa Btrfs ed è aggiornato su Btrfs?
Clicca per espandere...
Beh, chi meglio di lui che é in un certo senso l'utente finale, può conoscere pregi e difetti?
Inoltre ti faccio notare che ha scritto che o sono vaghi sul suo utilizzo o lo usano in contesti ristretti e controllati, quindi può essere che si riferisca al secondo caso per quanto riguarda Facebook
Come ho detto l'altra volta, necessitá diverse, utilizzi diversi. Canonical, se non erro, ha scelto ZFS, punto.
Per le opzioni di mount, bisogna vedere esattamente cosa intenda,ma potrebbe essere effettivamente un errore, non lo nego.
Anyway, era giusto per dare un parere in più oltre quello dell'utente di reddit(suppongo tu l'abbia preso da lá?), sui vantaggi di zfs.
Chi lavora nell'IT DEVE essere aggiornato
oltre a tastare con mano i prodotti in maniera più seria, no? Chi meglio di lui può conoscere una determinata tecnologia?
La news é quella su redhat che abbandona btrfs
Personalmente mi sembra un progetto un po' traballante btrfs, ma non sono un indovino,per cui non posso dire di avere ragione a pensar questo
 
Ultima modifica da un moderatore:
AES ha detto:
Beh, chi meglio di lui che é in un certo senso l'utente finale, può conoscere pregi e difetti?
Inoltre ti faccio notare che ha scritto che o sono vaghi sul suo utilizzo o lo usano in contesti ristretti e controllati, quindi può essere che si riferisca al secondo caso per quanto riguarda Facebook
Come ho detto l'altra volta, necessitá diverse, utilizzi diversi. Canonical, se non erro, ha scelto ZFS, punto.
Per le opzioni di mount, bisogna vedere esattamente cosa intenda,ma potrebbe essere effettivamente un errore, non lo nego.
Anyway, era giusto per dare un parere in più oltre quello dell'utente di reddit(suppongo tu l'abbia preso da lá?), sui vantaggi di zfs.
Chi lavora nell'IT DEVE essere aggiornato
oltre a tastare con mano i prodotti in maniera più seria, no? Chi meglio di lui può conoscere una determinata tecnologia?
La news é quella su redhat che abbandona btrfs
Personalmente mi sembra un progetto un po' traballante btrfs, ma non sono un indovino,per cui non posso dire di avere ragione a pensar questo
Clicca per espandere...
Si ho letto ,e mi sembra, da come scrive, che non ha mai usato Btrfs, non ne segue lo sviluppo e non sappiamo che preparazione ha, quindi giudica a senso unico, ci sono controprove come l'utente su Reddit, che preferisco Btrfs. Può lavorare nell'IT o no, ma la sua parola non è niente in confronto a migliaia di professionisti, di certo quelli di Suse, Oracle, Facebook etc non sono sprovveduti ad usare e sviluppare Btrfs, vuol dire che ha un futuro, altrimenti colossi del genere non ci mettono niente ad abbandonare un progetto e crearne un altro.
Ripeto, da quel che scrive, è poco informato, anche la cazzata di Facebook, visto che contraddice un commento del developer principale di Btrfs e dipendente Facebook, ed ex Oracle quando ha iniziato lo sviluppo di Btrfs, quindi la sua parola a confronto non è niente, perché dice chiaramente che su facebook lo usano in produzione.
Per me sono le solite cazzate che scrivono altri professionisti, developer, che dicono che Btrfs è rotto by design, e poi scopri che non sono aggiornati sul suo sviluppo, non lo usano da anni, e l'unica cosa che ribattono è la corruzione dei dati su una feature dichiarata instabile, non pronta per la produzione (raid 5/6)
 
lele.deb ha detto:
Si ho letto ,e mi sembra, da come scrive, che non ha mai usato Btrfs, non ne segue lo sviluppo e non sappiamo che preparazione ha, quindi giudica a senso unico, ci sono controprove come l'utente su Reddit, che preferisco Btrfs. Può lavorare nell'IT o no, ma la sua parola non è niente in confronto a migliaia di professionisti, di certo quelli di Suse, Oracle, Facebook etc non sono sprovveduti ad usare e sviluppare Btrfs, vuol dire che ha un futuro, altrimenti colossi del genere non ci mettono niente ad abbandonare un progetto e crearne un altro.
Ripeto, da quel che scrive, è poco informato, anche la cazzata di Facebook, visto che contraddice un commento del developer principale di Btrfs e dipendente Facebook, ed ex Oracle quando ha iniziato lo sviluppo di Btrfs, quindi la sua parola a confronto non è niente, perché dice chiaramente che su facebook lo usano in produzione.
Per me sono le solite cazzate che scrivono altri professionisti, developer, che dicono che Btrfs è rotto by design, e poi scopri che non sono aggiornati sul suo sviluppo, non lo usano da anni, e l'unica cosa che ribattono è la corruzione dei dati su una feature dichiarata instabile, non pronta per la produzione (raid 5/6)
Clicca per espandere...
Sulla sua preparazione avrei da ridire dal momento che seguo con interesse i suoi commenti e di certo l'unica cos di cui non si può dubitare é la sua conoscenza fatto di struttura dei sistemi operativi.
Ripeto, lui, come altri sysadmin, é da considerarsi come un utente finale esperto, per cui é normale che ha tutte le ragioni( se sensate), di criticare qualcosa che probabilmente tasta con mano o su cui può fare un'attenta analisi.
Non servono migliaia di professionisti a sostenere una cosa, ne basta solo uno.
L'utente di lffl ha espresso un parere tecnico più che argomentato(bene), per cui non mi sembra abbia detto cazzate
 
Pubblicità
Pubblicità
Indietro
Top