Jemand Ubuntu 10.04 im Einsatz?

Hat das jemand im Einsatz? Ich wüßte gerne ob es Probleme mit ext4 gibt.

Ich schätz mal, dass das weltweit mittlerweile ein paar Millionen Menschen im Einsatz haben

Also frag doch Tante Google - auch wenn ich nicht wüsste, warum gerade ext4 da Probleme machen sollte

Markus Everson schrieb:

Hat das jemand im Einsatz? Ich wüßte gerne ob es Probleme mit ext4 gibt.

Zum Vergrößern anklicken....

Ich glaub auf dem netbook von meiner freundin hab ichs ... und da macht das eigentlich keine probleme. da es standard bei ubuntu ist sollte es sowieso keine probleme machen.

Bei mir macht's auf nem Laptop, nem Nettop, nem Desktop, nem Server (Gentoo) und kvm Virtualserver keinerlei Probleme.
Die maximal eingesetzte Filesystemgröße ist dabei 6,8TB, am Server.

lg
__tom

ubuntu ist die hierzulande wohl meistgenutzte distri im privatbereich
das dürften so einige hier benutzen. habs auf 2 systemen drauf und im täglichen einsatz. hatte noch nie probleme mit ext4 und ich benutze es seit es im kernel nicht mehr den status "experimental" hat. also schon seit ner weile im täglichen einsatz auf /, /home und ner großen lvm2-volume von über 2 tb.

Ist mir schon klar das ext4 nicht mehr experimentell und Ubuntu millionenfach im Einsatz ist.

Aber fakt ist das ich mit vier verschiedenen virtuellen HD von Virtualbox Probleme habe und fakt ist und Fehler in Virtualbox nicht so viel wahrscheinlicher sind. Win7 läuft unverändert stabil und hat im NTFS auch keine Fehler, also sehe ich das Wirtssystem nicht unter den ersten Verdächtigen.

Ich werd mal in der Richtung VB schauen.

Hihi, bist auf das selbe Problem hereingefallen wie ich...
Hättest du VB im eingangspost erwähnt, hätte ich dir gestern schon die Antwort gegeben.

Das selbe Problem hatten wir hier in der Firma mit der Lucid-Testinstallation die den Host für eineige VBox-Systeme spielen sollte.
Es gibt einen Bug, der Virtualbox AsyncIO - Zugriffe auf Ext4-Partitionen betrifft und da wohl für Fehler sorgt.
Und zwar auf eine merkwürdige Art, die Daten kommen vollständig an, jedoch schlägt das erneute einlesen dieser Daten fehl (Irgend eine Buffer Corruption nehme ich an) und das verwirrt VBox natürlich.
Die neueste VBox-Version sollte einen Workaround enthalten. Hab ich zumindest in VBox Release-Notes gelesen. Bin mir aber nicht sicher ob die Version schon released ist oder noch eine Beta.
Jedenfalls hat Ext4 selbst kein Problem in Lucid, aber Ext4 im Zusammenspiel mit VBox macht probleme.
Scheint aber auch nur Lucid Lynx zu betreffen, also ist wohl abhängig von der Kernel-Version (Ext4-Treiber)
Jedenfalls solltest du auf eine neue VBox Versio nausweichen (notfalls die neueste Beta) dann sollten die Probs gelöst sein.

Wird sofort getestet!

Falls das nicht geht, kannst Du ja auch die Partition mit ext3 anstelle ext4 formatieren lassen, oder willst Du ausdrücklich ext4 testen?

Das ist nat. auch eine mögliche Lösung.
In Sachen Filesysteme gibts ja eine ziemlich breite Auswahl...

Rones schrieb:

Falls das nicht geht, kannst Du ja auch die Partition mit ext3 anstelle ext4 formatieren lassen, oder willst Du ausdrücklich ext4 testen?

Zum Vergrößern anklicken....

Nein, ich bin eher konservativ und sehe für mich nichtmal einen grund über ext2 hinaus zu gehen.
(ok, werde ich nicht weil das ganz sicher nichts bringen wird).

Intressant aber schon das ein Problem nur mit ext4 auftreten soll. Weiß man denn seit wann das auftritt? Ich steh nicht so auf Beta-Bananen und würde lieber down- als updaten. (sorry für Sprachpanscherei)

Soweit ich weiß ist das Problem nichtmal direkt auf ext4 zurückzuführen sondern auf DIESE KONKRETE Version von Ext4.
Also mit Lucid-Kernel und Userland.
An der Diskussion die ich da verfolgte beteiligten sich auch Fedora Nutzer und die konnten keine Probleme feststellen, wenn ich mich recht erinnere.
Ext2 wäre mir schon etwas zu altbacken, das journalling von ext3 das einem die fscks erspart ist schon praktisch. Ob man nun ext4 braucht liegt im Ermessen des Anwenders...
Soweit ich weiß hat dieser AsyncIO-Fehler direkt damit zu tun, dass Daten die auf dem System über asyncIO geschrieben, und sofort erneut eingelesen werden, korrupt zurückkommen (irgend ein Puffer spinnt wohl, wie oben schon geschrieben) die daten liegen allerdings im Filesystem korrekt vor und wenn ein anderer Prozess diese liest stimmen sie auch.
Ist also ein sehr spezifisches Problem, das dummerweise genau in dieser Kombination VBox und ext4 auf Lucid Lynx zu Tage tritt.
Also sogesehen, in dem Augenblick wo du ais dem ext4 ein ext3 machst, sollte das Problem behoben sein. Evtl. verlierst du etwas performance aber der Fehler sollte dann definitiv weg sein.
Google spuckt nach kurzer Suche das hier aus:
http://forums.virtualbox.org/viewtopic.php?f=7&t=31255
Das ist nicht direkt der thread wo sie über den workaround beschreiben, aber er zeigt das Problem auf.

