Che succede se uso LINUX su DISCHI DANNEGGIATI?

[@morrolinux]

🧐Ti piace il mio modo di spiegare e vuoi diventare UN ASSO nei sistemi GNU/LINUX? 😎Buone notizie! Ho realizzato corsi on-demand per tutti i livelli. 👉Visita corsolinux.com per maggiori informazioni.

[@marcocabianca207]

Questa serie di video mi crea più ansia di un thriller

[@maximilian6880]

😂😂😂😂😂😂😂

[@aventrax]

Non avevo mai saputo che nbd potesse essere modificato in questo modo, davvero interessante per lo scopo. A fine anno 90 se non ricordo male feci i primi esperimenti con i vari fa, ma ero alla ricerca del più veloce. Mi fermai su XFS fino a che non persi i dati, tornato ad ext3 provavo ad intervalli regolari reiserfs che notavo più veloce ma incredibilmente soggetto a corruzione. Poi finalmente arrivò BTRFS che non abbandonai più, certo qualcosa lo persi all'inizio ma gli snapshot erano qualcosa di cui non potevo più fare a meno. Solo recentemente però ho iniziato a fare scrub regolari, ed effettivamente servono. Bel video comunque hai riassunto con dei test quello che costerebbe anni di prove senza poter replicare gli errori disco in questo modo, complimenti.😊

[@Jak835t]

Non commento spesso dato che non sono il tipo. Devo ammettere che sono rimasto veramente sorpreso da quanto è utile e interessante il video. Ti seguo da tanto e sembri molto più esperto del passato (o almeno lo sei diventato nel comunicare le cose). Continua così!! Grazie davvero per il tuo impegno!!!

[@MarcoSarti]

Geniale l'environment di test che hai preparato, non conoscevo nbdkit e lo riciclerò per un sacco di altri impieghi

[@giusepperossi699]

Un meraviglioso delirio di conoscenza. Bravo e grazie.

[@alerighi]

Questo però avviene in linea teorica perché stai usando un disco simulato che non da errore di lettura al kernel quando provi a leggere dati corrotti. In uno scenario reale, ossia dove hai un disco fisico il controller si accorge se sei di fronte a dei settori danneggiati, se non quando vai a scrivere almeno quando vai a leggere, e da al sistema operativo un errore di I/O che fa fallire l'operazione di lettura di quel settore. Quindi nel caso di RAID 1 con EXT4 non è proprio vero corrompe i dati, ma va a leggere i dati solo dal disco non danneggiato, dando ovviamente l'errore che il RAID è corrotto ed il disco danneggiato va sostituito ASAP. C'è anche poi da dire che un caso del genere è possibile anche se raro negli HDD (in genere il controller ti indica i settori danneggiati), e quasi impossibile che si verifichi con SSD, che generalmente o si guastano completamente, oppure restituiscono i dati corretti (o quantomeno il controller internamente fa dei checksum, se non error correction, per cui o ti da il dato corretto o non te lo da). Quindi non trovo la situazione così preoccupante, alla fin fine. EXT4 ha il pro come hai notato che in caso di guasti comunque genera meno corruzione dei dati, probabilmente perché sotto usa strutture più semplici per allocare i dati, che rendono possibile in maniera più facile il recuperare i file da supporti danneggiati.

[@maggiolino76]

Ma infatti, itest non rispecchiano la realtà.

[@gproietti67]

Stavo per fare la medesima osservazione, mi hai preceduto. Sarebbe interessante simulare anche questa situazione, per vedere la risposta di Ext4 di fronte ad una condizione reale.

[@alerighi]

Più che altro bisognerebbe capire anche qua che garanzie fa l'hardware sotto. Magari il test interessante da fare sarebbe prendere dei dischi mezzi rotti di varie marche e provare a vedere quale FS si comporta meglio, in termini di corruzione dei dati. Che per i desktop parliamo di dischi, ma ad es. se parliamo di server, alcuni (o quasi tutti?) i controller RAID dovrebbero già tenere internamente dei checksum dei dati (per cui il filesystem che usi sopra diventa irrilevante, anzi, a quel punto forse conviene un filesystem come EXT4 che evita delle operazioni che sono già fatte in maniera più efficiente dall'hardware?). Comunque la cosa è si interessante da studiare.

[@paolinide]

Fai sembrare tutto così banale che quando uno prova a rifare le stesse cose rimane frustrato. Non so se farti i complimenti o incazzarmi. Nel dubbio, complimenti, sei davvero bravo e, sopratutto, chiaro nelle spiegazioni.

[@Kakihara73]

Come sempre sei un GRANDE!!!! 😉😉😉

[@osciuto]

Ciao sei un grande, fai cose allucinanti con una dimestichezza incredibile, ho comprato tutti i tuoi corsi ma non per diventare bravo come te, ma solo per saper fare 1% di quello che sai fare e soprattutto per seguirti meglio nei video, continua così!

[@morrolinux]

Troppo gentile ti ringrazio!

[@giuliodicriscio]

Dopo aver visto questo video credo che per salvare foto e video in modo sicuro, sia meglio ritornare alle videocassette e alle foto stampate con tanto di negativi conservati xD Scherzi a parte, gran bel video come sempre!

[@logic_square2016]

Almeno le foto stampate non prendono virus, così come libri e soldi in carta. Giusta la tua riflessione.

[@gerlosv]

​@@logic_square2016questo perché non hai ancora incontrato le tarme della carta, che rosicchiano i fogli in punti random!

[@vincenzoferrara4223]

Infatti di recente ho letto un articolo su quanto fosse più sicuro fare backup su casette (che vengono ancora prodotte, e anche da abbastanza tera)

[@morrolinux]

@@gerlosv IL BIT ROTTING ANALOGICO!

[@DenisSoiMi]

Complimenti per il test veramente interessante. Personalmente ho sempre usato raid5 e sarebbe bello vedere se risolve il problema, in teoria dovrebbe. Una cosa che mi ha lasciato esterefatto è la questione del checksum subito dopo la copia. Penso dipenda dal fatto che usi un disco virtuale, altrimenti dal mio punto di vista è una notizia bomba. Vai così!🫡

[@nicoladellino8124]

Grazie per l'utile e bel video.

[@alessandromauri93]

Questa serie di video mi incuriosisce e mi appassiona parecchio. Ho una domanda in merito: se il disco "non lavora" è comunque possibile che i dati si corrompano? Io vorrei tenere una copia fisica che "stacco e attacco" quando mi serve aggiornarla per le foto. Credi potrebbe degradarsi col tempo o in teoria se analizzo ad ogni inserimento dovrei riuscire a prevenire errori?

[@morrolinux]

Risposta breve: sì, è possibile. Risposta lunga: dipende 😂

[@alessandromauri93]

@@morrolinux Io spero in una "risposta video" 😜 Comunque è un discorso incredibilmente interessante, appena ho tempo vado più a fondo 🐰

[@sebaberny7170]

complimenti, una comparazione efficace e brillante

[@kentahirono]

Sgr Morro ho notato che su silverblue puoi montare la partizione di root (/dev/sda3 nel mio caso) su un punto di mount a tua scelta avendo poi tutti i permessi di scrittura su ogni file e sottovolume. btw per curiosità come si sarebbero comportati, oltre ai già citati ntfs hfs+ apfs, anche bcachefs e f2fs.

[@AllevatoreAnonimo]

24:27 caro Moreno, Ubuntu è via. Non ho tutto sto tempo da dedicare. 😅

[@luciovestina8729]

Ciao, vorrei installare linux mint LMDE6 su filesystem ZFS, ma anche formattando prima la partizione ( nella procedura guidata ZFS non compare nell'elenco dei filesystem ) me la riformatta in ext4. Sbaglio io qualcosa o é necessario che l'installer della distro ammetta ZFS? Per esempio l'installer di Mint Cinnamon ha l'opzione "in chiaro"

[@KarbonBlack]

ciao Morro! Volevo dirti che ho appena comprato i tuoi 4 corsi su Udemy! Non vedo l’ora di seguirli e magari anche conseguire le certificazioni LPI!

[@fabrizio-6172]

Bel format ❤

[@Demon1195]

Una domanda ho visto in un tuo video il krytox 205 sarebbe il lubrificante una domanda dove l hai preso e quanto?

[@StefanoBergamini]

1000simo like 😂 bel video!

[@TheLizardNerd]

Ciao! Ci sono sviluppi su btrfs? Inoltre, ho una domanda se ext4: perché è sconsigliato utilizzare ext4 in raid1? Avrei bisogno di ulteriori delucidazioni, grazie!

[@marcomoraschi3537]

Comunque il video non è "interessante" è epico. Poi il fatto di testare tutto live e non elencare una serie di risultati ottenuti è impagabile. Oltre ad essere tecnicamente preparato hai una grande capacità didattica. Su KZbin.

[@marcomoraschi3537]

E comunque mannaggia a te, ora sto pensando il mio home server o prozmox con mirror zfs o truenans scale con mirror zfs. Altro non esiste

[@sakurapenguin1714]

Visto il tuo grande apprezzamento per ZFS, non faresti una recensione di GhostBSD, che usa per default questo file system proponendolo per l'uso desktop? Grazie :)

[@morrolinux]

Però il supporto hardware su BSD è decisamente inferiore a Linux, non saprei :/

[@AlessandroBenisi]

Giusto giusto arriva questo video… che avevo in programma di acquistare un NAS nuovo e puntavo a Synology o QNAP. E vedo che questi usano ext4 o btrfs (che per ora è meglio non usare con RAID5). Che gioia 😅

[@morrolinux]

Chi fa da sé fa per tre! (e spesso anche meglio ultimamente)

[@AlessandroBenisi]

@@morrolinux vero. Avevo anche in mente di costruire un NAS DIY con TrueNAS Core. Ma con la memoria ECC…? Sono un po’ paranoico con i dati 😂

[@morrolinux]

@@AlessandroBenisi Beh la memoria ECC male non fa ;)

