24 replies to this topic

[anudanan]

Wurde bei den aktuellen Builds die Unterstützung von ext2 und ext3 entfernt?

Ich habe im et-view-support Forum gelesen, daß dort nach einem Update heute die ext3 Platte nicht mehr erkannt wurde. Warum wurde das gemacht? Dort gibt es noch viele Benutzer, die ext3 und ext2 mit dem neuen Image verwenden.

[MiLo]

Die Unterstutzung ist immer noch da. Ext2 und ext3 kann mann genau wie immer lesen und schreiben.

[familievierfuss]

Tja, nur einige und auch ich haben Probleme mit Aussetztern, haben die Platten auf ext2 umformatiert und auch so in der fstab eingebunden.

Ein weiterer User hat in der fstab seine Platte explizit mit dem ext3 Modul mounten lassen und siehe da, er hatte keine Aussetzer mehr. Vorher war dies auf Auto.

Wie muss ich dies nun in der fstab eintragen? ext2 durch auto ersetzen?

Ich bete darum, dass die Aussetzproblematik nicht mit dem ext4 Modul zusammenhängt.

Edited by familievierfuss, 25 January 2012 - 12:16.

[anudanan]

Ich meine schon, daß durch Tests im et-view-support Forum erkennbar ist, daß eine ext2 Platte besser tut, wenn auch das ext2 Module diese bedient und sie nicht durch das ext4 Modul bedient wird. Oder man muß jetzt noch Dinge in der fstab bei auto einstellen, die bestimmte neue Methoden bei dem ext4 Modul abschalten. Was genau, ist mir aber nicht klar.

[anudanan]

Wäre es ein Problem, ext2/3 wieder einzubauen User im et-Bereich wünschen sich das, da damit ext2/ext3 Platten besser laufen als mit dem ext4 Module, was diese dann bedient. Das ist zumindets die Erfahrung vieler Tage langer Test wegen der Aussetzerthematik

Edited by anudanan, 25 January 2012 - 13:27.

[MiLo]

Do you have a link to those tests and results?

The ext2/ext3 kernel modules can still be loaded, if you really want them, "opkg install kernel-module-ext2" should do the trick.

Tried yesterday, the 9x00 had no problem whatsoever recording 5 HD channels to disk (an old 160GB laptop disk) while playing back another HD recording, all on the same ext4 disk.

[familievierfuss]

Do you have a link to those tests and results?

http://www.et-view-s...-...hier-lesen.

The ext2/ext3 kernel modules can still be loaded, if you really want them, "opkg install kernel-module-ext2" should do the trick.

THX

Tried yesterday, the 9x00 had no problem whatsoever recording 5 HD channels to disk (an old 160GB laptop disk) while playing back another HD recording, all on the same ext4 disk.

Yes, but we have problems with >500GB Hdd's.

[MiLo]

http://www.et-view-s...-...hier-lesen.

Only leads to a login page.

[Rob van der Does]

http://www.et-view-s...-...hier-lesen.

Only leads to a login page.

And after logging in you will continua to the linked page.

[MiLo]

Do i have to create an account just to read it?

[familievierfuss]