ok, hier weitere Infos:
Der Bug exisitert Seit VirtualBox 3.2, da hier die Benutzung des AsyncIO-API zur performancesteigerung implmentiert wurde.
Eigentlich ist der Fehler aber in ext4 zu finden https://bugzilla.kernel.org/show_bug.cgi?id=16165
Anscheinend fehlen einige Ext4-betreffende Patches im Lucid standardkernel.

nochn edit:
Wie hier
http://forums.virtualbox.org/viewtopic.php?f=7&t=31255&sid=4ae2965fc1f78f15a7936d2601deafbb&start=15#p142282
angemerkt, scheint sich das Problem umgehen zu lassen indem man in den Settings der Virtuallen maschine das Häkchen für "Host cache" bei den betreffenden festplattencontrollern setzt.
Virtualbox 3.2.6 sollte das schon selbst richtig machen.

Wobei mir die Verwendung von EXT4 im privaten Bereich nicht ganz erschließt. Nen wirklichen Vorteil sehe ich da nicht.

Solange keine EXT4 spezifischen Einträge gemacht wurden, kann man auch jederzeit diese Partition als EXT3 mounten oder anderes herum. EXT3 als EXT4. Mann muss also nicht zwingend neu formatieren. (so ist mein letzter Stand)

Es hat sich aber gezeigt, das EXT4 einiges langsamer ist bei sequenziellen Löschen vieler kleinen Dateien (Backups), als EXT3. Zumindest sind, das meine Erfahrungen.

Ich fahre aktuell EXT3 als 6.4TB Raid 5 "Datenschleuder" und konnte bis auf das Löschen , aber auch nicht wirklich Vorteile für mich als Homeuser feststellen.

tspoon schrieb:

Wobei mir die Verwendung von EXT4 im privaten Bereich nicht ganz erschließt. Nen wirklichen Vorteil sehe ich da nicht.

Zum Vergrößern anklicken....

Wie gesagt, für mich galt das im reinen Privatbetrieb auch schon und noch für ext2. Email Appliance mit 1 GB Datenpartition und 4 GB für Ubuntu..

Solange keine EXT4 spezifischen Einträge gemacht wurden, kann man auch jederzeit diese Partition als EXT3 mounten oder anderes herum. EXT3 als EXT4. Mann muss also nicht zwingend neu formatieren. (so ist mein letzter Stand)

Zum Vergrößern anklicken....

Das wäre der Königsweg! Wird ab heute abend bei mir getestet, ich halte euch auf dem laufenden.
.
EDIT :
.
Nachtrag: So, hab nun in fstab umgestellt. Aber ich habe noch fs-fehler die ich im Singleuser beheben will.

Ist mir ja ziemlich peinlich, aber das kriege ich nicht hin. Mit PM als ISO findet er keine Fehler, danach in Ubuntu wieder verlorene Inodes. Grub habe ich sichtbar gemacht, im Runlevel S bin ich - aber / ist eingehängt und es zu reparieren wäre keine gute Idee. Sagt mir fsck /dev/sda1

Wo liegt denn mein Denkfehler?

Mach ein:
und danach neu booten.
Das Laufwerk sollte dann geprüft werden.

Danke Dir!

Scheint aber ohnehin als ob ich um neu formatieren nicht herum komme. Das FS wird weiterhin als ext4 gemounted, vermutlich weil die erweiterten Features aktiviert sind.

root@Email-Appliance:~# mount | grep sd
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
/dev/sdb1 on /mnt/sdb1 type ext3 (rw,errors=remount-ro)

root@Email-Appliance:~# cat /etc/fstab
[...]
/dev/sda1 / ext3 errors=remount-ro 0 1
/dev/sdb1 /mnt/sdb1 ext3 errors=remount-ro 0 1

root@Email-Appliance:~# tune2fs -l /dev/sda1 | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

root@Email-Appliance:~# tune2fs -l /dev/sdb1 | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file


Ich geh jetzt erst mal an den Strand, heute abend gehts weiter.

Diese art der Konvertierung erfordert wohl etwas Arbeit:

http://ubuntuforums.org/showthread.php?t=1147968

ggf. wäre es einfacher in der VM-Config den host-cache einzuschalten als temp. Workaround bis Ubuntu einen Kernel mit den erforderlichen ext4-Patches liefert.

in einem anderne forum hab ich für die migration von ext4 zu ext3 einen hinweis auf fsarchiver gefunden http://www.fsarchiver.org/QuickStart
Könnte hilfreich sein

tspoon schrieb:

Solange keine EXT4 spezifischen Einträge gemacht wurden, kann man auch jederzeit diese Partition als EXT3 mounten oder anderes herum. EXT3 als EXT4. Mann muss also nicht zwingend neu formatieren. (so ist mein letzter Stand)

Zum Vergrößern anklicken....

ext4 nutzt standardmäßig extents, und mit denen kann ext3/2 nicht umgehen. Der Weg zurück ist dort versperrt.