Den dauernden Zugriff auf die Platte ausstellen in YaVDR 0.4?

Also bei mir landen in den 2 genannten Verzeichnissen keine Logs und vtx-Dateien.
Für die Logs in eine Ramdisk gibt es zwar ein FeatureRequest, aber das muss eben noch ordentlich ausgearbeitet werden.
vtx-Daten landen normal in /var/cache/vdr/vtx wenn ich mich nicht täusche.

In der 0.3a habe ich folgendes in die fstab eingetragen

tmpfs	/var/cache/vdr/vtx	tmpfs	defaults,size=64m,uid=107,gid=107  	0   	0

Bei der 0.4 auf meinem TestVDR genauso, nur halt uid & gid =666

Mit:

echo 1 >/proc/sys/vm/block_dump

die Zugriffe loggen einschalten.
Damit findest du die Bösewichte. Ansonsten habe ich aufs verwendet siehe: Sandy Bridge VDR Energiespar Server
Wobei bei extfs du mit commit=xxx vielleicht um aufs herum kommst.

Johns

Genau so eine Diskussion hatten wir doch vor einem Jahr schonmal, und damals war es beim Theadstarter "ext4 Journaling", das dauernd auf der HDD rumwurschtelt. Aber ich erinnere mich nicht mehr genau, vielleicht findet Ihr den Thread.

EDIT: Hier: Den dauernden Zugriff auf die Platte ausstellen?

EDIT2: Ach so, der wird oben schon genannt.

EDIT3: Weiter unten hier kommen noch mehr Links auf ältere Threads.

Gruß
hepi

Zitat von Tournevis

Mittlerweile (YaVDR 0.4) ist zumindest für einen Teil der stetig anfallenden Daten (vtx, diverse logs) eine Ramdisk aktiv (/var/run, /var/lock).
Die Nutzung dieser hält sich aber in Grenzen.
Wo wird denn festgelegt, welche Daten dort abgelegt werden?
Werden die Daten dort auch persistiert oder beim Abschalten verworfen?
Wo ist dies festgelegt oder gesteuert?

yaVDR benutzt diese Verzeichnisse überhaupt nicht direkt, sondern höchstens über das darunterliegende Betriebssystem Ubuntu. Deshalb legt auch Ubuntu fest was dort hineinkommt. Die Filesysteme sind nicht persistent, weil das für die Daten die dort hineinkommen auch nicht sinnvoll wäre.

Zitat von Tournevis

(Bei LinVDR habe ich z.B. die Daten bei runvdr start in die Ramdisk kopiert und bei runvdr stop gesichert, dazwischen wurde mit der Ramdisk gearbeitet. Die betroffenen Dateien waren in runvdr explizit benannt.)

yaVDR macht das nicht so, weil wir dem Betriebsystem Ubuntu soviel wie nur irgend möglich überlassen. Das gibt uns mehr Zeit an Erweiterungen an der Oberfläche zu arbeiten. Außerdem sorgt es dafür, dass wir problemlos Updates von Ubuntu einspielen können ohne das Änderungen durch yaVDR jedesmal angepasst werden müssten.

Gerald

Hier, es gibt noch mehr Threads zu diesem Thema. Bitte mal einlesen:

Ständiger Festplattenzugriff seit 3 Tagen ?
[0.3] gelöst: ständiger Festplattenzugriff

Gruß
hepi

ofenheizer ?

tmpfs	/var/cache/vdr/vtx	tmpfs	defaults,size=64m,uid=107,gid=107  	0   	0

warum ?

apt-get install vdr-plugin-osdteletext

mount sagt:

tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)

ls -l /run/vdr/vtxls -l /run/vdr/vtx
insgesamt 0
drwxr-xr-x 2 vdr vdr 26620 2011-10-27 14:20 C-1-1079-28006

insgesamt 0
drwxr-xr-x 2 vdr vdr 26620 2011-10-27 14:20 C-1-1079-28006

(oneiric)

bei der 0.4 ist es glaube ich noch var/run
in oneiric ein link von da nach /run

also reicht es "nix" zu tun.

@hoplo

tja, warum. weil ich es von der 0.3 nicht anders kannte. also auch am testvdr so eingefügt.

eben in meiner VM mal nachgesehen.

apt-get install vdr-plugin-osdteletext

dann einen reboot und mount sagt bei mir

root@yavdr-vm:~# mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
/dev/sda3 on /srv type xfs (rw)
/srv/vdr/video.00 on /srv/share/vdr type none (rw,bind)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

es gibt auch kein Verzeichnis /run gibt es bei mir nicht (natty).

hast du meinen post gelesen ?

bei der 0.4 ist es glaube ich noch var/run
in oneiric ein link von da nach /run

