Are you sure? If I remember the mcdx.c block strategy routine here
I think one could get surprised here ...
> >2. At least raid and frieds basically just don't care about it if I
> >understand
> >the code correctly.
>
> Because raid always uses a PAGE_SIZE blocksize and by design linux doesn't
> support blockdevices with blocksizes > PAGE_SIZE.
So why comes it that it's possible to drive fs with less blocks through
RAID?
> >Removing this would make at least the quite offending two dimensional
> >hardsect_size array almost a "write only" variable, which could be used
> >for
> >a significant overall device handling cleanup.
>
> Of course we need to clean up this to extend the kdev_t or we'll have a
> too big array but the logic must remains. If you don't know the
> hardblocksize you don't know if the blocksize of the fs that you are
> mounting is too big for your underying blockdevice.
This doesn't answer one question: Why do all the other filesystems
working fine
without it? In esp. for example the minixfs.
> >I have anyway the impression that all device drivers are emulating
> >nearly
> >arbitrary physical block sizes, just due to the fact that:
>
> You can't emulate a 512kbyte softblocksize with a 2k hardblocksize.
>
> About the patch the #defines are faster during compile and we may need
> NR_REQUESTS from the outside. The compiler can't generate better code with
> an inline if something it's the opposite if the compiler is lazy.
Andrea I was looking at the generated code before I came to the
conclusion that the macro hackery doesn't give you any gain.
The NR_REQUESTS isn't used anywhere else and it's kernel internal
thing that shouldn't be exposed to user space. (it wasn't).
> + * Mon Nov 29 01:33:28 CET 1999 Marcin Dalecki <dalecki@cs.net.pl>:
> + *
> + * This is indeed bad, since:
> + *
> + * 1. It's heavly dependant upon the number of bits in kdev_t.
> + *
> + * 2. I miss the logical justification why exactly this (obscure) hash function
> + * should be better then anything more tangible.
>
> What DaveM did is been to grab hardware, stress it in different ways
> logging all the hash insert/remove he generated on the buffer cache. Then
> he took the log and made an hashfn that was distributing the buffer heads
> in the best possible way for his empirical input.
I doubt seriously if the result of this procedure give good results on
the average system out there. At least I would prefere much to have a
deductive
statement supporting it.
-- Marcin Dalecki- 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/