On Thu, 11 Feb 1999 10:31:57 +0100 (MET), Andries.Brouwer@cwi.nl said:
> But it is an internal kernel bug. User space doesnt know about it.
> An ioctl cannot help.
> (At most it can help in avoiding the problem, just like my solution:
> `mount ... -o blocksize=1024' helps in avoiding the problem.)
> No, we do not want ioctls. The kernel must be fixed.
No. There is no way I'll support the idea of making set_blocksize
preserve data in the buffer cache. That is just brain-dead. So if
you want to go and change every filesystem in the kernel to support
non-local blocksizes, go right ahead.
You are reading more into my response than I said.
One part of the kernel does something, and another part
of the kernel reacts to that in an unexpected way.
The respective authors of each of the two kernel parts
involved may claim that their code is correct, but it is
clear that the combination of the two yields a buggy kernel.
In this particular case the msdos fs does a set_blocksize(512).
This call should fail in the case of a RAMdisk, and then the
msdos fs has the choice of using a blocksize 1024, which it is able to,
or returning an error for the mount call.
The "right" fix is to make set_blocksize fail on an in-use ramdisk,
Yes, precisely.
NOT to support changing the blocksize for existing buffers.
But I think nobody ever suggested that.
Allowing
the user to set a correct blocksize via ioctl before mkfsing the
device in the first place makes a ton of sense, however.
It does no harm to give user space additional capabilities,
but this is almost irrelevant to what we are discussing.
There is a kernel-internal bug that we have to fix.
That the user could avoid encountering the bug by present
or future mechanisms is an entirely different matter.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/