Messages in this thread | | | Date | Mon, 4 Sep 2000 10:24:01 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Large File support and blocks. |
| |
Hi,
On Fri, Sep 01, 2000 at 12:09:23AM -0700, Linda Walsh wrote:
> Perhaps an "easy" way to go would be to convert block numbers to > type "block_nr_t", then one could measure the difference that 10's of > nanoseconds make against seeks and reads of disk data.
You might not find it just taking 10s of nanoseconds. Intel CPUs have very few registers, and register spills can be slow. long long operations cause _lots_ of register spills, and we would end up taking that cost down all of the buffer cache lookup paths, not just on disk IO.
We also need to avoid changing the buffer-cache API in such a way that existing drivers will fail silently if not modified. Certain drivers we just don't want to touch --- drivers/block/floppy.c is the single ugliest piece of code in the whole kernel (but then, it drives one of the worst-specified and most buggily reimplemented piece of hardware...). Just moving the type to 64 bits will not stop drivers from performing 32-bit arithmetic on them!
> If the change became as simple as changing a typedef in a file, then you > could even allow a user to choose to allow "very large files" -- compiling > with long long when turned on, or simple ints when turned off -- if that > was seen as a necessity -- but I'd still lean toward it not being noticable.
We already have that for regular files. The block device case should be transparent to user space (except for fsck/mkfs) in most cases, because the user will only be accessing those devices via a filesystem, and will never see block numbers directly.
Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |