2009/3/11 Dina <dina.nimeh at sun.com>
> Juergen Keil wrote:
>> 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
I think that's different.
lofi_strategy_task does fail the writes on the block device with EROFS
errors, but the write is async, so the user program doesn't notice the
errors?
/*
* Compressed files can only be read from and
* not written to
*/
if (!(bp->b_flags & B_READ)) {
bp->b_resid = bp->b_bcount;
error = EROFS;
goto done;
}
The same problem exists with sd(7D) when trying to write to a
DVD-ROM media:
# dd if=/dev/zero of=/dev/rdsk/c0t1d0p0 count=64 bs=2k
write: I/O error
1+0 records in
1+0 records out
# dd if=/dev/zero of=/dev/dsk/c0t1d0p0 count=64 bs=2k
64+0 records in
64+0 records out
Using the ps/2 floppy driver and a read/only floppy media:
In this case the char and block device open() fails with EROFS.
# dd if=/dev/zero of=/dev/rdiskette count=64
dd: /dev/rdiskette: open: Read-only file system
# dd if=/dev/zero of=/dev/diskette count=64
dd: /dev/diskette: open: Read-only file system
I think lofi could do the same, and fail open for write
on a non master control device, when a compressed
file is mapped.
>>> 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?"
That would be a problem if it would be possible to map a new file for an active
lofi device, but that isn't possible.
# mount -F hsfs /files2/media/os200906.iso /mnt
{ change lofi_max_comp_cache from 1 => 0 here }
# lofiadm
Block Device File Options
/dev/lofi/1 /files2/media/os200906.iso -
# lofiadm -f -d /dev/lofi/1
# lofiadm -a /files2/media/os200811.iso /dev/lofi/1
lofiadm: could not map file /files2/media/os200811.iso to /dev/lofi/1:
File exists
{ assuming the above lofiadm -a would be possible (but it isn't);
change lofi_max_comp_cache from 0 => 1 here }
lofi_map_file() checks that there is no existing state before reusing a
lofi device, lines 1798,1799:
1787 if (pickminor) {
...
1796 } else {
1797 newminor = klip->li_minor;
1798 if (ddi_get_soft_state(lofi_statep, newminor) != NULL) {
1799 error = EEXIST;
1800 goto out;
1801 }
1802 }
The soft state is freed in lofi_free_handle() - at the same time
the cache with decompressed data is freed.
> 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?
Hmm, we currently have no upper limit for the
compression segment size, either. The following
command could have bad effects on a system:
mkfile -n 3G /var/tmp/foobar
lofiadm -C 1g /var/tmp/foobar
lofiadm -a /var/tmp/foobar /dev/lofi/99
od -xc /dev/lofi/99
And with s/3G/4G/, the compressed lofi file after lofiadm -a is empty?
Another >= 4 giga byte bug?
> D.
>
