Re: [PATCH 5/5] zram: Set initial disksize to some default value

[Nitin Gupta]

On 09/09/2011 08:50 PM, Valdis.Kletnieks@xxxxxx wrote:

> On Fri, 09 Sep 2011 20:18:56 EDT, Nitin Gupta said:
>> On 09/09/2011 07:12 PM, Greg KH wrote:
>>
>>> On Fri, Sep 09, 2011 at 07:01:04PM -0400, Nitin Gupta wrote:
>>>> Currently, we set initial disksize as 0, which forces
>>>> user to write some value to corresponding zram device's
>>>> sysfs node, before the device can be used. Now, we avoid
>>>> this step by providing some default size initially.
>>>>
>>>> To change the disksize, user must:
>>>>  - Reset disk.
>>>> 	Ex: echo 1 > /sys/block/zram0/reset
>>>> (NOTE: disksize is set to the default value after reset)
>>>>
>>>>  - Set new disksize.
>>>> 	Ex: echo $((256*1024*1024)) > /sys/block/zram0/disksize
>>>
>>> So, what tools just broke with this change?
>>>
>>> And where is the sysfs file documentation change that should go along
>>> with this?
>>>
>>
>>
>> This change does not change any sysfs names or behavior, so does not
>> break any scripts that assume the current behavior.
> 
> Consider the current case:   We init size to zero, and a startup script changes
> it to 1024 and then sticks 768 of data in there.  No Problem.
> 
> We now get a kernel that's built with a default of 512.  The startup script
> tries to change it to 1024, but doesn't know it has to splat something into
> 'reset' for it to actually work.  It then tries to stick 768 of data in there,
> and hilarity ensues...
> 
> If I haven't misunderstood...
> 


Setting default size of say 512 doesn't make the device initialized.
The initialization happens only when user issues any I/O to the device
and only after initialization the disksize cannot be changed.
So, when user writes say 768 as new disksize in uninitialized state, the
new disksize will take effect and there will be no surprises.

Device reset is needed only when user wants to discard existing data and
bring device to uninitialized state again, after which disksize can be
changed again.

Nitin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/