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? D.
