|
|
|
|
Strumenti |
13-10-2010, 13:14 | #21 |
Senior Member
Iscritto dal: Sep 2003
Città: Bergamo
Messaggi: 1176
|
Concordo su XFS che è infatti il filesystem che utilizziamo come riferimento. Con reiser ho avuto solo problemi...
__________________
VGA? No grazie, preferisco le SERIALI! http://daniele.vigano.me | Home server HP Proliant MicroServer (Fedora 64bit) | Notebook Dell Latitude E5450 (Fedora 64bit) | Mobile Moto G3 GEM HPC Cluster Dell PowerEdge R720xd + R720 + R420 + M1000e + M915 (Ubuntu LTS 64bit) up to 1000 cores | EATON UPS |
13-10-2010, 18:55 | #22 |
Registered User
Iscritto dal: Feb 2005
Messaggi: 1856
|
io con XFS mi trovavo bene ma mi dava un piccolo problema nel portatile con un quake3, reiserfs era veloce ma dopo un anno mi iniziava a rallentare pesantemente, invece ext3 è sempre andato bene.
Un peccato era reiser4, che lo hanno iniziato a usare su linux solo dopo avergli tolto non sò quante cose. Questi piallano reiser4 e rilasciano come stabile un fs come ext4 che ha solo problemi Il filesystem dovrebbe essere sacro, non può perdere dati... |
13-10-2010, 20:12 | #23 |
Senior Member
Iscritto dal: Jan 2005
Città: TTT
Messaggi: 6560
|
Io con xfs ho avuto solo problemi mentre jfs non è male ma un po debole se manca corrente...per ora il migliore per me resta ext4.
__________________
HP 630 core i3 linux inside Jolla phone user |
13-10-2010, 22:51 | #24 |
Senior Member
Iscritto dal: Sep 2004
Città: Padova
Messaggi: 11642
|
non mi passa manco per l'anticamera del cervello di usare ext4 per la partizione dati.
anzi ultimamente sto riusando ntfs, sotto linux è lentissimo, bisogna periodicamente deframmentarlo, ma è di una comodità unica e verametne solido, pure scritto da linux. al nuovo travaso ripasserò il backup dati su ext3. ext4 lo uso solo per gli OS.
__________________
mac user = hai soldi da buttare; linux user = hai tempo da buttare; windows user = hai soldi e tempo da buttare |
16-10-2010, 16:49 | #25 |
Senior Member
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
|
Ciao,
non condivido tutte queste opinioni negative su EXT4, pur premettendo anche io sui sistemi server in produzione uso EXT3. Il discorso di perdita di dati deriva sostanzialmente dal non utilizzo della funzione fsync da parte della maggioranza delle applicazioni. Il non utilizzo di tale funzione comporta che i dati _non_ vengano scritti immediatamente sul disco, ma solo dopo un certo tempo, che di default su EXT4 è ben 60 secondi. Perchè i programmi non tendono a non usare fsync? Perchè, su EXT3, la sua implementazione non era il massimo: quanto un'applicazione la invocava, _tutte_ le code dati di _tutte_ le applicazioni erano flushati su disco. Questo spesso comportava un notevole rallentamento del computer. Proprio per questo motivo (fsync = flush di tutti i dati) EXT3, che sincronizza il journal ogni 3 secondi, in pratica garantisce che ogni 3 secondi tutti i dati vengano scritti su disco, riducendo il rischio di perdita dati. EXT4 invece, supportando il flush dei dati di una singola applicazione, permette al journal di essere flushato su disco ma _non_ sincronizza su disco i dati delle applicazioni. Aggiunto alla possibilità di fare delayed allocation, EXT4 fa più affidamento sulla cache disco e quindi in teoria risulta più esposto a perdita di dati rispetto a EXT3. Il bello è che, da standard POSIX, il comportamente giusto è quello di EXT4: le applicazioni che devono essere sicure della scrittura sul disco, _devono_ eseguire un fsync o un fdatasync. PostgreSQL, per esempio, di default fa proprio questo. Comunque, onde mitigare il problema, su EXT4 sono state eseguite della patch che gli pemettono di comportarsi come EXT3 nella maggioranza dei casi "a rischio" di perdita dati. Il link sopra indicato (http://www.h-online.com/open/news/it...ds-740671.html) spiega la cosa più nel dettaglio. Semmai, una cosa che mi "preoccupa" di EXT4, è il fatto che VirtualBox, quando configurato in modalità AHCI senza buffer di sistema, tende a corrompere le immagini virtuali che girano sul sistema. Devo ancora capire da cosa deriva il problema... Riguardo a BTRFS, ho visto che in Ubuntu 10.10 è stata implementata la possibilità di sceglierlo come filesystem di root. Devo fare qualche test Una nota anche su RAISERFS / RAISER4: oltre ai noti problemi del suo creatore (condannato per omicidio), questi filesystem hanno altri problemi e, avendoli usati per anni sulla mia Gentoo box, posso parlare per esperienza vissuta. RAISERFS tutto sommato è abbastanza stabile ma, raggiunta la versione 3.6, il suo sviluppatore ha praticamente "abbandonato" il progetto, per passare allo sviluppo di REISER4, nonostante ci fossero bug importanti. Questo non è piaciuto molto alla comunità di sviluppatori del kernel... REISER4 invece è piuttosto instabile e più di una volta mi è capitato di perdere tutti i dati della partizione dove lo usavo. Infine, riguardo a NTFS, per quanto tenda a frammentarsi in modo abbastanza rilevante, lo reputo un _ottimo_ filesystem, dato che supporta compressione on-line, encryption on-line, snapshots e, nelle ultime versioni, anche la delayed allocation. Probabilmente, l'unico filesystem attualmente comparabile a livello di feature è ZFS, che purtroppo su linux non abbiamo... Comunque urgono test al riguardo... non appena ho tempo mi metto sotto! Ciao. |
17-10-2010, 11:55 | #26 |
Senior Member
Iscritto dal: Aug 2001
Città: San Francisco, CA, USA
Messaggi: 13826
|
Sarà, ma io non ho mai perso un byte con EXT4 Eppure di roba di sviluppo ne installo un mare (kernel e drivers da git e company) e il sistema mi crasha spesso, ma nonostante ciò non ho mai perso nulla.
Saro fortunato Tra l'altro da quando ho scoperto che si può passare da ext4 a btrfs senza formattare mi sta venendo la tentazione ...
__________________
GPU Compiler Engineer |
17-10-2010, 17:48 | #27 |
Senior Member
Iscritto dal: Oct 2009
Città: Cagliari
Messaggi: 2955
|
aspettiamo pareri su btrfs
|
17-10-2010, 18:29 | #28 | |
Senior Member
Iscritto dal: Apr 2003
Messaggi: 16462
|
Quote:
__________________
MICROSOFT : Violating your privacy is our priority |
|
17-10-2010, 19:07 | #29 |
Senior Member
Iscritto dal: Sep 2003
Città: Bergamo
Messaggi: 1176
|
Quoto e straquoto!
Giusto per informazione ho cominciato da un paio di giorni a provare btrfs sul notebook (ho il vantaggio che non ho dati importanti in locale ) Per ora nulla da segnalare
__________________
VGA? No grazie, preferisco le SERIALI! http://daniele.vigano.me | Home server HP Proliant MicroServer (Fedora 64bit) | Notebook Dell Latitude E5450 (Fedora 64bit) | Mobile Moto G3 GEM HPC Cluster Dell PowerEdge R720xd + R720 + R420 + M1000e + M915 (Ubuntu LTS 64bit) up to 1000 cores | EATON UPS |
17-10-2010, 20:15 | #30 | |
Senior Member
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
|
Quote:
Se vogliamo scendere nel dettaglio, ZFS fa anche data-deduplicazione a livello dei singoli blocchi il che, a mio avviso, lo rende un passo avanti rispetto agli altri filesystem, NTFS incluso. Peccato che in Linux non ci sia... Ciao. PS: grazie per il link, specialmente i commenti sono molto interessanti Ultima modifica di shodan : 17-10-2010 alle 20:33. |
|
17-10-2010, 20:20 | #31 | |
Senior Member
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
|
Quote:
se vuoi provare l'ebrezza della perdita dei dati (), prova a creare un file con vim, salvalo e subito dopo resetta il computer col tasto di reset. Con EXT3 bastano 3 secondi "di vita" al sistema per sincronizzare tutti i dati, mentre EXT4 ritarderebbe molto la scrittura su disco. Al 90% dovresti avere, al riavvio, il file senza dati dentro... a meno che una patch recente (>6mesi) abbia cambiato le carte in tavola. Ciao. Ultima modifica di shodan : 17-10-2010 alle 20:33. |
|
03-04-2014, 20:45 | #32 |
Senior Member
Iscritto dal: May 2008
Messaggi: 979
|
Mi spiace per il necroBump e per il fatto che siamo nella sezione news,
ma visto che si parlava anni fa di btrfs, e visto che da due giorni mi sto informando e lo sto testando.. voglio condividere i miei pareri qui.. Non ho trovato altre sezioni a riguardo sul forum, ma se i mod ritengono di dover spostare/eliminare, non esistate! Inutile dire che dal 2010 ad oggi btrfs è migliorato.. L'ho provato su una macchina test: i5 750 4GB RAM 2xWD Velociraptor 150Gb in RAID-1 software sotto LVM con btrfs.. Ma essenzialmente con tale fs si può eliminare LVM e quindi ho riformattato tutto e rilanciato una nuova installazione.. OBIETTIVO: boottare Debian Jessie Alpha 1 (Testing) con Btrfs che faccia sia da subvolume che da RAID-1. NOTE: Kernel 3.13 Durante l'installazione di wheezy 7.4 al momento della formattazione/partizione degli HDD, non è concesso (Partman non concede per meglio dire) creare il RAID-1 via btrfs. Per questo stupidamente settai LVM e da lì il RAID-1. Leggendo però questa pagina si capisce come sia assolutamente semplice risolvere tale problema. Si può:
I miei dischi si presentano come segue: Codice:
SCSI12 (0,0,0) (sda) - 150,00GB ATA WD WD1500HLFS-0 SCSI12 (0,1,0) (sdb) - 150,00GB ATA WD WD1500HLFS-0 Codice:
LVM VG swapvolumegroup, LV swaplogicalvolume - 9.0 GB Linux device-mapper (linear) SCSI12 (0,0,0) (sda) - 150,00GB ATA WD WD1500HLFS-0 #1 primary 145.5 GB F btrfs / #5 logical 4.5 GB K lvm SCSI12 (0,1,0) (sdb) - 150,00GB ATA WD WD1500HLFS-0 #1 primary 145.5 GB F btrfs / #5 logical 4.5 GB K lvm Iniziamo dando un Codice:
fdisk -l Ora che siamo sicuri di avere due dischi partizionati nel modo corretto, lanciamo l'utility di configurazione del fs btrfs. Nonostante questa pagina dica che la versione è la 0.19, quella usata in Debian8.0Alpha1 è v3.12. Per fare il RAID-1 lanciate: Codice:
mkfs.btrfs -f -m raid1 -d raid1 /dev/sda1 /dev/sdb1 Codice:
/dev/sda1 appears to contain an existing filesystem (btrfs). Error: Use the -f option to force overwrite Codice:
WARNING! - BTRFS v.3.12 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 adding device /dev/sdb1 id 2 fs created label (null) on /dev/sda1 nodesize 16384 leafsize 16384 sectorsize 4096 size 271.08GiB Btfrs v3.12 EDIT1 Questa procedura sembra non funzionare.. porta all'impossibilità di installare un bootloader.. Provando a settare Btrfs solo sul disco 1 e lasciando il secondo senza partizionamento, e - via shell - creando le partizioni con mkfs.btrfs; creando poi un pool e successivamente il RAID-1 porta lo stesso al medesimo errore. Provo quindi ad installare Debian sul disco 1 senza RAID-1 e creare il pool e il raid in un secondo momento ad installazione completata. Aggiornerò il post una volta effettuato il tutto.
__________________
Codice PHP:
|
04-04-2014, 09:16 | #33 |
Senior Member
Iscritto dal: May 2008
Messaggi: 979
|
Confermo che, installando DebianJessie su un disco con fs Btrfs e poi, al primo avvio - tramite mkfs.btrfs - creare il pool in RAID-1 funziona perfettamente!
__________________
Codice PHP:
|
01-06-2014, 12:40 | #34 |
Senior Member
Iscritto dal: Jan 2001
Messaggi: 3278
|
di recente ho voluto sperimentare BTRFS su Archlinux
installazione pulita e opzione compress=LZO (quella più veloce) attiva, ebbene: trasferimento da ext3/4 a BTRFS = 15 MB/s trasferimento da ext3/4 a ext3/4 = 100 MB/s ovviamente test effettuato sugli stessi HDD inoltre una lentezza ESTREMA nell'estrarre un qualsiasi archivio compresso rimango su EXT4 |
25-08-2014, 04:05 | #35 |
Senior Member
Iscritto dal: Oct 2004
Messaggi: 11968
|
Finalmente con l'ultima versione di ubuntu (bhe kubuntu) 14.04 si può usare btrfs anche sulla partizione di boot dove c'è grub quindi lo sto usando da un po'! per me è nettamente meglio di ext4, almeno con i file di piccole dimensioni e non mi fa più rimpiangere reiserfs. Non so nello spostamento di grossi file, ma adesso mi sembra decisamente più veloce quando c'è da gestire piccoli file. Con ext4, rispetto a residerfs, notavo rallentamenti anche nel fare un update cn apt-get
__________________
"Non capisco quelli che dicono che per avere successo devono soffrire. Ma che so', scemi?" Intel Core 2 Quad Q9450 @ 2.66 Ghz, Asus P5K-VM, Ram 4 GB A-Data + 2 GB Kingmax 800 Mhz, Gigabyte GeForce GT 710 2 GB GDDR5 passiva (GV-N710D5SL-2GL), SSD Crucial BX500 CT120BX500SSD1 120 GB, Monitor LCD Samsung S22C300 21.5'', router D-Link DVA-5592 |
02-08-2015, 12:47 | #36 |
Senior Member
Iscritto dal: Dec 2005
Messaggi: 7037
|
Bitrot and atomic COWs: Inside “next-gen” filesystems
Giusto per riportare l'attenzione sui benefici nell'uso di file system che dispongano di determinate caratteristiche, non presenti, in modo integrato, nei file system standard moderni. Considerando pure l'enorme quantitativo di spazio reso disponibile all'utenza da diversi anni, chi non dispone di sistemi molto obsoleti, con risorse troppo limitanti, farebbe bene ad orientarsi su queste soluzioni che, nel caso di linux, significa Btrfs. Nota: Non ho ancora approfondito le caratteristiche del diffuso file system XFS che, a partire da RHEL 7 risulta essere stato selezionato come sistema di default, per capire se presenta le medesime funzionalità.
__________________
Distro:Ubuntu LTS, Debian,SL,OpenBSD I love Linux, Bsd and the free software! Fantasia: fotografica [Icewm]: Thread Ufficiale - light window manager Benchmark Cpu per sistemi Linux/BSD |
27-08-2015, 22:41 | #37 | |
Senior Member
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
|
Quote:
l'articolo di arstechnica purtroppo ha un grossolano errore di fondo: non è così che si simula un bit-root! Se ne è discusso parecchio anche sulla mailing linux linux-raid. In sostanza, quelli di ars hanno: 1) scritto un file (jpeg) 2) modificato, accedendo direttamente al blocco dati e usando un hexeditor, un valore nel jpeg 3) caricato, via filesystem, il file in questione 4) osservato come il file risultava "corrotto". In realtà, un vero bitroot è un'altrerazione spontanei dei dati, che (ed è questo il punto) ha un'altissima probabilità (10^14, almeno) di essere rilevata e bloccata/corretta dai meccanismi ECC integrati nei settori dei dischi! Insomma, la possibilità di avere un bitroot "vero" è davvero bassissima, ancor di più usando tecniche di scrub/autopatrol dei dati (cosa che quasi tutti i controller RAID abilitano di default, e che con il software RAID linux e semplicissima). In sostanza, è molto più probabile che sia la _memoria_ (di sistema, anche ECC, o pure solo quella usata come cache dal disco) a generare errori piuttosto che il disco a non rilevare l'errore. Non voglio essere fraiteso, però: la validazione tramite hash SHA1/256 ha un valore reale, ed è un peccato che non sia inclusa in ulteriori filesystem (XFS, che uso con grande soddisfazione, non ce l'ha. Si è parlato di integrare qualcosa di simile, ma solo per i metadati). E' solo che le cose non funzionano così come presentate da ars. Ciao. |
|
21-09-2015, 21:21 | #38 |
Senior Member
Iscritto dal: Apr 2009
Messaggi: 1060
|
ma ext4 è ancora nella situazione che ho letto nei primi post oppure dopo 5 anni hanno sistemato i problemi?
|
21-09-2015, 22:01 | #39 | |
Senior Member
Iscritto dal: Jan 2008
Messaggi: 8406
|
Quote:
La faccenda del flush era relativa ad una specifica volontà dello sviluppatore di ext4. Non so se sia stato lui a fare dietrofront o gli sviluppatori di software applicativi. |
|
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 03:58.