ossblog

Login:: equilibrium
Karma:: 92
Nome Completo:: Mauro
Sito web:: http://
Registrato dal:: 2007-03-02 18:22:57
Commenti scritti:: 42
Segnalazioni inviate:: 0
Descrizione:

Gli ultimi commenti di equilibrium:

Dhcp server possono prendere il controllo dei client

(0 punti) (0 commenti)

Anche su Gentoo FORTIFY_SOURCE è abilitata di default globalmente (dall'inizio del '09 per giunta): http://archives.gentoo.org/gentoo-dev/msg_8efa8bf5aad1fd2d724f4ba001b26ff7.xml quindi Gentoo non è affetta da questa vulnerabilità

8 mesi fa

Drupal eletto miglior CMS Open Source

(0 punti) (0 commenti)

@andre "cimi": nei commenti di questo post non ho mai espresso opinioni ne su Drupal ne su WP, quindi non mettermi in bocca parole che non ho detto. @ekerazha: ti stai sminuendo, le community da cui sei stato bannato e/o messo in ignore list sono molto di più delle due che hai citato.

1 anno e 4 mesi fa

KDE 4.0 Beta 4 è qui!

(0 punti) (25 commenti)

@orchidea: "pagare" era inteoso nel senso di "pagare la licenza d'uso".

2 anni e 4 mesi fa

Ubuntu regina di Google Trends

(-1 punto) (11 commenti)

la sagra dei luogi comuni U_U che tristezza…

2 anni e 7 mesi fa

GCC 4.2 is out!

(0 punti) (6 commenti)

@paolino: gcc4.3 sara' un upgrade ancora piu' traumatico del gcc4.2, perche' abilita di default i padwarn –> http://www.cyrius.com/journal/gcc/gcc-4.3-pedwarn quindi un sacco di software non compilera' piu' correttamente, con le dovute conseguenze e bagno di sangue upstream e per i tester/pacchettizzatori delle varie distro.

2 anni e 10 mesi fa

Riprende lo sviluppo di EXT4

(0 punti) (36 commenti)

citaz: Ogni quanto ti risulta che venga fatto? @ekerazha: te l'ho scritto nei miei post precedente piu' di una volta: il sync time di XFS e' dato dal parametro sysctl: fs.xfs.xfssyncd_centisecs se guardi la documentazione del kernel (Documentation/filesystem/xfs.txt) trovi scritto che per quel parametro di sysctrl, il valore di default e' 3000, cioe' 30sec, e al MASSIMO si puo' impostare 720000 ovvero 2 ore. Il default e' 30 sec e oltre le 2 ore non si puo' forzare il lease time del syncd di XFS, quindi avere i buffer in RAM per piu' del tempo impostato dal syncd non e' possibile.

2 anni e 10 mesi fa

Usare ZFS su Linux grazie a FUSE

(0 punti) (5 commenti)

è già qualcosa, sempre meglio di nulla. ben venga quindi il supporto ZFS tramite FUSE

2 anni e 10 mesi fa

Riprende lo sviluppo di EXT4

(0 punti) (36 commenti)

