On 03/11/09 14:44, Dina wrote: > > > Juergen Keil wrote: >> 2009/3/11 Dina <dina.nimeh at sun.com>: >>> > ... >>> >>> Now you turn it back on by setting the value back to 1. The segment >>> that is already cached is still sitting there. What happens to it? >> >> It will be reused, in case the next lofi read will result in a cache >> hit. >> >> Since compressed lofi only works in read/only mode, the cached >> uncompressed data is still valid. >> > > Ah, it's read-only, ok. > >> # lofiadm -a `pwd`/solaris.zlib /dev/lofi/5 >> # dd if=/dev/zero of=/dev/rlofi/5 count=2 >> write: Read-only file system >> 1+0 records in >> 1+0 records out >> >> >> Hmm, but why does the following work using the lofi block device? >> Seems to be another bug... I'd expect that this get s a EROFS error, >> too. >> >> # dd if=/dev/zero of=/dev/lofi/5 count=2 >> 2+0 records in >> 2+0 records out >> > > I don't know if this is related to an existing bug: > 6717722 lofi must not write to R/O file systems > >> >>> It releases the memory at unmap time, is unmapping the file a >>> guaranteed >>> event at this point? If not, then does this lead to a stale segment in >>> the cache? >> >> No, patching / changing the lofi_max_comp_cache variable doesn't >> result in unmapping the file (that is calling lofi_free_handle(()). >> You would have to use lofiadm -d and close all references to the >> /dev/lofi/N file to get the cache memory released. >> > > Did not mean that changing lofi_max_comp_cache unmaps the file, I know > that. Rephrasing: "Lofi releases the memory at unmap time, ok, however > what guarantees that an unmap happens between the time the caching is > disabled and the time the caching is re-enabled?" > > It seems the answer is related to the compressed lofi being read-only. > Inconsistency is not an issue, is that correct? > >> >> Hmm, you could construct a case with attaching a compressed lofi file, >> and write to the underlying vnode. >> >>>> Do we really need code to shrink the lofi decompress cache at runtime? >>> I think I understand that 1 cached segment gives a nice boost. And >>> that >>> the improvement is probably not linear. At some point it doesn't matter >>> if you have 5 or 10 for your max cache size, the incremental >>> performance >>> improvement may no longer be noticeable. >>> >>> That's why I asked what would happen if I set it 10240. Would it >>> really >>> grow to 10240, or would it cut me off somewhere and not grow >>> anymore, to >>> prevent running out of heap? >> >> It would grow to 10240 cached segments. > > Is there any value to put a hard limit on how big lofi_max_comp_cache > can ever be? Juergen: I believe what Dina is asking for is to limit the size of the cache to prevent tunable from sucking up all the heap.
-Sanjay > > D.
