lkml.org 
[lkml]   [2000]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [from the cache]
©2003-2011 Jasper Spaans