Subject: Re: improvements to mknod(8)
To: <>
From: David Laight <david@l8s.co.uk>
List: tech-userlevel
Date: 02/10/2003 09:08:18
On Mon, Feb 10, 2003 at 09:36:46AM +1100, Luke Mewburn wrote:
> On Sun, Feb 09, 2003 at 08:42:38PM +0000, David Laight wrote:
>   | Some timings for my 50MHz sparc running diskless.
>   | 
>   | issue:		92.03s real    25.27s user    50.80s system
>   | mtree:		18.30s real     5.61s user    10.83s system
>   | mknod:		93.13s real    33.60s user    55.11s system
>   | 
> It is unclear to me (early in the morning, coffee not affecting
> neurons yet), what you're timing there.  What is "issue", "mtree",
> and "mknod"  referenced in your examples?

ok, 'issue' is the standard MAKEDEV script.
'mtree' is a copy of MAKEDEV where all the 'mknod' commands have been
replaced by echo commands that output the data in the form required by
mtree, any chgrp, chown and chmod requests have been collected into the
comamnd line.
'mknod' is the modified script, but calling a shell function to convert
the 'mtree' line into a mknod call.

I've also realised why my 'mknod' is slower that 'issue'.  It is down
to the cost of looking up a username or groupname.  Fixing that lookup
in the script (and adding another option to check for numeric uid/gid
values before doing the name lookup [1]) gives me times of:
			79.61s real    30.49s user    49.31s system

> Note; the reason that the install media uses the mfs trick instead of
> just "stuffing" the devices into the ramdisk is that /dev in the
> latter case consumes a lot of inodes and the ramdisk runs out of
> space (e.g, 2000 inodes on a 3MB file system).

And I thought it was only used if root was cdfs etc.
Any script that replaces the mfs /dev will need to check there
are enough free inodes - as well as checking that device entries
can exist.

	David

[1] Who on earth allowed group "32" to have number 17 ?

-- 
David Laight: david@l8s.co.uk