[@dukefleed9525]

video spaziale che risponde esattamente alla domanda che avevo in mente! ma puoi spiegare meglio perche BTRFS non è consigliabile su raid 5 e 6 ? e ZFS se la cava meglio in questi casi? o cosa si può usare a quel punto ? configurazione immaginata: 5 dischi 10 tera l'uno, che raid, che file system?

[@davidevagginelli1678]

al momento con btrfs è meglio usare raid1c3 anziché raid5

[@DenisSoiMi]

Gli sviluppatori stessi lo sconsigliano in quanto ci sono casi limite in cui il raid si disallinea portando a problemi a volte catastrofici. Ci stanno lavorando ormai da diversi anni.

[@davidevagginelli1678]

@@DenisSoiMi infatti non ci credo più che verrà sistemato. Che poi, per come è implementato il raid1 su btrfs, se fai un raid 1 su 3 dischi non ha nemmeno senso il raid5 (almeno in senso di spazio utilizzabile, per quanto riguarda il throghput in lettura su file sequenziale si perde)

[@EmanueleCavallaro]

E invece verrà sistemato a breve e con una soluzione migliore rispetto a come fanno zfs e mdadm (perché il write hole è presente anche in queste implementazioni). Sul kernel in sviluppo 6.7 hanno introdotto il raid stripe per fare raid sui dispositivi zoned, ma può essere usato anche sui normali, prossimo step (6.8 o 6.9) dovrebbe esserci il raid 5/6.

[@davidevagginelli1678]

@@EmanueleCavallaro che io sappia il write hole è presente solo su btrfs e mdadm, non su zfs

[@therevenge3922]

Ciao mitico, mi piacerebbe veder un tuo video inerente il crearsi una connessione domestica protetta in virtù anche di tante persone che hanno subito degli hackeraggi, mi piacerebbe sapere quale sia la soluzione ideale calcolando che navigo in qualsiasi sito…grazie mille

[@ladytech28390]

Video sempre super interessante. Si impara sempre un sacco. Devo correre a sistemare il mio nas allora 😮 Una domanda: esiste qualcosa di simile a Cubbit per i privati che tu sappia? P.S. Attendo tanto il video in cui parlerai di Infomaniak, sembra presentarsi meglio di Proton Mail

[@xanScale]

usando EXT4 senza raid questo video crea piu ansia di THE RING

[@morrolinux]

Consolati, EXT4 in RAID1 é anche peggio! 😂

[@ivanzb89]

anch'io pensando ad anni di foto e video salvati in ext4... e backuppati in ext4... alternative?

[@morrolinux]

@@ivanzb89 Come dicevo nel video, btrfs o ZFS hanno il controllo di integrità sul contenuto del file. In configurazione RAID1 o superiore è nettamente migliore, in configurazione a singolo disco almeno ti permettono di sapere se e quali file sono corrotti, che è già un passo avanti. ZFS in particolare ha anche un demone per mandarti una mail quando questo accade, ne consiglio l'uso su Proxmox per la migliore esperienza possibile. Se parliamo di "normali dischi esterni USB" allora BTRFS.

[@dario.nistri]

Con Linux è possibile accedere ai dati di un vecchio hard disk diventato inaccessibile in seguito a un defrag interrotto dal computer che si è impallato?

[@peaolo]

Penso tu possa appoggiarti a testdisk ed il suo gemello photorec: son due strumenti open source da riga di comando che recuperano partizioni perse (il primo) e file cancellati o sminchiati per vari motivi non considerando la Master File Table (o area analoga su vari filesystem), ma identificando i file direttamente dall'intestazione esadecimale che recupera leggendo bit a bit su disco rigido o memoria a stato solido di varia natura (funziona anche su schede SD, chiavette USB, ecc..). La fregatura del secondo tool è che ignorando la MFT ciao ciao a nomi dei file e posizione delle relative cartelle: ti trovi un mucchio di file nominati tipo M00534.pdf RP4278.jpg ecc.. in alcuni casi però i metadati annessi permangono e possono esser usati per ricostruire i nomi dei file, come ad esempio i tagID3 degli MP3 o le informazioni EXIF delle foto.

[@mprone]

Se raggrupperai questi video in una playlist, chiamala "dischi fantastici e come spaccarli"

[@morrolinux]

AHAHAHAH

[@amedeopetrella2610]

Ottimi test. Grazie. Una domanda: l'implementazione di btrfs di Synology è diversa rispetto a quella di Linux?

[@morrolinux]

È Linux sotto la scocca

[@amedeopetrella2610]

@@morrolinux Infatti. Però Synology usa pesantemente RAID5 e RAID6 nei suoi NAS. Se non funzionasse, non li comprerebbe nessuno. Ma btrfs su Linux è ancora sperimentale. Mi chiedevo quindi se loro usassero una versione personalizzata di btrfs, così come penso faccia QNAP con ZFS sulla sua versione enterprise con QuTS Hero.

[@fabriziop.3360]

Per mantenere l' highlight di journalctl ti consiglio di non mandare in pipe grep, ma di usare il parametro --grep=

[@morrolinux]

Grazie!

[@logic_square2016]

Ciao Morro. Ti chiedo solo se conosci un'app per linux che mi consente di recuperare i dati da dischi esterni danneggiati. Ne ho uno molto importante che lo vede ma non ci entra, purtroppo. Cosa posso fare? Grazie.

[@morrolinux]

Già provato photorec?

[@giacomo1439]

Prova con testdisk/photorec. Io ci ho recuperato un disco da 2tb corrotto

[@logic_square2016]

@@morrolinux lo provo poi ti farò sapere

[@logic_square2016]

@@morrolinux Ho cercato photorec sul repository e mi ha dato testdisk. L'ho avviato e il hard disk esterno non lo legge, in compenso l'app dischi di mint 21.1 si lo vede ma non ci entra. Come windows.

[@luke3207]

Molto, molto interessante.

[@thinkmarco]

Un RAID 1 hardware riesce a correggere il bitrot? Meglio due dischi in RAID1 gestiti in hardware oppure 2 dischi in RAID1 gestiti come volume ZFS? Mettendo come obiettivo la sicurezza dei dati e non le performance.

[@morrolinux]

Bisognerebbe fare qualche prova con qualche controller hardware ma mi verrebbe da dire sia più sicuro ZFS senza controller perché a differenza del controller RAID che ragiona per blocchi e non sa cosa sia un filesystem, ZFS gestisce tutto e nel caso peggiore sa anche dirti quali sono i file interessati.

[@testaaa88]

Non è che ZFS rilegge i dati quando li scrive, forse lo confondevi con il copy on write?

[@DavideFici]

Per quanto riguarda il sync o copy dei file tramite rclone è possibile controllare se l'md5 è uguale ? E' possibile inoltre effettuare una verifica md5 tra cloud e locale periodica (in tempi non troppo lunghi avendo grandi quantità di dati anche in parti criptate) in modo tale da sostituire i files in locale ? Usando windows con un pool di drive in ntfs sono un pochino preoccupato ora ahahaha Ho visto dalla documentazione che esiste rclone check --checksum e rclone cryptcheck; ma non mi è chiarissimo il funzionamento e se funzionano anche in pratica.

[@morrolinux]

Ma in realtà rclone sincronizza solo i file cambiati dall'ultima sincronizzazione per impostazione predefinita. Non trasferisce tutti i documenti ogni volta. E la crittografia è praticamente a costo zero se hai una CPU prodotta entro gli ultimi 10 anni.

[@DavideFici]

​@@morrolinux​​ grazie mille per la risposta. Però c'è qualcosa che non mi torna; forse mi sono espresso male o c'è qualcosa che non ho capito. Nel caso abbia un file in locale che si è corrotto in maniera silente e abbia in google drive salvato in passato questo file, rclone potrebbe controllare il md5 dei due file e ristabilire il file non corrotto ?

[@morrolinux]

@@DavideFici Il problema è: come farebbe rclone a capire che il file locale è stato corrotto per via del bit rot e non semplicemente modificato dall'utente?

[@DavideFici]

