Re: reiserfs & databases.
On Wed, 30 Aug 2000, Nathan E Norman wrote:
>On Tue, Aug 29, 2000 at 04:36:23PM +0200, Dariush Pietrzak wrote:
>> but, there are some commercial databases which keep their data directly
>> on partitions ( this should be much better then any *fs including
>> reiserfs) and the weird part is that that direct-partition instalation
>> scheme seems to be a little bit slower that fs-based in benchmarks.
>> And this means that I'm missing something here, what is it that I haven't
>> thought about, anyone, any comments on this?
>
>If I understand your question, you're saying that RDBMs do benchmark
>faster using a native filesystems rather than rolling their own on
>a partition, and you're wondering why ... I would have to hazard a
>guess that the operating system disk cache and buffers are coming
>into play when you're using a native filesystem, but there's no
>caching when a "raw" partition is used.
The idea is that the database vendor knows their data storage better than the
OS can guess it, and that knowledge allows them to implement better caching
algorithms than the OS can use.
The fact that benchmark results show that raw partition access is slower
indicates that the databases aren't written as well as they are supposed to
be.
The concept of the database being able to cache better than the OS sounds
reasonable, but seems to not work in practise. I have seen other examples of
similar principles. One of which was someone who did tests with IBM's
HPFS386 file system for server versions of OS/2. He tried using 2M of cache
with HPFS386 and 16M of physical cache in a caching hard drive controller and
using 18M of HPFS386 cache with no cache on the controller. The results were
surprisingly close on real-world tests such as compiling large projects. It
seemed that 2M of cache was enough to cache directory entries and other
file-system meta-data and cache apart from that worked on a LRU basis anyway.
Russell Coker
Reply to: