Re: fadvise syscall?

[Anton Altaparmakov]

At 20:19 17/03/02, Ken Hirsch wrote:
>Anton Altaparmakov writes:
> > Last time I heard serious databases use their own memmory
> > management/caching in combination with O_DIRECT, i.e. they bypass the
> > kernel's buffering system completely. Hence I would deem them irrelevant
>to
> > the problem at hand...
> >
> > If a database were not to use O_DIRECT I would think it would be using
>mmap
> > so it would have madvise already... but I am not a database expert so take
> > this with a pinch of salt...
>
>I don't think that either MySQL or PostgreSQL use O_DIRECT; I just grepped
>the source and didn't find it.  They can't use mmap() because it uses up too
>much process address space.

<flame bait>So you consider these two to be serious databases?</flame bait> 
(-; [1]

>It's true that commercial databases mostly do their own scheduling and
>caching, and if they are the only thing running on your system and you tune
>them right, that works.  But it's not necessarily a good thing.  If there
>are other processes on your system, there would be a benefit if the DBMS
>could inform the operating system of its intentions.
>
>A posix_fadvise() call would be a start, but you could potentially go beyond
>that.

Ok, so basically we want both fadvise() and open(2) semantics, with the 
open(2) being a superset of the fadvise() capabilities (some things no 
longer make sense to be specified once the file is open). They can of 
course both be calling the same common helpers inside the kernel...

fadvise() would probably only be used by databases while open(2) would be 
used by the rest of the world. (-;

Best regards,

Anton

[1] Sorry about the flame bait, couldn't resist...  I know they are both 
very respectable databases and they are free software which is great.