Seite 1 von 6
Snapshot 09.10.2006
Verfasst: Di 10 Okt 2006, 0:02
von hepp
danke riker, dass es weitergeht!
Und dann gleich mit haufenweise Neuerungen!
Bevor ich mich nun in weitere Dateisystemtests (xfs) stürzte ...
im letzten Testsnapshot 2006_0926_1623 hattest Du ja die Aufnahmeverzeichnisauswahlmenü-Änderungen von Günther eingebaut.
Hatte den TestSnap nun auch einige Tage im Einsatz und für gut befunden.
Frage:
sind Günthers Erweiterungen im aktuellen Snap enthalten?
http://tuxbox-forum.dreambox-fan.de/for ... highlight=
außerdem gibts da noch günthers/mb405 userlevel patches.
http://tuxbox-forum.dreambox-fan.de/for ... c&start=20
ist der nfs-server noch drin?
Verfasst: Di 10 Okt 2006, 7:32
von petgun_download
hi,
Riker hat geschrieben:Da die Tools einges an Platz brauchen ist der Snap viel grösser geworden
was bedeutet das konkret?
Dauert das booten laenger?
Wird es in der Zukunft ein Image ohne IDE-Unterstuetzung und die ganzen Tools geben?
Verfasst: Di 10 Okt 2006, 7:49
von torre
Die Umstellung auf das neue xfs Dateisystem klappt bei mir nicht:
Code: Alles auswählen
/ > umount /hdd
/ > mkfs.xfs -l version=2 -f /dev/ide/host0/bus0/target0/lun0/part2
meta-data=/dev/ide/host0/bus0/target0/lun0/part2 isize=256 agcount=16, agsize
=1220097 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=19521552, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=9532, version=2
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
soweit scheinbar o.k., aber mounten klappt dann nicht
Code: Alles auswählen
/ > mount -t xfs /dev/ide/host0/bus0/target0/lun0/part2 /hdd
mount: Mounting /dev/ide/host0/bus0/target0/lun0/part2 on /hdd failed: No such d
evice
/ >
Verfasst: Di 10 Okt 2006, 7:59
von torre
der xfs-treiber sollte natürlich auch geladen werden ...
#!/bin/sh
# JTG-Team-Image [IDE] start_ide v1.07 # 08.10.2006
# IDE Treiber Laden
insmod jbd
insmod xfs
insmod ide-core
insmod dboxide
insmod ide-detect
insmod ide-disk
#SWAP mounten
if [ -e /var/etc/.swap ] ; then
/sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1
fi
#HDD mounten
#/bin/mount -t ext3 /dev/ide/host0/bus0/target0/lun0/part2 /hdd
/bin/mount -t xfs /dev/ide/host0/bus0/target0/lun0/part2 /hdd
/sbin/hdparm -S 60 -M 128 $(cat /var/etc/opt_hdparm 2>/dev/null) /dev/ide/host0/bus0/target0/lun0/disc
exit 0
dann kann auch gemountet werden.
Verfasst: Di 10 Okt 2006, 8:40
von hepp
petgun_download hat geschrieben:hi,
Riker hat geschrieben:Da die Tools einges an Platz brauchen ist der Snap viel grösser geworden
was bedeutet das konkret?
Dauert das booten laenger?
Wird es in der Zukunft ein Image ohne IDE-Unterstuetzung und die ganzen Tools geben?
Wüßte nicht, warum sich der Bootprozess verlängern sollte, sofern der ganze Treiber/Tools-Kram nicht geladen/gestartet wird. Und das kann man ja schön steuern.
Ich sehe kein Problem im "besser ausgefüllten" squashfs (schließlich liegt der ungenutzte Teil des _fixen_ squashfs-Bereich ja sonst im Prinzip brach).
Übrigens: die (cramfs)-images hatten vor der squashfs-Umstellung auch eine Größe von 5,7MB erreicht. Schon irre, was die neue Komprimierung gebracht hat.
Verfasst: Di 10 Okt 2006, 9:27
von petgun_download
..wird der ganze IDE-Kram (Treiber/tools/scripte) wirklich erst zur Laufzeit entpackt?
Verfasst: Di 10 Okt 2006, 9:48
von hepp
petgun_download hat geschrieben:..wird der ganze IDE-Kram (Treiber/tools/scripte) wirklich erst zur Laufzeit entpackt?
Ich nehme an Du spielst auf den Speicherverbrauch (RAM) an?
Also ohne dass ich meine Behauptung jetzt auf die schnelle belegen könnte, behaupte ich mal, dass das squashfs ein Realtime Komprimierungsfilesystem ist.
Verfasst: Di 10 Okt 2006, 9:54
von petgun_download
Ich nehme an Du spielst auf den Speicherverbrauch (RAM) an?
ja...mit geladener IDE-Interface Unterstuetzung wird der imo um einiges groesser sein (Buffer usw.). Ich will mich nur vergewissern dass es keinen erhoehten Ramverbrauch gibt wenn keine IDE-Interface Unterstuetzung gewaehlt wird.
Verfasst: Di 10 Okt 2006, 14:07
von ZERINA
Kann irgednwer über Erfahrungen mit xfs berichten, bzgl perfomance und CPU Belastung ?
Verfasst: Di 10 Okt 2006, 14:27
von Riker
petgun_download hat geschrieben:..wird der ganze IDE-Kram (Treiber/tools/scripte) wirklich erst zur Laufzeit entpackt?
Deswegen hab ich nun alles als module eingebaut, wenn kein IDE eingeschaltet wird davon auch nix geladen, auch kein filesystem mehr jetzt.
Gruß Riker
Verfasst: Di 10 Okt 2006, 14:42
von petgun_download
..wenn kein IDE eingeschaltet wird davon auch nix geladen, auch kein filesystem mehr jetzt
Danke fuer die Antwort und Deine Arbeit.
Verfasst: Di 10 Okt 2006, 14:58
von torre
ZERINA hat geschrieben:Kann irgednwer über Erfahrungen mit xfs berichten, bzgl perfomance und CPU Belastung ?
Macht einen sehr sehr guten Eindruck, teste gerade ARD mit 3 Tonspuren und es scheint in jedem Fall besser als ext3 zu laufen. Daher mein Tipp: unbedingt ausprobieren (sofern die HD gerade leer ist).
Verfasst: Di 10 Okt 2006, 15:10
von BigHardy
@Riker
Danke erstmal für den neuen Snap (Stein fall vom Herz)
Ich benutze im Moment ext2 (ich hoffe die ext2-User ziehen nicht wirklich deinen Zorn auf sich, wie in einigen Beiträgen gewarnt wird) und bis auf gelegentliche Overflows bei ARD inkl. aller Tonspuren bin ich auch zufrieden damit.
Würde sich ein Versuch mit xfs lohnen ?
Wie verhält sich xfs verglichen mit ext2 ?
Vorteile / Nachteile ?
Für einen Versuch müsste ich dann natürlich erstmal die Platte leeren.
Daher meine Frage ob es lohnt.
Gruss
Hardy
Verfasst: Di 10 Okt 2006, 15:17
von petgun_download
Würde sich ein Versuch mit xfs lohnen ?
Wie verhält sich xfs verglichen mit ext2 ?
Vorteile / Nachteile ?
hier ein Vergleich zwischen ext3, reiser, xfs, jfs
In der Zusammenfassung:
...XFS appears to be the most appropriate filesystem to install on a file server for home or small-business needs :
It uses the maximum capacity of your server hard disk(s)
It is the quickest FS to create, mount and unmount
It is the quickest FS for operations on large files (>500MB)
This FS gets a good second place for operations on a large number of small to moderate-size files and directories
It constitutes a good CPU vs time compromise for large directory listing or file search
It is not the least CPU demanding FS but its use of system ressources is quite acceptable for older generation hardware
Verfasst: Di 10 Okt 2006, 17:01
von ZERINA
Kann man schon etwas dazu
It is not the least CPU demanding FS but its use of system ressources is quite acceptable for older generation hardware
sagen ?