lkml.org 
[lkml]   [1999]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATH] A few things for immediate cleanup.
    Andrea Arcangeli wrote:
    >
    > On Mon, 29 Nov 1999, Martin Dalecki wrote:
    >
    > >Second I have noticed that the usuefullness of the
    > >get_hardblocksize function is, lets say, at least
    > >questionable. The simple logics is that:
    > >
    > >1. Why do get all the other file systems around
    > >without using it?
    >
    > Because you can't build a 1k fs on a 2k blockdevice.

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:4.944 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site