On Thu, Nov 12, 2009 at 3:31 PM, Timo Juhani Lindfors <[email protected]> wrote: > Paul Thomas <[email protected]> writes: >> I'm using emdebian grip lenny. Currently mounting the / over nfs. I've > > I'm using normal lenny so what I say here may or may not apply to > emdebian. > >> I don't see any /dev or udev entry in /etc/fstab. How does the system >> know where and how to create "udev on /dev type tmpfs (rw,mode=0755)"? > > /etc/init.d/udev mounts it: > > # mount a tmpfs over /dev, if somebody did not already do it > ... > if ! mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs tmpfs /dev; then > mkdir -p $udev_root/.udev/db/ > >> Where does /dev/.udev/db come from? It's not on the nfs shared > > My guess is that udev generates it. The udev_device_update_db() > function in libudev-device-private.c does things like > > if (udev_device_get_devlink_priority(udev_device) != 0) > fprintf(f, "L:%u\n", udev_device_get_devlink_priority(udev_device)); > if (udev_device_get_event_timeout(udev_device) >= 0) > fprintf(f, "T:%u\n", udev_device_get_event_timeout(udev_device)); > if (udev_device_get_num_fake_partitions(udev_device) != 0) > fprintf(f, "A:%u\n", udev_device_get_num_fake_partitions(udev_device)); > > and the lines in the files in /dev/.udev/db have exactly this format. >
OK, .udev/db is just udev tracking what's in sysfs. So if it's a device in /sys then in takes up space in /dev on the udev tmpfs (i.e. ram which is limited). In the kernel I configured CONFIG_LEGACY_PTY_COUNT from 256 to 16 and this reduced .udev/db from ~2MB to ~500kB which was enough that /dev didn't run out of inodes anymore. Also I guess newer udev versions use a smaller db, so maybe that's already in unstable and it will come down the pipe at some point. thanks, Paul -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
