[xmltv2vdr] Kann nun mit "tmpfs" arbeiten ...

fnu · 22. April 2013

Hi,

Joe_D hat eine wunderbare Änderung an "vdr-plugin-xmltv2vdr" vorgenommen, es kann jetzt wenn vorhanden ein "tmpfs" zur Laufzeit nutzen.

Die Idee dazu ist eher aus der Not geboren, eine Script-basierte Steuerung ist für Debian konforme Paketbauer wohl undenkbar ...

Daher kam der Gedanke auf, das Plugin prüfen zu lassen ob beim Start im FHS konformen "/var/run" ein Unterverzeichnis "/var/run/vdr" existiert, was dann genutzt wird, wenn nicht wie gehabt SSD/HDD. Die DB wird weiterhin im definierten Massenspeicher-Pfad gesichert, Default "VIDEO_DIR".

[EDIT] Weiter unten führt Joe_D aus, das Plugin prüft auf "/var/run/vdr"=tmpfs oder "/tmp"=tmpfs und nutzt dies nur dann! [/EDIT]

Das sollte somit für alle Linux-Derivate lösbar sein, bei yaVDR wird "/var/run/vdr" schon längere Zeit beim VDR Start (plugin-loader[.sh]) für z.B. "osdteletext" angelegt evtl. inzwischen auch bei den eTobi/SOliver Paketen. Der Start sieht dann so aus:

Code

Apr 22 20:56:09 vdr2 vdr: [1569] initializing plugin: xmltv2vdr (0.2.0pre): Importiert xmltv epg in den VDRApr 22 20:56:09 vdr2 vdr: [1569] starting plugin: xmltv2vdrApr 22 20:56:09 vdr2 vdr: [1569] xmltv2vdr: using codeset 'UTF-8'Apr 22 20:56:09 vdr2 vdr: [1569] xmltv2vdr: using file '/srv/vdr/video.00/epg.db' for epg database (storage)Apr 22 20:56:09 vdr2 vdr: [1569] xmltv2vdr: using file '/var/run/vdr/epg.db' for epg database (runtime)Apr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' added epgsourceApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' reading source configApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' is providing data through a pipeApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' updates data @00:00Apr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' is providing picsApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' daysmax=15Apr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' reading plugin configApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' daysinadvance=15Apr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' using pics=0Apr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' weekdays=MTWTFSSApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' nextrun on Tue Apr 23 20:08:00 2013Apr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: 'tvm2xmltv' is ready2parseApr 22 20:56:14 vdr2 vdr: [1569] xmltv2vdr: using sqlite v3.7.9

Bitte mal testen, ich sag nur geil

Regards
fnu

Keine_Ahnung · 22. April 2013

Klasse, läuft bei mir vermutlich voll gegen die Wand (Es sei denn es wird geprüft obs wirklich tmpfs ist)

Zitat von fnu

Die Idee dazu ist eher aus der Not geboren, eine Script-basierte Steuerung ist für Debian konforme Paketbauer wohl undenkbar ...

Eine pluginübergreifende Umgebunsvariable wie z.B. VDR_TMP ist ja wohl auch undenkbar

BTW: Meine "plugin.xmltv2vdr.conf" sieht so aus

Code

--epgfile=%VDR_CONFIG_BASE_DIR%/epg/epg.db
--episodes=%VDR_CONFIG_BASE_DIR%/config/vdrseriestimer

Geht also schon (auch bei debian konformen Paketen ) wenn man will.

cu

fnu · 22. April 2013

Zitat von Keine_Ahnung

Klasse, läuft bei mir vermutlich voll gegen die Wand

Mußte auch meine ganzen Scripte wegwerfen ...

Copperhead · 22. April 2013

Super Sache. Aber warum /var/run?

Klar das ist tmpfs, aber /tmp doch auch, oder hat sich das noch nicht in allen Distris durchgesetzt?

Keine_Ahnung · 22. April 2013

Zitat von Copperhead

Super Sache. Aber warum /var/run?

Klar das ist tmpfs, aber /tmp doch auch, oder hat sich das noch nicht in allen Distris durchgesetzt?

Bei Debian stable ist /var/run UND /tmp das normale root Filesystem, nix tmpfs. Ich denke da gibts nix verlässliches was für alle passt

Wobei /tmp als tmpfs nun auch sehr ungünstig ist wenn da Software (z.B. das Burn Plugin) mal schnell 5 GB zwischenlagern will.

Ich habe für meinen VDR /dev/shm/.vdr/vdr/tmp (tmpfs) für den Kleinkram und /srv/BIGTMP (Liegt auf der Datenpartition mit viel Platz) wenns mal Platz braucht.

cu

fnu · 22. April 2013

Zitat von Copperhead

Aber warum /var/run?

Für "/tmp" ist nach FHS "tmpfs" kein Zwang, "/var/run" wohl dagegen schon.

