Re: OT: besser JFS oder XFS ?
Am Donnerstag 28 Februar 2008 schrieb Markus Schulz:
> Am Donnerstag, 28. Februar 2008 schrieb Martin Steigerwald:
> > Am Donnerstag 28 Februar 2008 schrieb Markus Schulz:
> > > Am Donnerstag, 28. Februar 2008 schrieb Dirk Salva:
> > > > On Wed, Feb 27, 2008 at 10:57:28PM +0100, Martin Steigerwald
>
> wrote:
> > > > > Beschränktes Schreiben
> > > > > von Martin Steigerwald
> > > > > Erschienen im Linux-Magazin Sonderheft 2006/04
> > > > > http://www.linux-magazin.de/heft_abo/sonderheft/2006/04/beschra
> > > > >enkt es_schreiben?category=0
> > > >
> > > > Danke. Sag mal, was haben denn dann diese Meldungen bei mir beim
> > > > Booten (Etch, Soft-RAID1) zu bedeuten:
> > > > server kernel: Filesystem "md0": Disabling barriers, not
> > > > supported by the underlying device
> > > > server kernel: Filesystem "md1": Disabling barriers, not
> > > > supported by the underlying device
> > > >
> > > > Nach dem Artikel bin ich davon ausgegangen, daß barriers vom
> > > > Kernel abhängen und nicht vom Laufwerk (sind übrigens zwei
> > > > identische Seagate Model=ST3120026A, WriteCache=enabled).
> > >
> > > Write Barriers funktionieren nicht bei Kombination md-Raid mit XFS.
> > > Laut einer Aussage von Martin F. Krafft [1] soll das mit ext3
> > > allerdings funktionieren. Für Software Raid ist XFS also bisher
> > > wohl nicht die erste Wahl.
> >
> > Ich glaube, dass das so, zumindest bis zum Kernel 2.6.23 nicht
> > stimmt. Da hatte ich ja auch schon Infos zu gepostet:
>
> [.. Beweise ..]
>
> Ok, also alles was über Device Mapper läuft kann keine Write-Barriers
> nutzen, egal was für ein Filesystem drüber liegt. Irgendwie dann doch
> schon recht ärgerlich. Da dein Bugreport noch als NEW deklariert ist,
> dürfte das also auch für alle aktuellen Kernel noch gelten?
Okay, Probe aufs Exempel:
root@shambala:~ -> cat /proc/version
Linux version 2.6.24.3-tp42-toi-3.0-rc5 (martin@shambala) (gcc version
4.2.3 (Debian 4.2.3-1)) #1 PREEMPT Tue Feb 26 22:24:21 CET 2008
Auf meinem Spiel-LVM auf meinem ThinkPad T42.
root@shambala:~ -> lvcreate -L3G -n ext3 shambala
Logical volume "ext3" created
root@shambala:~ -> lvcreate -L3G -n jfs shambala
Logical volume "jfs" created
root@shambala:~ -> lvcreate -L3G -n xfs shambala
Logical volume "xfs" created
root@shambala:~ -> lvcreate -L3G -n reiserfs shambala
Logical volume "reiserfs" created
root@shambala:~ -> mkfs.ext3 /dev/shambala/ext3
mke2fs 1.40.6 (09-Feb-2008)
Warning: 256-byte inodes not usable on older systems
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
196608 Inodes, 786432 Blöcke
39321 Blöcke (5.00%) reserviert für den Superuser
erster Datenblock=0
Maximum filesystem blocks=805306368
24 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
8192 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken:
32768, 98304, 163840, 229376, 294912
Schreibe Inode-Tabellen: erledigt
Erstelle Journal (16384 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt
Das Dateisystem wird automatisch alle 32 Mounts bzw. alle 180 Tage
überprüft,
je nachdem, was zuerst eintritt. Veränderbar mit tune2fs -c oder -t .
root@shambala:~ -> mkfs.jfs /dev/shambala/jfs
mkfs.jfs version 1.1.11, 05-Jun-2006
Warning! All data on device /dev/shambala/jfs will be lost!
Continue? (Y/N) y
-
Format completed successfully.
3145728 kilobytes total disk space.
root@shambala:~ -> mkfs.xfs /dev/shambala/xfs
meta-data=/dev/shambala/xfs isize=256 agcount=4, agsize=196608
blks
= sectsz=512 attr=2
data = bsize=4096 blocks=786432, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
root@shambala:~ -> mkfs.reiserfs /dev/shambala/reiserfs
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
A pair of credits:
Alexander Zarochentcev (zam) wrote the high low priority locking code,
online
resizer for V3 and V4, online repacker for V4, block allocation code, and
major
parts of the flush code, and maintains the transaction manager code. We
give
him the stuff that we know will be hard to debug, or needs to be very
cleanly
structured.
Oleg Drokin was the debugger for V3 during most of the time that V4 was
under
development, and was quite skilled and fast at it. He wrote the large
write
optimization of V3.
Guessing about desired format.. Kernel 2.6.24.3-tp42-toi-3.0-rc5 is
running.
Format 3.6 with standard journal
Count of blocks on the device: 786432
Number of blocks consumed by mkreiserfs formatting process: 8235
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: ad8d7a3e-eeaf-460e-b55d-856a44b54ba8
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/shambala/reiserfs'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok
Tell your friends to use a kernel based on 2.4.18 or later, and especially
not a
kernel based on 2.4.9, when you use reiserFS. Have fun.
ReiserFS is successfully created on /dev/shambala/reiserfs.
In einem anderen Fenster läuft
tail -f /var/log/syslog
Ext3
===
root@shambala:~ -> mount -o barrier=1 /dev/shambala/ext3 /mnt/zeit
root@shambala:~ -> touch /mnt/zeit/barriertestfile
root@shambala:~ -> umount /mnt/zeit
Der touch-Befehl ist erforderlich, da JBD erst beim Journal Commit nach
dem ersten Schreibvorgang motzt. Das Commit Timeout dafür ist
standardmäßig 5 Sekunden (Mount-Option commit).
führt zu:
Feb 28 20:31:46 shambala kernel: kjournald starting. Commit interval 5
seconds
Feb 28 20:31:46 shambala kernel: EXT3 FS on dm-0, internal journal
Feb 28 20:31:46 shambala kernel: EXT3-fs: mounted filesystem with ordered
data mode.
Feb 28 20:32:02 shambala kernel: JBD: barrier-based sync failed on dm-0 -
disabling barriers
==> Nada, womit die hier aufgeworfene Frage bereits beantwortet wäre
JFS
===
Ähm, okay, das lass ich mal aus. Das hat meines Wissens keinen
Barrier-Support. Es macht jedoch meiner Erinnerung nach etwas anderes: Es
verwendet normale Cache Flushes. Ob die immer funktionieren, weiß ich
allerdings auch nicht genau.
Na, ich glaube, ich hab da in meinen Artikel was zu geschrieben.
Okay, trotzdem mal schauen:
root@shambala:~ -> mount /dev/shambala/jfs /mnt/zeit
root@shambala:~ -> touch /mnt/zeit/testfile
root@shambala:~ -> umount /mnt/zeit
Führt zu:
Feb 28 20:39:22 shambala kernel: JFS: nTxBlock = 8192, nTxLock = 65536
==> Entweder bringt JFS keine Meldung oder wie ich vermute, hat JFS auch
im aktuellen Kernel keinen Write Barrier Support.
XFS
===
root@shambala:~ -> mount /dev/shambala/xfs /mnt/zeit
root@shambala:~ -> umount /mnt/zeit
führt zu:
Feb 28 20:36:30 shambala kernel: Filesystem "dm-2": Disabling barriers,
not supported by the underlying device
Feb 28 20:36:30 shambala kernel: XFS mounting filesystem dm-2
Feb 28 20:36:30 shambala kernel: Ending clean XFS mount for filesystem:
dm-2
==> Also auch nada
Reiserfs
=========
root@shambala:~ -> mount -o barrier=flush /dev/shambala/reiserfs /mnt/zeit
root@shambala:~ -> umount /mnt/zeit
Führt zu:
Feb 28 20:37:55 shambala kernel: ReiserFS: dm-3: found reiserfs
format "3.6" with standard journal
Feb 28 20:37:55 shambala kernel: ReiserFS: dm-3: using ordered data mode
Feb 28 20:37:55 shambala kernel: reiserfs: using flush barriers
Feb 28 20:37:55 shambala kernel: ReiserFS: dm-3: journal params: device
dm-3, size 8192, journal first block 18, max trans len 1024, max batch
900, max commit age 30, max trans age 30
Feb 28 20:37:55 shambala kernel: ReiserFS: dm-3: checking transaction log
(dm-3)
Feb 28 20:38:03 shambala kernel: reiserfs: disabling flush barriers on
dm-3
Feb 28 20:38:03 shambala kernel: ReiserFS: dm-3: Using r5 hash to sort
names
Feb 28 20:38:03 shambala kernel: ReiserFS: dm-3: warning:
Created .reiserfs_priv on dm-3 - reserved for xattr storage.
==> Also auch nada
Zusammenfassung
============
Das ist mein aktueller Stand zum Thema:
- Ich nutze auf meinem Notebook "normale" Partitionen für produktive Daten
und LVM nur zum Spielen
- Write Cache mit hdparm aus, wenn Device Mapper im Einsatz, und
Controller ohne NVRAM. Es macht bei XFS meines Erachtens nicht so viel
azs, da XFS selbst bereits sehr optimiert arbeitet und der Page Cache
sein Übriges tut. Ich hab damals mit Kernel 2.6.16 auf meinem Notebook
subjektiv keinen großen Unterschied gesehen. Bei einem unserer Kunden
läuft ein kompletter Webcluster mit externen RAID Array (ohne NVRAM) mit
auf allen Ebenen ausgeschaltetem Write Cache.
- Write Barriers aus, wenn Controller mit NVRAM im Einsatz. Fein beim
Einsatz von ICP Vortex-Controllern ;-).
- Blockbasiertes Journalling ist in Situationen ohne Write Barrier mit
Write Cache womöglich wirklich robuster. 100% drauf verlassen würde ich
mich auch da nicht. Daher schalte ich auch für ext3 den Write Cache aus,
wenn Write Barriers nicht funktionieren.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: