File system: io continuo a preferire reiserfs

[zephyr83]

Sono l'unico? ho provato sia EXT4 che BTRFS (cn kubuntu adesso ma anche in passato con frugalware) ma con reiserfs il sistema mi sembra sempre più "reattivo" e SOPRATUTTO ci mette molto meno ad avviarsi! :stordita: Anche per aggiornare i repository e i pacchetti con reiserfs ho sempre fatto prima, e neanche di poco! con ext4 ci ho sempre messo di più!
Eppure ext4 e btrfs sn decisamente più "nuovi", ci sn molti bench che dimostrano una loro superiorità in vari ambiti! Per caso reiserfs ha ancora prestazioni decisamente superiori cn file di piccole dimensioni (di cui l'hard disk è invaso e sicuramente incidono molto sia al boot che nell'aggiornamento dei pacchetti)?? Perché se la ragione è questa continuerò con il buon vecchio reiserfs ancora per molto!! :fagiano:

[eclissi83]

anche io uso reiserfs sui miei computer e lo trovo piu' reattivo degli altri; in produzione uso in genere ext3, piu' che altro per avere meno difficolta' in caso di corruzione del fs, ed xfs per le partizioni dove ho file grandi ed i backup...

[zephyr83]

anche io uso reiserfs sui miei computer e lo trovo piu' reattivo degli altri; in produzione uso in genere ext3, piu' che altro per avere meno difficolta' in caso di corruzione del fs, ed xfs per le partizioni dove ho file grandi ed i backup...
uso ext3 sul secondo hard disk contenente i dari proprio per quel motivo.....però ora preferisco usare ntfs che tanto anche linux gestisce senza alcun problema, meglio del contrario (ext3 su windows)

[kernelex]

anch'io reiserFS per / e ntfs dati.
avessi solo linux, reiserfs e ext3

[AMD_Edo]

Anch'io non ho trovato molto performante EXT4... tanto che sia sul mio nas che sul mio portatile continuo ad utilizzare JFS perché lo trovo ottimo in tutte le situazioni!

[Xemertix]

Provato mkfs.ext4 -T largefile -O extents,uninit_bg,dir_index -j -m 0 /dev/sda + tune2fs -c 0 -i 0 /dev/sda ? le impostazioni di default degli ext* sono shit.

Come ripeto sempre,io voglio un fs con ottimo supporto alla transparent compression,per ora vedo solo reiser4,btrfs. Se il processore è decente,la velocità i/o dovrebbe migliorare in molti scenari,soprattutto abilitando la compressione lzo.

ps.in merito a reiserfs c'è un'opzione di mount chiamata notail che sembrerebbe influenzare le prestazioni http://www.funtoo.org/wiki/Funtoo_Filesystem_Guide,_Part_2

[Gimli[2BV!2B]]

@Xemertix, mi risulta che extents, uninit_bg e dir_index siano ormai attivi di default in quasi tutte le distribuzioni.
Le opzioni impostate di default dovrebbero essere visibili nel file /etc/mke2fs.conf (anche i dettagli del profilo largefile).

Un'opzione interessante che dovrebbe permettere di guadagnare qualcosina senza perdere funzionalità importanti è noatime -> in lettura non aggiornare l'informazione sul momento dell'avvenuto accesso all'inode.
Ricordo di averla utilizzata sia nelle partizioni ext4 che in quella reiser.

Nella Gentoo da battaglia mi pare di aver attivato pure data=writeback nelle partizioni ext4 ed il sistema è sopravvissuto a tanti crash (il resto del pc no, ma questa è un'altra storia...).

Resta che al solito non son stato lì a controllare le differenze di prestazioni: ho provato principalmente per curiosità dopo aver trovato alcuni benchmark che evidenziavano qualche miglioramento in varie modalità di utilizzo (benchmark che avrei volentieri riportato, ma non li ho rintracciati).

[Xemertix]

ecco il mio mke2fs.conf
[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
blocksize = 4096
inode_size = 256
inode_ratio = 16384

[fs_types]
ext3 = {
features = has_journal
}
ext4 = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
}
ext4dev = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
options = test_fs=1
}
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
floppy = {
blocksize = 1024
inode_size = 128
inode_ratio = 8192
}
news = {
inode_ratio = 4096
}
largefile = {
inode_ratio = 1048576
blocksize = -1
}
largefile4 = {
inode_ratio = 4194304
blocksize = -1
}
hurd = {
blocksize = 4096
inode_size = 128
}

Qui base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr mi pare manchi qualcosa,a meno che non sia inclusa in ext_attr
ps.potrebbe essere che quanto scritto in base_features venga aggiunto alla voce features dell'fs scelto,ma dalle prove che ho fatto non mi pare sia così.

[Gimli[2BV!2B]]

In Debian con mkfs.ext4 -m 0 /home/gimli/linux.ext4 (file da 128 MB esatti) ho ottenuto un filesystem con queste opzioni attive:Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isizeInodes e blocchi:Inode count: 32768
Block count: 131072
Reserved block count: 0
Free blocks: 121285
Free inodes: 32757
First block: 1
Block size: 1024
Fragment size: 1024

Con -T largefile crea un buon filesystem da archiviazione con blocchi da 4096 e pochi inodes:Inode count: 128
Block count: 32768
Reserved block count: 0
Free blocks: 28647
Free inodes: 117
First block: 0
Block size: 4096
Fragment size: 4096

Il file è praticamente identico, salvo un paio di profili in più e qualche impostazione aggiuntiva:[defaults]
base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
default_mntopts = acl,user_xattr
enable_periodic_fsck = 0
blocksize = 4096
inode_size = 256
inode_ratio = 16384

[fs_types]
ext3 = {
features = has_journal
}
ext4 = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
auto_64-bit_support = 1
inode_size = 256
}
ext4dev = {
features = has_journal,extent,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize
inode_size = 256
options = test_fs=1
}
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
floppy = {
blocksize = 1024
inode_size = 128
inode_ratio = 8192
}
big = {
inode_ratio = 32768
}
huge = {
inode_ratio = 65536
}
news = {
inode_ratio = 4096
}
largefile = {
inode_ratio = 1048576
blocksize = -1
}
largefile4 = {
inode_ratio = 4194304
blocksize = -1
}
hurd = {
blocksize = 4096
inode_size = 128
}

[Gimli[2BV!2B]]

largefile4 non l'avevo mai visto, è ancora più estremo:Inode count: 32
Block count: 32768
Reserved block count: 0
Free blocks: 28653
Free inodes: 21
First block: 0
Block size: 4096
Fragment size: 409621 inode mi sa che finiscono molto velocemente, però pensando di archiviare solo file da circa dieci mega di dimensione dovrebbero bastare anche per riempire la mia "partizione" da 128 mega (non ricordo se ne occorre uno per ogni file, ma credo ne possano servire altri per journal o altra roba).