@@morrolinux Aaa, ok. Avendo backup prevalentemente di foto e video non mi ponevo il problema in effetti; però su uno scenario con files che vengono modificati spesso è un problema. Grazie mille. Se può interessare ho provato cryptomator guardando il tuo precedente video però per le mie esigenze non è stato ideale (principalmente per il tempo impiegato a criptare grandi quantità di files). Allora ho provato Veracript ma aveva delle limitazioni per quanto riguarda la grandezza dei volumi. Infine ho provato cppcryptfs(su windows) che è un'implementazione di gocryptfs(su linux), usa la cifratura aes 256 ed è molto veloce.

[@trademark4500]

Mi chiedevo se esista una distro che permetta di fare un backup senza perdita di dati, ma qualcosa per comuni mortali non per informatici super top

[@emanuelerosati3885]

Non faccio mai un raid software, già avuta pessima esperienza tantissimi anni fa con ext3. Ai clienti dico sempre "controller raid con cache e batteria/condensatore". Sicurezza assoluta? Ovviamente no, ma almeno aumenti di ordini di grandezza la possibilità che non ti schianti tutto o ti corrompa i file perché è il controller stesso che verifica ogni operazione di lettura/scrittura. Per non parlare dei fenomeni che mettono SSD da PC su un server....quando te le cerchi, è facile che le trovi....

[@valix85]

Ma ntfs come si comporta?

[@alessandrochiarenza]

Ciao! Non vorrei fare troppa pubblicità...ma che ne pensi di quei NAS della QNAP con sistema operativo "QuTS hero" basato su ZFS?

[@alessandrochiarenza]

Oppure, in alternativa, "TrueNAS".

[@morrolinux]

@@alessandrochiarenza Quello della QNAP non lo conosco, TrueNAS invece mi dicono sia tanta roba. Io però uso Proxmox perché mi piace un po' di più e mi sembra più robusto e semplice da capire e gestire, al di là dell'interfaccia.

[@michelecippitelli2894]

Ottimo video, argomento veramente interessante e poco trattato

[@plasma77]

a 16:33 mi hai fatto morire con "il Raid di m...." 🤣

[@sisko212]

Leggevo sulla documentazione che lo scrub è sconsigliato se usi ZFS come filesystem in una vm, ossia come guest sopra un hypervisor che a sua volta magari usa un raid hardware o una soluzione similare. Vista la cosa direi che invece sarebbe utile.

[@morrolinux]

Probabilmente per un discorso di performance e usura, hanno ragione. Lato integrità però è importantissimo. La soluzione migliore infatti è usare proxmox con ZFS e fare lo scrub a livello di hypervisor

[@vinciraia9944]

ora che ho avuto una giusta dose di ansia, che file system conviene in backup di foto e video a lungo termine in locale, su un disco che è continuamente connesso al pc

[@langhistruk]

Scusate il leggero OT, ma NTFS e il filesystem di Apple come si sarebbero comportati qua?

[@morrolinux]

Non hanno il controllo di integrità sui dati quindi come ext4 direi

[@langhistruk]

Se interessasse a qualcun'altro: ho poi googlato e APFS ha il checksum, mentre Microsoft ha un nuovo filesystem ReFS moderno. Mentre NTFS come dice morro sarebbe stato come ext4.

[@morrolinux]

@@langhistruk Sicuro che il checksum sia sui dati e non solo sui metadati come EXT4? Da una breve ricerca ho subito trovato: "Apple File System uses checksums to ensure data integrity for metadata but not for user data." Fonte: en.wikipedia.org/wiki/Apple_File_System Mentre per quanto riguarda ReFS confermo che ha il checksum, ma avevo letto che non era pensato (o pronto) per rimpiazzare NTFS inteso come filesystem su cui installare l'OS e nell'uso a singolo disco.

[@emanueleluciani99]

​@@morrolinuxReFS non è ancora pronto perché manca ancora qualche feature rispetto a NTFS. Però Microsoft lo sta aggiornando da anni, ormai non manca troppo. L'unica cosa che non comprendo, è il fatto che non documenti bene il tutto, almeno pubblicamente 😅

[@langhistruk]

@@morrolinux errore mio, mi sono fidato di questa tabella en.m.wikipedia.org/wiki/Comparison_of_file_systems#Features 🙂

[@dinodelfavero]

Interessante video e bei test, probabilmente non è necessario smontare e rimontare il filesystem ma è sufficiente forzare il sync dei dati.

[@ipersalvo1]

Ciao, veramente edificante come contenuto. Vorrei sapere se conosci il comportamento del NTFS di microsoft?

