usr/src/uts/common/io/lofi.c
Suggestions:
line 821, 856: Double-check for mutex_owned(lsp->ls_comp_cache_lock)
for both lofi_find_comp_data() and lofi_add_comp_data()?
Questions:
line 863, 865: lofi_max_comp_cache is tunable? What happens when it
switches between non-0 and 0 and back again? Is it possible
for cached segments to get orphaned, or get out of sync?
(Low likelihood...)
Probably check for lsp->ls_comp_cache NULL-ness and take a
moment to dump out the cache if any.
What if someone like me tunes lofi_max_comp_cache to 10240?
Should there be a max lofi_max_comp_cache?
line 2236 and following (new file numbering):
Does anything need to be done about -f(orce) option to lofi?
I left a note there for the next person, but wouldn't expect
anything other than a call to lofi_free_comp_cache() for the
time being.
Nits:
line 848,849: missing words?
line 1191: spelling
D.
sanjay nadkarni (Laptop) wrote:
> Hopefully third time is a charm..the review is located at:
>
> http://cr.opensolaris.org/~nadkarni/bug6679115+6805505/
>
> Dina wrote:
>> Was there a link to ...? I looked at the CR for 6679115 in the
>> suggested fix and had no comments.
>>
>> Thanks,
>> D.
>>
>> sanjay nadkarni (Laptop) wrote:
>>>
>>> I am sponsoring the following changes for Juergen Keil. Please send
>>> your comments to caiman-discuss and cc jrgn.keil at sun.com. I would
>>> like these to be included in build 111 since that will help us reduce
>>> the number of ISOs for OpenSolaris.
>>>
>>> The bugs are:
>>> 6679115 lofi(7) shouldn't accept non-powers of 2 for a segment size
>>> 6805505 lofi needs a performance boost
>>>
>>>
>>>
>>>
>>>
>
