Messages in this thread | | | Date | Mon, 29 Nov 1999 17:42:55 +0100 | From | Martin Dalecki <> | Subject | Re: [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/
| |