Yes, I see it. You must have an account to read the board. :-(

So, here a little summary.

hdd>500Gb, ext4. Kernel 3.1 OpenPLI
It startet with video freezers only at the beginning of a film.
If the hdd fulled up >20% you have some freezers somewhere over the whole length of a film.
Same on ext3 formatted hdd's if you mounted it with the ext4 Modul.
One user reported no freezers if you mounted it in fstab with "ext3"
Also no freezers on an ext2 formatted hdd which was mounted with "ext2" into the fstab.
Another test was with ext3 formatted hdd, which have freezers on an 3.1 Kernel. There no Frezzers if you flash an old PLI Image with an 2.6.18 Kernel.

So, the best results was, to format the drive with ext2 and use a fstab like this:

rootfs			   /					auto	   defaults			  1  1
proc				 /proc				proc	   defaults			  0  0
devpts			   /dev/pts			 devpts	 mode=0620,gid=5	   0  0
usbfs				/proc/bus/usb		usbfs	  defaults			  0  0
tmpfs				/var/volatile		tmpfs	  defaults			  0  0
UUID=38dcece1-aa50-4a85-b47c-9c34f4967f15  /media/hdd	   ext2   rw,data=ordered   0  0
UUID=9f4c8363-3e1e-4488-bccb-45ace31773d9  /media/hdd_usb   ext2   rw,data=ordered   0  0

Edited by familievierfuss, 25 January 2012 - 15:16.

[MiLo]

I'm filling my ext4 formatted harddisk with zeroes now with
dd if=/dev/zero of=big_blank_file bs=1024k count=40M
Just for the fun I'm actually recording and playing back while the disk is filled, and that runs without a hitch...

[MiLo]

For optimal performance, you should format the disk in FAT, nothing beats that in raw speed. But you'll be limited to 4G recordings. NTFS with large clusters (256k or so) will also outperform all the ext filesystems in write speed. You'd have to format it in a Windows PC though.

On the other hand, the ET9x00 writes at a steady 50MB/s to my disk, and is still able to timeshift while doing that, so if there are problems with the disk throughput, it must be caused by software and/or settings, you can't blame ext4 solely for that.

Are you (or anyone else) willing to spend some serious time on this (you'll be mostly asked to run tests and probably some 'debug' enhanced enigma versions)?

[MiLo]

Did a timing test, which goes like this:

enigma outputs the time it spends in each "write" call. This is typically 2..3 ms to write a 188k data block.

While doing so, i delete a 2G file from the disk, and rewrite it with DD. This causes some delays in the write() call as it has to compete with the other process for harddisk attention.

When the filesystem is mounted as ext4 with "data=ordered", the longest delays I've seen were 2 seconds. That is enough to cause a buffer overrun (the situation is rather extreme, you wouldn't be deleting and writing huge files while recording).

When mounting with "data=writeback", I did not get such extreme delays any more. The longest I got was about 200ms, which can easily be compensated for and doesn't cause an overrun. This option may result in "random" data occurring in files after power loss, but not much else.

Just for the heck of it, I deleted the journal and tried again. This basically turns the disk into sort of ext2. With the journaling disables, I couldn't get it to stall longer than just over 15ms. So that's something to try if you're using ext2 mount now. Note that this also means that you should run a fsck after any unexpected power failure or kernel panic, or you may suffer severe system corruption...

The commands you'll find useful (unmount the disk before using any of these commands, you can re-mount it after that without rebooting):

Install tune2fs:
opkg install e2fsprogs-tune2fs

Disable journal:
tune2fs -O ^has_journal /dev/sda1

Set writeback mode:
tune2fs -o journal_data_writeback /dev/sda1

Set ordered mode:
tune2fs -o journal_data_ordered /dev/sda1

[anudanan]

Thank you MiLo for those tests. I seems so that the ordered write may cause the problem we see at some users. I think we will make some more tests with writeback option for the disk.
I hope in future kernel version 3.2x and newer we can use ext4 with up to 1 MByte Cluster to speed up the overhead of managing blocks especially for large hdds. That will earn many memory and cpu time I think.

[MiLo]

You'd have to reformat the disk to make use of clusters. It would bring the performance back in line with FAT, but won't do much for CPU usage. Recording just doesn't use much CPU at all, it's very low bandwidth. A HD recording typically writes about 1MB/s, while the disk easily moves 50 times that much around.

[familievierfuss]

Thank you Milo for your tests. I can only test at the weekend, but I think we have other Users like anudanan which can make earlier tests.

[MiLo]

Do some test, and please let me know your results. I'm particularly interested in the jounaling settings, if they appear to solve the problem for those folks who are now using ext2 drivers, I'll add a plugin that allows you to change these settings from the GUI (probably something like "performance" vs "reliability").

[anudanan]

Makes it now sense to set in your image the defauilt value for the variable
data
now to the value
writeback
instead of
ordered
because there is a lower delay?

[MiLo]

I'm awaiting your results in order to be able to answer that question.