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! 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!!

[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]

Originariamente inviato da 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...

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_Fi..._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_isize

Inodes 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:            4096

21 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).