Messages in this thread | | | Subject | Re: initrd and NFS | Date | 20 May 1997 06:45:12 +0100 | From | Jon Peatfield <> |
| |
> The only objection I can think of to using initrd to nfs mount root is that > if you can do an initrd, why bother remounting root? It seems to me, > a better solution would be to put the bare essentials in initrd, and > then nfsmount /usr and /home (or whatever) and not bother remounting root.
The problem with keeping the initrd around after boot is (as you say) that you need more memory. On machines which are really low on memory there is usually enough space for a small ramdisk, but nothing else will run at the same time. e.g. on 4 or 8M machines you don't want a 1M initrd hanging about.
This is why I was suggesting ditching the initrd after mounting the root partition.
The current initrd scheme won't work for NFS root, since it relies on having a device-ID which is used for the actual mount. If the initrd just left the new root mounted in some special place then the kernel won't need to re-mount it, it just moved this into being the new root, and can then ditch the initrd.
One may only mount on a directory which has an i_count of 1. I think that this will never be the case for / itself (even in the initrd) since you have current->root being / so i_count is at least 2. The new root could be mounted somewhere else though, as long as the kernel knew where to look... Unmounting the initrd would then involve a hack, as under normal circumstances you can't remove a file-system which has something mounted on it. The current initrd code has to be sneaky anyway though so it really isn't much harder (I think -- but I'm no expert).
-- Jon Peatfield, DAMTP, Computer Officer, University of Cambridge Telephone: +44 1223 3 37852 Mail: J.S.Peatfield@damtp.cam.ac.uk
| |