On Fri, 5 May 2000, Graham; Stephen wrote:
> >I'm not sure how deep you want to go into this project but there is
> >another (fairly advanced) option with raw i/o. In a nutshell, this
> >bypasses the kernel buffer cache and gives you direct access to disk. It
> >is often used (and even required) by high-end database products.
>
> Were I to implement this kind of thing, how badly off would this put me for
> portability?
In traditional terms, it's not portable, but the reality is that raw i/o
is available for all serious, modern, commercial Unices in the enterprise
market. You would need to investigate the raw i/o semantics for each
target platform to determine the kinds of problems you might or might not
run into.
> My plan is also to have the blocks in the database set to exactly one page
> in size, which may save me some hassle(?).
Note that the page size may change between hardware platforms (but that
shouldn't stop you from doing clever things in the code).
Also, contrary to my last post, the current Linux implementation requires
memory alignment with the _sector_ size of the underlying device, which
is typically 512 bytes (and works fine with common page alignments anyway).
But the big question on this issue for you might be whether it is within
the scope of your project to develop an application on the bleeding edge
of the OS. And some might argue that raw i/o for Linux/Unix is actually a
terrible hack, which may also be an issue to consider if this is
assessable work.
- James
--
James Morris
<[EMAIL PROTECTED]>
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