Bei squeeze ist das kein "tmpfs"? Hab nur Wheezy gecheckt ...

Keine_Ahnung · 22. April 2013

Zitat von fnu

Bei squeeze ist das kein "tmpfs"?

Jup. Ich erinnere mich jetzt auch nicht da was umgebastelt zu haben.

Code

/dev/sda2 on / type ext4 (rw,nodiratime,relatime,user_xattr,errors=remount-ro,commit=60)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/sda3 on /srv type ext4 (rw,noatime,user_xattr)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
encfs on /pub/Dropbox/111 type fuse.encfs (ro,nosuid,nodev,allow_other)
none on /dev/shm/.vdr/vdr/config type aufs (rw,relatime,si=5ced2bb9,udba=notify)
vdrnfofs on /srv/VIDEO/VDR_VIDEO type fuse.vdrnfofs (rw,nosuid,nodev,allow_other)

Alles anzeigen

cu

fnu · 22. April 2013

Nachtrag, bei Wheezy & Precise ist der Mountpunkt "/run" mit einem symbolischen Link nach "/var/run" um eben FHS zu entsprechen ...

Wie auch bei ArchLinux ... eben kurz geguckt ...

Copperhead · 22. April 2013

Also Archlinux folgt dem, was Fedora macht und dort ist "/tmp" tmpfs und "/var/tmp" normales Filesystem. Ist ja letztlich auch egal.

fnu · 22. April 2013

Zitat von Copperhead

Also Archlinux folgt dem, was Fedora macht und dort ist "/tmp" tmpfs und "/var/tmp" normales Filesystem. Ist ja letztlich auch egal.

Ja, aber Du fragst doch warum nicht "/tmp"? Eben weil das oft kein "tmpfs" ist, aber "/run" bzw. "/var/run" auch bei ArchLinux ... ?

fnu · 22. April 2013

Zitat von Keine_Ahnung

(Es sei denn es wird geprüft obs wirklich tmpfs ist)

Er schreibt nicht nach "/var/run"! Er prüft ob "/var/run/vdr" existiert und nutzt das, ~~wenn das nicht da ist passiert nix ...~~

Zitat von Keine_Ahnung

Eine pluginübergreifende Umgebunsvariable wie z.B. VDR_TMP ist ja wohl auch undenkbar

Nun, frag nicht mich ...

Zitat von Keine_Ahnung

Geht also schon (auch bei debian konformen Paketen ) wenn man will.

Nein, da gab es vom Meister höchstpersönlich eine Absage für ...

Joe_D · 22. April 2013

Zitat von Keine_Ahnung

Klasse, läuft bei mir vermutlich voll gegen die Wand (Es sei denn es wird geprüft obs wirklich tmpfs ist)

Bei mir wird (fast) nichts 0815 gemacht. Zuerst wird geprüft ob es /var/run/vdr gibt und ob dies als tmpfs läuft, dann wird geprüft ob es /tmp gibt und als tmpfs läuft. Ist beides nicht der Fall entspricht das runtime-Verzeichnis dem storage-Verzeichnis. Das funktioniert auch wenn man eine komplett andere Datei und Lagerort für das "storage" angegeben wird. Eigentlich ziemlich easy

Gruß

Joe_D

Keine_Ahnung · 22. April 2013

Na denn ist ja super

War auch nicht so ernst gemeint, ich bin nur kein Fan von diesen "nehmen wir den User mal an die Hand und machen das für ihn" Lösungen, deswegen konnte ich mir nen Spruch nicht verkneifen.

Wobei, für Debian schient es dann wohl doch sinnig zu sein. Denn dort fehlen eindeutig Mechnismen (z.B. die Möglichkeit kurze Shell Snippets in die plugin.<pluginname>.conf zu packen) für solche Fälle.

Zitat von fnu

Nein, da gab es vom Meister höchstpersönlich eine Absage für ...

Den VDR ins Debian-System zu quetschen ist aber auch nen Krampf. Schon alleine die Tatsache das die Pluginconfigverzeichnisse nicht in /etc liegen sorgt dafür das man das eh alles nicht mehr so wirklich Debiankonform handeln kann.

cu

MegaV0lt · 23. April 2013

Unter Gentoo/Gen2VDR sieht es schlecht mit tmpfs aus.

Code

hdvdr01 xmltv2vdr # mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw,noatime,errors=continue,user_xattr,barrier=0,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=385180k,nr_inodes=96295,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
rc-svcdir on /lib/rc/init.d type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda5 on /mnt/data type xfs (rw,noatime)
/dev/sda1 on /boot type ext2 (rw,noatime)
/dev/ram0 on /tmp/osdteletext type ext2 (rw)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)
nfsd on /proc/fs/nfsd type nfsd (rw,noexec,nosuid,nodev)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
//SheevaPlug/root on /mnt/sheeva_root type cifs (rw,mand,noexec,nosuid,nodev)
hdvdr01 xmltv2vdr # df -h
Dateisystem       	Size  Used Avail Use% Eingehängt auf
rootfs             	20G   11G  7.9G  58% /
/dev/root          	20G   11G  7.9G  58% /
devtmpfs          	377M  328K  376M   1% /dev
rc-svcdir         	1.0M  140K  884K  14% /lib/rc/init.d
shm               	377M 	0  377M   0% /dev/shm
/dev/sda5         	1.8T  610G  1.3T  34% /mnt/data
/dev/sda1          	50M   39M  8.4M  83% /boot
/dev/ram0          	59M  1.8M   57M   4% /tmp/osdteletext
//SheevaPlug/root 	3.7G  1.5G  2.0G  43% /mnt/sheeva_root

