[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <62714.1315615809@turing-police.cc.vt.edu>
Date: Fri, 09 Sep 2011 20:50:09 -0400
From: Valdis.Kletnieks@...edu
To: Nitin Gupta <ngupta@...are.org>
Cc: Greg KH <greg@...ah.com>, Jerome Marchand <jmarchan@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Robert Jennings <rcj@...ux.vnet.ibm.com>,
Linux Driver Project <devel@...uxdriverproject.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/5] zram: Set initial disksize to some default value
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...
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists