NDCODE repository - FUZIX.git/log

Alan Cox [Sun, 22 Oct 2017 14:13:13 +0000 (15:13 +0100)]

remount: add new syscall interface

Alan Cox [Sat, 21 Oct 2017 23:04:02 +0000 (00:04 +0100)]

kernel: rework buffer handling and superblocks

Be scared.. be very scared

Back up your disks before testing this changeset

The basic idea of this set of patches is to put in most of the framework for
keeping the buffer cache outside of the main kernel mapping. Instead we
introduce some functions to copy between kernel/buffer and user/buffer. As
most traffic goes directly between user/buffer this doesn't hurt us. These
patches don't implement the bits needed for an external buffer cache but they
do implement the framework required to add it.

To minimize impact on some bits like directory scanning we also introduce a
routine that with separate buffer cache address space wil make a temporary copy
of a small area, but on machines with the buffer cache in the normal place
resolves as essentially the same assembler as before (6502 suffers a tiny bit
I suspect).

In order to do this we also have to rework the mount handling. Superblocks are
now copied to/from buffers on mount and sync rather than pinning a buffer. The
superblock buffers mean that for a small system you probably want to drop the
buffer cache size by one block (the one previously pinned for the superblock)
in favour of the superblock table entries you'll now get (which are about 256
bytes each).

Execve is also tided up. We had a set of custom fastpath code for loading a
binary. Only it turns out that if we use readi the existing O_DIRECT fastpath
will do the work for us, which means execve itself can become oblivious to
where the buffer cache hides. This will need work for 8086 when split I/D hits
but it's quite manageable.

While I was at it I also realised that the problem with trying to add remount
support to mount is that remounting despite what the name implies is actually
a variant of umount. You do the same lookups to find the same existing
superblock, iterate the inode list but then swizzle some flags instead of
checking it is non-busy and firing it into hyperspace.

This patch changes umount(x) into _umount(x, flags) where flags include
MS_REMOUNT, MS_RDONLY and MS_NOSUID (not yet properly supported). This provides
enough functionality that you can now probably safely boot read only, fsck the
root fs (except I need to port the native fsck over and squash memory usage)
and the mount it r/w. You *cannot* fix the root fs and remount it without a
reboot. That involves jumping through far too many hoops. I think this is
sufficient as it'll allow the default initscripts to fsck, check and either
reboot or go read/write so we have proper fs recovery (whoopeee)

Programs using umount (all one if it) will need recompiling.

Why do all this

1. It lets you push several KB out of kernel space, which is valuable space
you can then turn into code, inodes (much needed) or processes.
2. Some platforms need the buffers themselves aligned and on boundaries. The
existing model doesn't handle this. For example the PC needs them so one does
not cross a DMA boundary.

At the moment we have systems with 512K+ of RAM that simply can't run with an
appropriate amount of buffering and inodes. Once 8086 is included we get into
situations where we might have 4MB of expanded memory and at that point we
can't hope to get the buffers needed into the 64K of data space, while we
can shove it elsewhere, and with expanded memory into a 64K expanded memory
bank along with some other oddments.

Once this support is finished we can shove both the tty buffers and the disk
buffers out of the way. On a 'big' configuration like a 286 PC we need something
like 30K for process/inode/file/buffer head/superblock data structures to match
the values 2BSD tuned to. That's without buffers ! The big hogs in the kernel
are then the inode structures and the process table entries. We might be able
to move a few bits of the process into its udata but neither it nor pushing
inodes out are easy problems to attack.