LKSF Sneak Preview: CacheFS

Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Navigation

< My Canon left me for a repair | Nachholen >

LKSF Sneak Preview: CacheFS

Tuesday, August 12. 2008

I´m writing a new tutorial for the Less Known Solaris Feature series. This time it´s about CacheFS. CacheFS is one of the really hidden gems of Solaris. You can find it in the work-in-progress version of the LKSF book. It starts on page 74.

Posted by Joerg Moellenkamp in English, Solaris at 18:16 | Comments (9) | Trackbacks (0)

Defined tags for this entry: cachefs

, lksf

, solaris

, sun

Related entries by tags:

View as PDF: This entry | This month | Full blog

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

The conclusion section of the CacheFS chapter is missing an apostrophe in the "arent".

More importantly: I have a server with encrypted partitions. I trust the user with a password to access the data transiently and handle it consciously. If the client system starts caching the data in large amounts, I moot the server encryption (at least in my setup). Is there an option to keep the cache encrypted?

Thanks!

#1 O Seidel on 2008-08-13 10:15 (Reply)

I can't recommend CacheFS now (although we still use it for many years) for several reasons:
- Filling the Cache is transparent, but very slowly
- no "umount -f".
- No NFS 4 support
- as you can see in the EOF discussions, nobody want's to maintain the code anymore.

There's no alternative to CacheFS, but the existing implementation is not recommendable.

#2 Achim Neumann on 2008-08-13 23:25 (Reply)

thats correct, we've just completed the EOF case for
cachefs to get the process started to put it to sleep in the longer run.

http://www.opensolaris.org/jive/thread.jspa?threadID=67765&tstart=75
http://www.opensolaris.org/jive/thread.jspa?threadID=67799&tstart=45

#2.1 batschul (Homepage) on 2008-08-15 10:26 (Reply)

I´m strongly opinionated about this feature. As Achim wrote: There is no alternative to this feature ... and it´s a shame that we´ve put this feature into sustaining mode, as it´s one of the features, that makes live much easier.

I really think, we need something like CacheFS2, at least for NFS.

#2.1.1 Joerg+M. (Homepage) on 2008-08-15 11:18 (Reply)

Ich hab in deinem Dokument grade den Abschnitt über export/home gesehen und hab da zwei Fragen zu die ich schon ne weile hatte:

a) mount unter solaris gibt nicht so wirklich den "fstype" aus, das ist grade bei VxFS oder NFS ärgerlich wenn man anhand der optionen raten muss. In deinem Beisiel z.b. frage ich mich ob der auto mounter das lokale exort/home vial NFS (von lokalhost) gemounted hat oder ob es da ein loopback/bind mount gibt.

Hintergrund: ist die Performance vergleichbar mit direktem /export/home pfad?

b) das ist die zweite frage, wenn ich einen anwendungsuser auf einem solaris server anlege wo es kein anderer gibt mit dem ich ein home sharen will. Ist es besser

b1) /export/home in der passwd zu verwenden
b2) autofs fuer /home abzuschalten
b3) eine lokale map anzulegen auf das risiko hin dass ich zusaezliche abhaengigkeit von nem service habe den ich nicht brauch.

Gruss
Bernd

#3 Bernd Eckenfels (Homepage) on 2008-08-14 10:23 (Reply)

eine TCP-Verbindung zwischen einem zpool und seinem L2ARC wuerde mich begeistern...

#4 Olli on 2008-08-14 16:56 (Reply)

Was hast Du damit vor ? L2ARC lokal und zpool via iSCSI holen geht heute schon

#4.1 Joerg+M. (Homepage) on 2008-08-14 19:22 (Reply)

da ich CacheFS nie richtig benutzt habe, kann auch sein, dass ich gerade falsch liege. Aber ein lokaler L2ARC mit einem remote zpool wuerde doch das gleiche tun wie CacheFS, naemlich remote Daten lokal vorhalten. iSCSI ist ne gute Idee, SRP via Infiniband sollte aber weniger CPU verbrauchen. Funktioniert das schon mit (Open)-Solaris?

#4.1.1 Olli on 2008-08-14 19:45 (Reply)

Das SRP-Target fehlt noch, kommt aber bald im Rahmen von COMSTAR.

NFS ist per se multiple reader/multiple writer faehig. waehrend ds bei ZFS/L2ARC nur dann geht, wenn man ein entsprechendes Filesystem dort noch on top setzt , das die funktion mitbringt.

Vergleichbar sind die funktionen nicht

#4.1.1.1 Joerg+M. (Homepage) on 2008-08-14 21:54 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: Standard emoticons like :-) and ;-) are converted to images. Enclosing asterisks marks text as bold (word), underscore are made via _word_.
	Remember Information? Subscribe to this entry