udev init script should use partition size from /etc/default/tmpfs

Bug #317161 reported by Iuri Diniz
2
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

I'm tunning ubuntu to a low memory device without swap (eee pc 701), I'm currently managing the max size of tmps partitions by setting size on /etc/default/tmpfs, but udev doens't use that settings, so I've made a patch to correct it.

the default behavior to udev init script (kernel behavior) is to set tmpfs partition to half size of system ram that I think is too much, 8 MB would be sufficient

using this patch, udev size will use UDEV_SIZE option if setted on /etc/default/tmpfs, if not setted it will use TMPFS_SIZE option if setted, and if not setted too, the default behavior is assumed

this is my first patch, I don' t if I made it correctly following the guidelines

Revision history for this message
Iuri Diniz (iuridiniz) wrote :
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 317161] [NEW] udev init script should use partition size from /etc/default/tmpfs

On Wed, 2009-01-14 at 16:51 +0000, Iuri Diniz wrote:

> I'm tunning ubuntu to a low memory device without swap (eee pc 701), I'm
> currently managing the max size of tmps partitions by setting size on
> /etc/default/tmpfs, but udev doens't use that settings, so I've made a
> patch to correct it.
>
> the default behavior to udev init script (kernel behavior) is to set
> tmpfs partition to half size of system ram that I think is too much, 8
> MB would be sufficient
>
Actually, I believe you're mistaking tmpfs with ramfs here. Space is
not reserved for a tmpfs, it simply sets the maximum size to which the
tmpfs may grow.