[@morrolinux]

Ciao, NTFS non ha il controllo d'integrità sui dati quindi dovrebbe comportarsi come EXT4.

[@ipersalvo1]

@@morrolinux ok grazie mille per la celerità :)

[@BrakeTheGame]

Bellissimo video! Io purtroppo ho imparato sulla mia pelle che ext4 e Raid 1 non vanno d’accordo quando ho quasi perso (grazie testdisk per esistere) tutti i dati sul mio home server che uso per vari server minecraft e altro. Ora uso ZFS e mi sento molto più al sicuro!

[@Hal3000IT]

il fatto che non si accorge degli scazzi è dovuta alla cache. ZFS ha una cache pesante ma bombissima...... Forse mi sbaglio ma brucia tutti(in passato) o quasi su questo fronte a costo di un uso vorace della RAM lo uso da Solaris e tutte (o quasi) le varie derivate e non posso che parlarne bene oltre ad aver acquisito una discreta conoscenza. Ha una valanga di possibilità (come tenere N copie sullo stesso disco; bassa utilità a mio giudizio). Unico aspetto: ho sempre cercato di usare hardware server specie su RAM e HDD/SSD/Nvme senza mai avere scompensi o perdite anche dopo virus o altri malware. E anche hw da pc con RAM ECC e storage server (con JBOD o normalissime sata) mai avuto buche irrisolvibili.

[@brunolombardini7342]

Uso lnux mint versione pepper dal 1990. mai avuto proplemi , con il succedersi delle versioni debian anche . mai perso un bit e all'epoca andavo con un 486 ... bho ...

[@010101825]

Seio f*tt* bravo, difficile trovarne così tra i coetanei

[@AlessioDrkdePinto]

Ma allora io mi chiedo, ci vuole molto a creare un file system perfetto, senza difetti ed errori o possibili perditete di dati per cavolate assurde come una veloce rilettura dopo ogni scrittura?

[@AlessioDrkdePinto]

E parlo da utente con un nas xpenology con 6 dischi da 4 tera in RAID 5 con BTRFS. Per ora, da quasi un annetto a questa parte non ho mai avuto problemi ma a questo punto spero in non molto tempo di riuscire a trasformarlo in RAID 6 alemno dovrei essere un po' più al sicuro (forse)

[@enricocialdini6194]

hai una mail per contattarti?

[@Franceyou]

Il limite di EXT4 potrebbe essere risolto con snapRAID?

[@Entropia404]

Mi sono avvicinato a ZFS quando ancora non si chiamava OpenZFS su Debian con OpenMediaVault. Se non ho la possibilità di RAID hardware direttamente da controller dedicato e non uso ZFS, mi viene l'ansia. Si Ok, non è sempre Mr. Simpatia, ma mi permette di avere un certo controllo e quindi meno ansia. Non ho mai provato sempre su Debian a provare un installazione con root in ZFS, potrebbe essere divertente.

[@ericturturo3115]

Che gran figata!!! Complimenti per la scioltezza con cui salti ti destreggi tra i comandi dei diversi fs! Cmq mi sarebbe piaciuto vedere anche come btrfs gestiva la corruzione in mirror. E poi, ultima cosa, faresti lo stesso esperimento anche con snapraid??? Ti preeeego!🙏

[@DenisSoiMi]

Btrfs in mirror lo ha fatto come primo test di btrfs.

[@LampoTuono-tp2li]

upvote per testare Snapraid!

[@riccardogianluigiterzaghi]

Video davvero interessante. Bravo Moreno! Ora scusate ma devo far benedire i miei dischi 😂

[@giusepperossi699]

Super!

[@antoniomessi]

Con zfs prova RAID-Z1 (che dovrebbe essere simile al raid5) ma forse dovrebbe dare una maggiore sicurezza

[@sergioruocco6181]

Bisogna usare ZFS in RAIDZ2 o meglio RAIDZ3 con N+2/3 dischi. Ogni altra alternativa è molto inferiore e inaffidabile.

[@AndreaIppolitoIppo]

Di btrfs in RAID1 non mi sembra però per niente male il fatto che corregga gli errori al mount successivo. ZFS fa lo stesso? In scenari in cui unmount/mount avvengono più spesso dello scrub pianificato (se pianificato...) ridurrebbe le possibilità di avere dati corrotti.

[@morrolinux]

Vero. E ZFS non mi è parso che correggesse fino al prossimo scrub, indipendentemente dai montaggi.

[@luigilaurini4995]

Interessante ma non capisco la scelta di BTRF per il test. Non avrebbe avuto più senso testare XFS?

[@morrolinux]

Perché?

[@luigilaurini4995]

@@morrolinux per un tema di diffusione. Credo che XFS sia molto più utilizzato di BTRFS e per il supporto al CRC di xfs

[@morrolinux]

@@luigilaurini4995 Ma a me risultava che il CRC di XFS fosse solo sui metadati come per EXT4, mi sto perdendo qualcosa? Dalla wiki di Arch: "Note: Unlike Btrfs and ZFS, the CRC32 checksum only applies to the metadata and not actual data."

[@luigilaurini4995]

@@morrolinux si hai ragione è solo sui metadati.

[@SnakeEstrai]

Io uso zfs su pc di casa e raid 5,gli scrub me li fa in automatico truenas ogni tot. Ma non ho un bakups dei file che ci son dentro perche sarebbe una spesa mostruosa in quanto ho un bel po di tera dentro. Spero non si scassi mai nulla ma la speranza non è una tattica😂. Se ci fosse un metodo di compressione dei file cosi efficiente da poter fare un bakups di terabite di dati in 1/3 o meno dello spazio sarebbe anche fattibile....???🤔

[@morrolinux]

In realtà l'object storage non costa poi tanto, ho quasi 1TB di backup sincronizzati giornalmente in maniera differenziale e ogni mese mi arriva una fattura che sarà l'importo di un paio di caffè.

[@SnakeEstrai]

@@morrolinux si certo io ho cubbit per quei file di vitale importanza ma quelli su truenas se li perdo sono persi e sinceramente mi rompererebbe le scatole,anche se non sono importantissimi

[@SnakeEstrai]

@@morrolinux parlo di 10tera e passa,sarebbe una spesa su cloud non indifferente

[@morrolinux]

​@@SnakeEstraiallora per quelli potresti anche pensar di comprare un segate da 12 TB o giù di lì, metterci ZFS in configurazione singolo disco e sincronizzare i tuoi dati li sopra ogni notte. Alla fine si tratterebbe del backup di un sistema in raid e con ZFS avresti la notifica di quali file si corrompono se qualcosa va storto, per una soluzione al massimo risparmio potrebbe anche andare se non è nulla di cruciale

[@emilie1977]

cosa ne pensate di backblaze? dico per i backup

[@brunolombardini7342]

Infatti uso disci max 500 giga! a volte anche meno così se uno mi molla ho sempre la riserva ... aahahaha!

[@A77ILA]

Ma quindi non mi è chiaro, per un ambiente in produzione, l'unico modo per essere sicuri di avere sempre i dati a posto è quello di smontare, rimontare e fare lo scrub? lo trovo assurdo

[@giacomo1439]

Quindi anche su raid più "avanzati" come il RAID5 il filesystem ext4 non si sarebbe accorto di nulla o ci "avrebbe pensato" il raid?

[@morrolinux]

A livello di filesystem consapevolezza zero, a livello di controller forse, ma leggevo che la partita è usata solo per ricostituire il raid in caso di rottura di un disco e se fosse vero direi che siamo nelle stessa situazione. L'unica sarebbe provare... Vediamo come và questo video, magari riesco a fare un sequel.

[@giacomo1439]

@@morrolinux Capisco, mi sa che coglierò l'occasione di upgradare il nas per rifare tutto meglio :) Grazie mille di questi video e sicuramente un sequel sarebbe molto apprezzato!

[@DenisSoiMi]

Il raid 5 avendo i dati scritti su 3 dischi, alla corruzione di 1 dovrebbe averne 2 di buoni che permetterebbero il recupero del terzo. Il test è d'obbligo.😀

[@tuttocrafting]

​@@morrolinuxbeh io avevo un pool dati btrfs sopra a Md in raid 5. 4 dischi. Ho perso diversi TB al fallimento di un disco a quanto pare ogni volta che il pool entrava e usciva dal raid venivano ricalcolati i checksum e man mano corrompevano i dati ogni volta di più. Nel mio caso non ho idea di cosa sia successo, non lo ho mai capito. Sono passati quasi 2 anni e da allora non ho più dati sui dischi. Ho testato i controller HBA ho testato i singoli dischi ho testato tutto. Non sono mai riuscito a replicare il problema neanche usando gli stessi dischi di cui appunto uno "rotto" Perché "rotto"!? Perché non mi ha più dato problemi quel disco, dopo avermi fatto perdere praticamente tutto quello non sotto backup ha smesso di fare lo scherzo. Ora ho una macchina con 2 HBA 8 dischi fermi perché non so cosa sia successo e non mi fido a farci più niente.

