nfs cachen mit cachefilesd

Ein kleiner Test zum NFS cachen. Genutzt habe ich cachefilesd dafür.

apt-get install cachefilesd

Konfigurationsdateien sind

/etc/default/cachefilesd

dort

RUN=yes

auskommentieren

und /etc/cachefilesd.conf wo man z.B. den Ort des Caches einstellen und diverse Limits setzen kann.

dir /cache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

Informationen zu den Variablen findet man unter man cachefilesd.conf.
Als nächstes muss das Filesystem auf dem der Cache liegt die user_xattr Option bekommen, z.B.

UUID=4d6b8fab-95f1-49e1-9651-16cbcb611ae6 / ext4 errors=remount-ro, user_xattr   0 1

Ebenso muss der mount Eintrag des nfs shares um die Option fsc ergänzt werden

123.123.123.123://web nfs defaults,rsize=32768,wsize=32768,intr,hard,rw,vers=3,fsc 0 0

in der fstab.

Danach noch ein reboot und nach dem reboot prüfen ob der cachefilesd Daemon läuft

/etc/init.d/cachefilesd status

fertig.

————-
Ein kurzer Exkurs wie man eine Ramdisk als Device nutzt

Nun könnte man natürlich auch eine Ramdisk als cache Device nutzen.
Das bringt noch ein paar Prozent an Geschwindigkeit.
Das fasse ich mal in kurz zusammen:

In der fstab /etc/fstab

tmpfs /media/tmpfs default,tmpfs size=10%	0 0

Wir nutzen 10% des RAMs für unseren Cache.

Einmounten unserer Ramdisk

mount /media/tmpfs

Erstellen eines Files in der Größe der Ramdisk

dd if=/dev/zero of=/media/tmpfs/cache bs=1024

Wir legen uns ein Device an und mounten es auf unseren Cache Ordner, den wir in der /etc/cachefilesd.conf angegeben haben

losetup /dev/loop0 /media/tmpfs/cache
mkfs.ext4 /dev/loop0
tune2fs -m0 /dev/loop0]
mount -o user_xattr /dev/loop0 /cache/

und mit

/etc/init.d/cachefilesd start

starten wir den Daemon.

Das findet ihr alles noch etwas besser beschrieben unter http://bopinions.de/?p=127.
Dort steht auch noch wie man das ganze persistent macht.
Das geht bestimmt auch irgendwie ohne den containerfile. Werde ich mir nochmal anschauen.
————-

Mit

$ cat /proc/fs/nfsfs/volumes
NV SERVER PORT DEV FSID FSC
v3 0a6c2008 801 0:21 58be8694:0 yes

kann man prüfen ob fsc auch genutzt wird.

$ cat /proc/fs/fscache/stats
FS-Cache statistics
Cookies: idx=9 dat=3553 spc=0
Objects: alc=2610 nal=0 avl=2610 ded=51
ChkAux : non=0 ok=0 upd=0 obs=0
Pages : mrk=60574 unc=20
Acquire: n=3562 nul=0 noc=0 ok=3562 nbf=0 oom=0
Lookups: n=2610 neg=2610 pos=0 crt=2610 tmo=0
Invals : n=0 run=0
Updates: n=0 nul=0 run=0
Relinqs: n=53 nul=0 wcr=0 rtr=0
AttrChg: n=0 ok=0 nbf=0 oom=0 run=0
Allocs : n=0 ok=0 wt=0 nbf=0 int=0
Allocs : ops=0 owt=0 abt=0
Retrvls: n=3027 ok=0 wt=1796 nod=2967 nbf=60 int=0 oom=0
Retrvls: ops=2967 owt=2389 abt=0
Stores : n=60571 ok=60571 agn=0 nbf=0 oom=0
Stores : ops=10392 run=70963 pgs=60571 rxd=60571 olm=0
VmScan : nos=0 gon=0 bsy=0 can=0 wt=0
Ops : pend=2389 run=13359 enq=70963 can=0 rej=0
Ops : dfr=61 rel=13359 gc=61
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0

bringt Statistiken zum Vorschein.

Ob ich das weiter betreibe und wo die Probleme und Vorteile liegen kann ich noch nicht abschätzen. Das wird sich aber im Laufe der nächsten Tage/Wochen zeigen.
Ein wichtiger Punkt ist natürlich wie Änderungen an Dateien erkannt werden bzw. was sie kosten. Eine expire time wie beim nginx cache kann man nicht einstellen.

An Erfahrungen damit bin ich sehr interessiert.

Update 1: noatime und nodiratime sollte man eventuell aus den Mountoptionen nehmen, da diese für das culling genutzt werden.
Update 2: Nach ein paar Tagen hängen sich die Webserver mit cachefilesd aktiviert auf. Der Zusammenhang ist noch nicht klar.

Links:
http://bopinions.de/?p=127
http://blog.lastlog.de/posts/ubuntu_cachefs_experiments/
http://chase-seibert.github.io/blog/2014/03/09/vagrant-cachefilesd.html
http://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/caching/cachefiles.txt
http://www.cyberciti.biz/faq/centos-redhat-install-configure-cachefilesd-for-nfs/
https://blog.yrden.de/2013/10/13/setting-up-nfs-cache-on-debian.html
http://ispire.me/nginx-over-nfs/
http://blog.spekschoor.nl/2012/08/effective-caching-with-nginx-over-nfs.html

Qnap TS-219 nfs und kvm

Ich kann das Problem nicht 100%ig erklaeren. Anscheinend tauchte es nach einem Update der Qnap Firmware (Current firmware version: 3.3.6 Build 1109T) auf. Ich mounte ein NFS share vom Qnap TS-219 in eine KVM VM ein. Bisher gab es nie Probleme, heute kam dann jedoch

failed, reason given by server: Permission denied

Das NFS share wird nicht automatisch gemountet, daher ist mir das Problem auch erst heute aufgefallen. Auf dem Qnap liegen Backupdaten, auf die ich heute zugreifen wollte. Diverse andere XEN VMs nutzen diesen QNAP in gleicherweise. Diese haben jedoch keine Probleme die shares einzumounten.  Egal welche Einstellungen probiert wurden, die KVM VMs konnten die shares nicht einbinden. Herr E. aus G. gab mir den Tip als export Option beim Qnap „insecure“ einzufuegen. Tatsaechlich funktionierte danach der mount wieder. Unklar ist mir jedoch warum es nur bei den KVM VMs Probleme gab, sowohl der KVM Host als auch die XEN VMs hatten keine Probleme mit NFS.

Da bei jedem reboot, bzw. neu start des NFS Dienstes, die Eintraege in /etc/exports ueberschrieben werden, sollte man in

/mnt/HDA_ROOT/.config/nfssetting

insecure direkt eintragen

[Access]
/share/MD0_DATA/deinefreigabe = rw,insecure

http://forum.qnapclub.de/viewtopic.php?f=49&t=275