If a tmpfs is only using 5MB, then it will only consume 5MB of memory;
it's backed by the page cache, so there is little overhead for such
things as filesystem (in fact, there isn't one!)

/dev is not writable by ordinary users, there is no danger of users
filling this filesystem with other data.

However there it is preferred that this filesystem "not become full", if
the udev daemon is unable to make device nodes, or maintain its
database, then system features such as hotplug fail to work and newly
connected devices are not available.

It is for this reason that we choose not to limit the size of the
filesystem.

 status wontfix

Scott
--
Scott James Remnant
<email address hidden>

Changed in udev:
status: New → Won't Fix
Revision history for this message
Iuri Diniz (iuridiniz) wrote :

Hello Scott,

On Thu, Jan 15, 2009 at 2:03 PM, Scott James Remnant <email address hidden>wrote:

> Actually, I believe you're mistaking tmpfs with ramfs here. Space is
> not reserved for a tmpfs, it simply sets the maximum size to which the
> tmpfs may grow.
>
> If a tmpfs is only using 5MB, then it will only consume 5MB of memory;
> it's backed by the page cache, so there is little overhead for such
> things as filesystem (in fact, there isn't one!)
>

I know that

>
>
> /dev is not writable by ordinary users, there is no danger of users
> filling this filesystem with other data.
>
> However there it is preferred that this filesystem "not become full", if
> the udev daemon is unable to make device nodes, or maintain its
> database, then system features such as hotplug fail to work and newly
> connected devices are not available.
>

I tottaly agree with you

>
> It is for this reason that we choose not to limit the size of the
> filesystem.
>
I think that you misunderstood me, I'm not suggesting to limit the size, I'm
suggesting to allow people if they want, they can limit the size. Currently
on ubuntu, I can do this on /dev/shm, /var/lock, /var/run, /lib/init/rw [1],
but I can't on /dev

The default behavior of my patch is to do nothing because the default
contents of /etc/default/tmpfs on my ubuntu is to not limit size. So the
patch only add support to allow people to choose the size, the patch is not
imposing the size.

IMHO I think that allowing people to choose the max size a good thing, but,
anyway, the final decision is yours, and I will respect it.

Thank you for your feedback

[1] see the contents of /etc/init.d/mountkernfs.sh,
/etc/init.d/mountdevsubfs.sh, /etc/init.d/mtab.sh
--
Iuri Diniz
http://iuridiniz.com [Sou um agitador, não um advogado]
http://blog.igdium.com [Linux on Limbo]

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Also, does adding the option in a remount actually have any effect?

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Iuri Diniz (iuridiniz) wrote :

"Also, does adding the option in a remount actually have any effect?"

yes,

iuri@cego:~$ free
             total used free shared buffers cached
Mem: 1285120 1249400 35720 0 205400 422532
-/+ buffers/cache: 621468 663652
Swap: 2441872 12608 2429264

iuri@cego:~$ df -h /dev/
Filesystem Size Used Avail Use% Mounted on
udev 628M 2.9M 625M 1% /dev

iuri@cego:~$ sudo mount /dev/ -o remount,size=8M
[sudo] password for iuri:

iuri@cego:~$ df -h /dev/
Filesystem Size Used Avail Use% Mounted on
udev 8.0M 2.9M 5.2M 36% /dev
iuri@cego:~$

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote : Re: [Bug 317161] Re: udev init script should use partition size from /etc/default/tmpfs

On Thu, 2009-01-22 at 03:43 +0000, Iuri Diniz wrote:

> iuri@cego:~$ df -h /dev/
> Filesystem Size Used Avail Use% Mounted on
> udev 628M 2.9M 625M 1% /dev
>
> iuri@cego:~$ sudo mount /dev/ -o remount,size=8M
> [sudo] password for iuri:
>
> iuri@cego:~$ df -h /dev/
> Filesystem Size Used Avail Use% Mounted on
> udev 8.0M 2.9M 5.2M 36% /dev
> iuri@cego:~$
>
But what happens if you try and fill this?

Scott
--
Scott James Remnant
<email address hidden>

Revision history for this message
Iuri Diniz (iuridiniz) wrote : Re: [Bug 317161] Re: udev init script should use partition size from /etc/default/tmpfs

On Thu, Jan 22, 2009 at 1:15 PM, Scott James Remnant <email address hidden>wrote:

> But what happens if you try and fill this?

Hum, I got. It will be a problem on the patch :-(

iuri@cego:~$ sudo mount /dev -o remount,size=8M && echo 1
1
iuri@cego:~$ sudo mount /dev -o remount,size=4M && echo 1
1
iuri@cego:~$ sudo mount /dev -o remount,size=1M && echo 1
mount: /dev not mounted already, or bad option
iuri@cego:~$

--
Iuri Diniz
http://iuridiniz.com [Sou um agitador, não um advogado]
http://blog.igdium.com [Linux on Limbo]

Revision history for this message
Iuri Diniz (iuridiniz) wrote :

tmpfs documentation says:
"These parameters accept a suffix k, m or g for kilo, mega and giga and
can be changed on remount. The size parameter also accepts a suffix %
to limit this tmpfs instance to that percentage of your physical RAM:
the default, when neither size nor nr_blocks is specified, is size=50%"

I had started to modify my patch to verify if the size on UDEV_SIZE is too few, but since tmpfs accepts % as suffix for size parameter it will be a very ugly verification for a very little (and maybe unnecessary) enhancement.

I was thinking to use:
df -m /dev | egrep '/dev$' | sed 's/ */ /g' | cut -d ' ' -f 2
instead of:
df -m /dev | tail -n 1 | awk '{print $2}'

because awk and is not on /bin, but egrep and sed is

And use:
--- cut ---
case $1 in
*M)
    echo MEGA;
    ;;
*K)
    echo KILO
    ;;
*%)
    echo PERCENT
    ;;
esac
--- end ---
instead of:
[[ "86M" = *@(M|m) ]] && echo MEGA

because dash doesn't support pattern matching like bash does.

------
In summary, this approach will be very complicated, so I think is the wrong way to do something simple. If this enhancement is really necessary I could live with the previous (and bugged) approach that issues a mount error. Anyway, leave as is it.

Bug status STILLS wontfix

Thanks Scott

Revision history for this message
Iuri Diniz (iuridiniz) wrote :

oops, the correct command to get actual used size of /dev is
df -m /dev | egrep '/dev$' | sed 's/ */ /g'| cut -d ' ' -f 2

one more space on sed

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.