@ekerazha: non capisco se ci sei o ci fai, comunque nella mia precedente risposta ti ho invitato non solo a leggere le FAQ della SGI ma anche il TechPub (oltre all' IBM DeveloperWorks), cosa che non hai fatto, altrimenti sapresti che la delayed-allocation non ha nulla a che vedere con la RAM (cosa che sostieni tu) in quanto passa i dati direttamente al meta-journal che è un file che risiede sull'harddisk e non in RAM. In RAM ci stanno solo i buffer temporanei dei processi di I/O e di allocazione (già qui dimostri di non sapere una fava su come funziona il filesystem XFS di suo, e ti *re-invito* a leggerti l'XFS Ondisk Format che è disponibile sul sito della SGI). In questi buffer transitano ANCHE i metadata, ma non restano residenti in RAM per giorni come vorresti far credere tu, ma ci restano per un tempo relativamente molto breve (di default è MASSIMO 30sec). Ora, che tu dica, che dopo un crash parecchi tuoi dati sono tornati "indietro nel tempo" di una settimana è pure follia. Cioè tu vorresti dirmi che hai creato un file il giorno X, e nei giorni successivi ha accesso/spento il tuo sistema svariate volte (quindi i tuoi dati sono stati flushati dal file di log del meta-journal e scritti su disco) ma dopo un crash del sistema, il filesystem ha deciso arbitrariamente di ripristinare la versione del file X a quella di qualche giorno prima? O_o E come è possibile che ciò sia avvenuto? il meta-journal, una volta che ha scritto le nuove modifiche (metadata) nel file, non tiene nessuna copia dei metadata già scritti. Anche prendendo per buona la tua tesi sui metadata costantemente cachati in RAM (che comunque non è assolutamente vera!!), hai comunque spento e acceso il tuo pc più volte in quei giorni, quindi è impossibile che ci fosse ancora qualche "residuo" in RAM. Ora tu potresti anche rispondermi sostenendo che in quei giorni non hai mai acceso e spento il PC, bene, se così fosse il meta-journal non tiene i suoi log per così tanto tempo, perchè di default il flush dei dati avviene ogni 30sec (vedere documentazione allegata al kernel, in particolare il parametro sysctls: fs.xfs.xfssyncd_centisecs) quindi in 48ore i tuoi dati sono stati flushati e il metajournal non ne ha più traccia già da parecchio tempo. E non puoi nemmeno dire di avere impostato valori di syncd superiori alle 24H, perchè il massimo che XFS consente è un delay di 2 ore. Non ha senso quello che hai scritto, avrebbe senso se i tuoi file dopo il crash fossero diventati illegibili (totalmente o parzialmente) o fossero spariti dagli inodes. Questo SI' che sarebbe possibile, ma non che il contenuto dei tuoi dati è tornato ad essere quello di qualche giorno prima. Ciò non può accadere per nessun filesystem, soprattutto a quelli dotati di meta-journal, al massimo avresti perso le ultime 2 ore di modifiche (impotizzando valori di syncd custom), o per dirla nei tuoi termini, i dati "sarebbero tornati indietro di due ore". Ma da qui a dire che "l'intero sistema è tornato indietro di 1 settimana" è pura follia. Mi piacerebbe molto sapere che motivazioni tecniche e plausibili ci sono alla base della tua teoria tali da imputare ad XFS quanto da te asserito, soprattutto considerando che, come ho spiagato sopra, ne il meta-journal ne il sistema di syncd ne tanto meno il meccanismo di delayed-allocation possono provocare il TUO problema perchè AL MASSIMO possono gestire metadata di 2 ore. Siccome di motivazioni plausibili non ce ne sono (io una ce l'ho, ma evito per non generare un altro flame), e considerando il fatto che mi sono stufato di continuare questa discussione sulla base delle tue patetiche argomentazioni, ti considero semplicemente un troll e d'ora in avanti ti ignorerò. E ti ripeto: non discuto sul fatto che hai avuto problemi di perdite di dati (nessun filesystem è immune da problemi e non ho mai scritto che XFS è esente da perdite di dati), ma dubito fortemente che il TUO SPECIFICO CASO sia imputabile al filesystem (avrei asserito le stesse argomentazioni anche se tu avessi citato un altro filesystem al posto di XFS). citaz: "Forse oltre a leggere le FAQ sul sito acquisendo una conoscenza superficiale dell'argomento, dovresti studiarti innanzitutto il funzionamento basilare di un file-system (e di un hard disk) ed in seguito procedere allo studio del codice relativo al file-system XFS all'interno del kernel" non ti preoccupare che sono tutti argomenti che conosco perfettamente, invece lo stesso non si può dire di te visto che le risposte che dai non fanno altro che confermare una TUA conoscenza superficiale degli argomenti (dici pure di usare XFS solo da pochi mesi…), stravolgendo e riportando concetti (mentendo palesemente, vedi la tua teoria sui metadata) al solo scopo di avere ragione a tutti i costi e fare FUD. Ora sei anche libero di insultarmi se lo ritieni. Luca 6,41- 42: "Perché guardi la pagliuzza che è nell'occhio del tuo fratello, e non t'accorgi della trave che è nel tuo? Come puoi dire al tuo fratello: Permetti che tolga la pagliuzza che è nel tuo occhio, e tu non vedi la trave che è nel tuo? Ipocrita, togli prima la trave dal tuo occhio e allora potrai vederci bene nel togliere la pagliuzza dall'occhio del tuo fratello"

2 anni e 10 mesi fa

Riprende lo sviluppo di EXT4

(0 punti) (36 commenti)

@Xanderob: dipende da quello a cui è destinato il filesystem, XFS e JFS sono equiparabili quasi in tutto. Per uso desktop, tra i due è sicuramente preferibile XFS perchè è meno avido di risorse rispetto a JFS. Se invece hai intenzione di usare OpenMosix o altro sistema di clustering è preferibile JFS perchè è maggiormente stabile e performante rispetto ad XFS (va da se che se stai realizzando un sistema cluster serio da mettere in produzione, allora non userei ne XFS ne JFS, ma Lustre che è il top della gamma). Negli altri ambiti sono equiparabili. @ekerazha: vedo che non hai capito una fava di quello che ho scritto, ti rimando alla lettura delle FAQ della SGI –> http://oss.sgi.com/projects/xfs/faq.html in cui viene spiegato molto bene il problema della Write Cache e della perdite di dati in seguito ad un crash. In modo particolare leggiti la FAQ "Why do I see binary NULLS in some files after recovery when I unplugged the power?" e seguenti, specialmente la parte che recita: "Many drives use a write back cache in order to speed up the performance of writes. However, there are conditions such as power failure when the write cache memory is never flushed to the actual disk. **This causes problems for XFS and journaled filesystems in general** because they rely on knowing when a write has completed to the disk" Il delayed-allocation di XFS non è la causa della perdita di dati, i fattori sono altri e riguardano le "write hardware barrier" (che sono presenti nel kernel linux solo dalla versione 2.6.18 e successive) non attive, il mancato uso di O_SYNC/O_DIRECT in fase di mounting (che dal kernel 2.6.21 è abilitato di default, mentre per le versioni precedenti va abilitato manualmente con l'apposita opzione) e l'uso della Write Cache *SENZA* un UPS. La leggenda metropolitana nasce proprio quando le persone leggono "serve un UPS" e recepiscono tale informazione come soluzione del problema, quando in realtà la soluzione è: DISATTIVARE la Write Cache dell'harddisk (che è una funzione hardware dello stesso e non del filesystem!!) e se sono supportate, usare le Write Barrier Hardware. Se configuri XFS/JFS in modo corretto, stai sicuro che i dati non li perdi anche se attacchi/stacchi l'alimentazione a caldo ripetutamente. Può capitare che si corrompano i dati dei buffer del journaling e dei metadatas i quali sono contenuti in RAM, e quindi in caso di crash ti puoi ritrovare con parecchi file corrotti. Fino a prova contraria però la RAM non ha nulla da spartire con il filesystem, e se qualcosa si corrompe è solo per un problema hardware (della RAM) dovuto a scarsa qualità dei materiali, o al software che fa porcate in fase di allocazione/deallocazione (vedi bug di HAL precedentemente citato). Ovviamente non contesto il fatto che tu abbia avuto delle perdite di dati, o che XFS/JFS ne siano soggetti. E' ovvio che ci sono, XFS/JFS non ne sono immuni, ma sono comunque eventi rarissimi, e parlo delle *vere* perdite/corruzioni di dati. Nel caso specifico di XFS una corruzione generata da se stesso la si nota perchè il filesystem entra in modalità 'freeze', generando l'errore 990 in fase di mount (ti viene impedito di montare la partizione fin quando non togli la flag freeze). Anche JFS ha una feature analaga chiama modalità 'dirty' ed entrambe servono per evitare che l'idiozia dell'utente favorisca il propagarsi della corruzione sul resto del filesystem. In queste specifiche situazioni SI, il filesystem ha generato corruzione e/o perdite di dati, in tutti gli altri casi, non ne è responsabile il filesystem ma altri fattori (che come ho spiegato sopra ricadono per il 99% sulla questione delle Write Cache e della RAM bacata). Da notare che il problema della Write Cache non è specifica di XFS o JFS, ma qualora non lo avessi ancora capito, si presenta su QUALSIASI filesystem di tipo journaling perchè tale feature dell'harddisk vanifica il journing stesso in determinate circostante (crash, interruzione dell'alimentazione). citaz: "Evitiamo di raccontare in giro certe cose quando non se ne ha un'esperienza personale." Guarda che le cose che ho scritto mica me le sono inventate, ti invito a leggerti il TechPubs di SGI (in particolare l' XFS Ondisk Format) e la documentazione ufficiale di IBM DeveloperWorks, dove potrai trovare riscontro a tutto ciò che ho riportato. Sicuramente sono testi molto più affidabili di quanto viene riportato invece da wikipedia (da cui, IMHO, presumo tu abbia tratto le tue informazioni). (scusate la lunghezza eccessiva del post)

2 anni e 10 mesi fa

Riprende lo sviluppo di EXT4

(0 punti) (36 commenti)

@aven: ecco bravo, avevo dimenticato di dirlo nel mio precedente post, un'altra leggenda metropolita su XFS/JFS e' che si mangia parzialmente alcuni file di sistema, tipo fstab, mtab o altri. Mi spiace contraddirti, non c'entra nulla il filesystem, e' un BEN NOTO bug di alcune (vecchie) versioni di hal e dbus. Il difetto si presenta comuqnue con tutti i filesystem, non solo XFS.

2 anni e 10 mesi fa

Vedi tutti i commenti di equilibrium.