var/run ist völlig ok

bei oneiric ändert sich das halt nach /run
aber man muss von uns aus (wegen osdteletext) nix ändern.

Zitat von hotzenplotz5

hast du meinen post gelesen ?

gelesen schon, aber die zeile dann wohl überlesen.

ok. guck mir das heute abend auf meinem testvdr mal an mit den vtx-dateien, aber in meiner VM existiert /var/run/vdr/vtx zumindest schonmal nicht. ob das erst beim videotextaufruf angelegt wird, kann ich jez nicht sagen.

hotzenplotz5

Passt schon, "/var/run" ist per default eine "ramdisk" bei Ubuntu, ab Oneiric eben "/run". Das Paket "vdr-plugin-osdteletext" wurde schon vor einer Weile entsprechend angepasst, damit es die Daten unter "/var/run/vdr/vtx" ablegt. Für 0.4 habe ich das eben nochmals verifiziert.

Alle Interessierten könnten "/tmp" auch in eine "ramdisk" verpacken, Speicher haben die Maschinen ja meist genug, dort liegen die fifo von xine respektive xineliboutput. Ein Zeile dieser Art in die "/etc/fstab" und ein anschließender reboot machts möglich:

none /tmp tmpfs size=128m 0 0

128MB, damit auch mal was abgelegt werden kann.

Regards
fnu

Zitat von Tournevis

Speziell für SSDs scheint es ratsam zu sein (findet Goggle), in fstab die Optionen "discard" und "noatime" zu verwenden.

Wenn dann aber bitte komplett hier beschreiben und nicht Häppchenweise ...

UUID=01234567-9876-1234-3456-654321123456 /     ext4     noatime,discard,data=ordered,errors=remount-ro 0 1

Ach ja, es wird allenthalben vom Anlegen eines Swaps auf SSD Platten gewarnt, was m.E. ein zweischneidiges Schwert ist. Wenn eine Maschine dauerhaft Speicher auslagern muß, stimmt schonmal etwas prinzipielles nicht, was erstmal gelöst werden sollte. Von daher lege ich auch bei SSDs einen Swap an, die Maschine sollte genug Speicher haben um diesen nicht dauerhaft nutzen zu müssen, aber für den Fall der Fälle lieber einen einmaligen nicht ganz so optimalen Zugriff auf den Swap@SSD, als ein Out-of-Memory. Aber von der dauerhaften Nutzung von SuspendToDisk würde ich denoch absehen ...

Regards
fnu

Zitat von Tournevis

Speziell für SSDs scheint es ratsam zu sein (findet Goggle), in fstab die Optionen "discard" und "noatime" zu verwenden.

"discard" sollte auf keinen Fall mehr verwendet werden. Seit Kernel 2.4.37 gibt es den Befehl fstrim der täglich oder wöchentlich verwendet werden sollte (cron),

http://de.gentoo-wiki.com/wiki/Solid_State_Drive

Eine weitere Möglichkeit wäre es das direkte Schreiben innerhalb von 5 Sekunden der Journaldaten mit dem entsprechenden Parameter commit hochzusetzen:

UUID=fdee250b-8929-49dc-81ae-aa53a105c8b2 /srv/vdr/video.00 ext4    defaults,commit=30        0       2

Ob das sinnvoll ist muss jeder für sich entscheiden, Sicherheit vor Datenausfall gegen Verringerung der Schreibzugriffe.

LG Urknall

Zitat von Murry

"discard" sollte auf keinen Fall mehr verwendet werden. Seit Kernel 2.4.37 gibt es den Befehl fstrim der täglich oder wöchentlich verwendet werden sollte (cron),

Der Punkt ist, das "discard" erst mit den Kernels ab 2.6.x für ext4 eingeführt wurde und für xfs, erst vor kurzen fehlerfrei mit 3.x.y ... "fstrim" ist die althergebrachte Methode und ich wünsche ja keinem, das er noch Kernel 2.4.37 nutzt ...

Regards
fnu

Zitat von fnu

Der Punkt ist, das "discard" erst mit den Kernels ab 2.6.x für ext4 eingeführt wurde und für xfs, erst vor kurzen fehlerfrei mit 3.x.y ... "fstrim" ist die althergebrachte Methode und ich wünsche ja keinem, das er noch Kernel 2.4.37 nutzt ...

Sorry, ich meinte 2.6.37 --> batched discard für ext4

http://www.thomas-krenn.com/de…inux_Kernel#Kernel_2.6.37

Gruß

Murry

Tournevis

Ok, nun hast Du halt das Problem, das die EPG Daten nach einem Neustart des Client komplett weg sind und dann wieder komplett neu aufgebaut werden müssen ... ?

Regards
fnu