[@morrolinux]

@@tuttocrafting Qui posso solo speculare, ma due osservazioni mi sorgono spontanee: 1. Perché BTRFS su MD quando con BTRFS puoi far gestire il RAID direttamente al filesystem? 2. Btrfs su RAID5 è notoriamente inaffidabile a detta anche degli sviluppatori, ma dovrebbe migliorare con il kernel 6.7.

[@alealba2383]

Io non so quali dischi utilizzate e se li trovate nelle discariche. Io uso ext4 da un decennio, sia server che desktop cin rsid 5 e con buoni backup e problemi seri non ne ho mai avuti

[@ivanzb89]

se non verifichi mai non avrai mai problemi... occhio non vede cuore non duole

[@alealba2383]

@@ivanzb89 ma che pataffiate dici. Ho scritto che non verifico mai? Quanta superficialità nei commenti

[@tom_zanna]

Che ci dici del "cow that won't eat your data"?

[@patriziobiancalani5323]

scusa perche' non fai la prova anche con ext3 visto che questo se non ricordo male fa anche il journal dei dati ?

[@DenisSoiMi]

anche ext4, ha poco senso usare ext3.

[@patriziobiancalani5323]

@@DenisSoiMi beh in realta a me risultava facesse il logging anche dei dati e non solo dei metadati, poi se in questa situazione possa servire non lo so .

[@gabriledyt]

Ntfs invece?

[@morrolinux]

Idem, fai un giro nei commenti ho risposto già 10 volte :)

[@gabriledyt]

@@morrolinux non si era aggiornata la vista dei commenti bruh

[@aanndnned]

A guardare il sorgente del tool probabilmente si poteva forzare un qualsiasi colore a scelta ignorando il loro "ansi_force_colour", ma va bene così, ignorerò che nero su nero sia una pessima scelta per fare del debug...

[@morrolinux]

Scherzi? In realtà è una tecnica: ti costringe a stare sempre concentrato 😂

[@kibit86]

Morro probabile che un sync prima del md5sum avrebbe manifestato la discrepanza di checksum senza necessità di smontare e rimontare!

[@DenisSoiMi]

Ho pensato lo stesso ma non ne sono certo, il sync fa il flush delle scritture pendenti in cache ma non sono certo che invalidi la cache stessa rileggendo dal disco, sarei curioso.

[@morrolinux]

Vado a memoria perciò prendilo con un pizzico di sale, ma il sync non cambiava nulla perché non veniva invalidata la cache. Le scritture avevo verificato che avvenissero già prima del sync perché il disco virtuale le loggava.

[@kibit86]

@@morrolinux allora forse una cosa del genere: sync; echo 3 > /proc/sys/vm/drop_caches Sarebbe simpatico da provare

[@jameskovalsky5577]

sto bestemmiando da una settimana per recuperare dei dati su un vecchio HD con partizione cifrata LUKS ne avevo 2 uno sono riuscito a montarlo e recuperare tutto mentre l altro riesco a montarlo ma risulta vuoto, sto impazzendo

[@morrolinux]

Backup, backup, backup, next time...

[@davidevagginelli1678]

oh però a che avevi fatto una zpool in raid1 potevi provare ext4 su zvol, e lì usciva il vincitore mi sa 😅

[@downinthebunnyhole]

Morro, l'analisi che fai per { ext3, ext4, xfs, ... } si basa interamente sulla modellazione di errori IO silenti mediati da dischi virtuali che, come tali, non tengono conto che un reale HDD sia costantemente monitorato da CBIT (lato firmware, sull'elettronica dell'HDD) tutti segnalati da S.M.A.R.T. ; cio' consente non solo di anticipare un HDD in procinto di tirare le cuoia (come fa Google, che sfrutta questi dati per rimpiazzare gli HDD in anticipo), ma soprattutto di poter dichiarare "non piu' affidabile" un HDD che abbia "scazzato" o che sia in procinto di farlo (p.e. entro un certo limite gli errori possono essere corretti, ma se S.M.A.R.T. indica che il tasso con cui si verificano queste correzioni tende ad aumentare, quello e' un chiaro sintomo di disco che sta per manifestare problemi ben piu' seri), togliendolo dal Raid1. In questo caso l'altro disco in mirroring non sara' costretto ad "azzoppare" uno o piu' blocchi per mantenere la coerenza.

[@downinthebunnyhole]

tra parentesi, sto sviluppando una applicazione RAID, ad-hoc ...

[@kaya19781]

Potresti provare con un sync per vedere se nota l'errore senza smontarli e montarli.