Alles anzeigen

Wäre schön, wenn das Plugin einen Parameter (z.B. --tmpfsdir=) für das tmpfs-Verzeichniss bekommen könnte. Dann könnte man das selber definieren

fnu · 23. April 2013

Zitat von MegaV0lt

Wäre schön, wenn das Plugin einen Parameter (z.B. --tmpfsdir=) für das tmpfs-Verzeichniss bekommen könnte. Dann könnte man das selber definieren

Joe_D wollte keinen weiteren Parameter und ich finde er hat das sehr gut gelöst, es stellt selbst gen2vdr Nutzer vor keine unmögliche Aufgabe ...

Du hast doch auch kein Problem eine RAM-Disk für "osdteletext" anzulegen ... ? Leg doch einfach "/tmp" als tmpfs an, so wie es vmtl. die meisten VDR Nutzer eh tun:

Code

#/> vi /etc/fstab
...
tmpfs	/tmp	tmpfs	nosuid,size=256M	0	0
...

Damit fackelst Du nebenbei auch noch Dein "/tmp/osdteletext" ab. Wenn nix da ist, arbeitet das Plugin wie seither auch, auf Disk/FS Ebene ...

Regards
fnu

Copperhead · 23. April 2013

Zitat von fnu

Eben weil das oft kein "tmpfs" ist, aber "/run" bzw. "/var/run" auch bei ArchLinux ... ?

Der Vollständigkeit halber:

Code

[root@christopher-pc christopher]# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=1989196k,nr_inodes=497299,mode=755)                              
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)                                                          
/dev/sda4 on / type ext4 (rw,relatime,data=ordered)                                                                 
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)                                
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)                                                                      
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)                              
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)                                                
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)                                                                                        
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)                                
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)                      
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)                                
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)                              
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)                              
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)                              
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)                                  
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)                                                                                                                   
debugfs on /sys/kernel/debug type debugfs (rw,relatime)                                                             
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)                                                            
mqueue on /dev/mqueue type mqueue (rw,relatime)                                                                     
tmpfs on /tmp type tmpfs (rw)                                                                                       
configfs on /sys/kernel/config type configfs (rw,relatime)

Alles anzeigen

Hast also Recht. /var/run ist nach /run gesymlinkt und /run ist tmpfs.

steffen_b · 23. April 2013

Wenn es "nur" um Performance geht - hat schonmal jemand sowas probiert ??
http://qt-project.org/forums/viewthread/9090

Mit entsprechend großer Cache Size sollte es doch ähnlich performant sein oder ?

Wenn es natürlich darum geht nur beim Shutdown einen konsisten Stand wegzusichern und ansonsten nie zu schreiben ist es so natürlich top

fnu · 23. April 2013

Zitat von steffen_b

Wenn es natürlich darum geht nur beim Shutdown einen konsisten Stand wegzusichern und ansonsten nie zu schreiben ist es so natürlich top

Ja, genau das war der Plan, die HDD Aktivität wie z.B. auch bei "osdteletext" einzuschränken.

Nebenbei ist es natürlich auch schneller, aber man hat kein Problem damit wenn die DB auf einer HDD liegt ...

Regards
fnu

Copperhead · 23. April 2013

Nur mal ein Gedanke:

Wie wäre ein weiteres Standard Verzeichnis

Neben:

ConfigDirectory
ResourceDirectory
CacheDirectory
VideoDirectory

auch noch
TempDirectory

das zeigt dann standardmäßig nach /tmp/vdr
Debian und Co können dann /tmp/vdr als tmpfs mounten und bei den anderen passt es von vornherein.

Alternative 1: CacheDirectory umdefinieren. Das kollidiert dann aber mit der epg.data, weil die ja liegen bleiben soll.

Alternative 2: xmltv2vdr und osdteletext schreiben nach /dev/shm/vdr. Ich habe das zwar noch nicht versucht, aber im Archlinux Wiki wird soetwas im Zusammenhang mit Firefox beschrieben.
Edit: Ich habe es versucht und man darf da als User tatsächlich Daten ablegen.

utiltiy · 23. April 2013

Danke für die Anpassung, spart mir einen Upstart-Job

[xmltv2vdr] Kann nun mit "tmpfs" arbeiten ...

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema