Jean-David Beyer wrote:
>
> Sure, some even read the entire cylinder. But unless the data are stored
> contiguously, this does little good. The Linux ext2 and ext3 file systems
> try to get more contiguity by allocating (IIRC) 8 blocks each time a write
> needs space
From where do you recall this?
It looks to me like managing the block reservation window
seems like a pretty involved process - at first glance way
more sophisticated than a hardcoded 8 blocks.
http://www.gelato.unsw.edu.au/lxr/source/fs/ext3/balloc.c
> (and gives the unused ones back when the file is closed for
> writing). But for a dbms that uses much larger page and extent sizes, this
> makes little difference. This is one of the reasons a modern dbms does its
> own file system and uses only the drivers to run the disk.
I'd have thought the opposite. The fact that old filesystems
had pretty poor block reservation algorithms and even poorer
readahead algorithms is one of the reasons historical dbms
writers wrote their own filesystems in the past. If you're
on a '90's VMS or Win9X/FAT - you have a lot to win by having
your own filesystem. With more modern OS's, less so.
> That way, the
> DBMS can allocate the whole partition in a contiguous lump, if need be.
There's nothing that special about a database file in that
regard. You may win by having the database executable program
be a continuous lump too - especially if lesser used pages of
the executable get swapped out (which they should - if they're
accessed less frequently than a database table that could use
the RAM).