Re: Raw Devices: Increased Performance?

In article <838041693.27945.0_at_gate.norwich-union.com>, M1069B00@?.? writes
>
>What about SVM???
>
>Having read this thread with interest (we use raw devices with ptx/SVM),
>the basic argument is that filesystems are better than raw devices if using
>OFA because :-
>
>* inodes are not a real overhead because they are in memory and commonly used
> indirect blocks are cached as filesystem blocks.
>

   Yes - sorry my brain rather overloaded with ideas against filesystems    on my last post and I got a bit carried away.

>* UNIX kernel uses elevator algorithm for data access on filesystems as opposed
> to the come first served algorithm inherent in raw device I/O.
>
 

   Generally disk drive controllers themselves which have the elevator    seek algorithm built-in to them, also the database engine has this    built-in as well. Why waste time doing it an extra time ?
>* In OFA you are spreading the datafiles across the disk bank and so thinning
> the load on any single controller (on average).
>

    Also fragmentation/ creation of tables within 'dbspaces' collections     of chunks of raw disk) allows spreading of databases/tables across     disks. This gives a clearer indication of disk layout to the     database engine (since raw device are continguous across the disk).

>This is comparing UNIX disk / filesystem algorithms versus raw devices as-is.
>(i.e. using basic character I/O control)
>But in the case of Sequent systems using ptx/SVM is it not a different issue?
>

    Running an Informix Online v7 database against a raw device provides     all of the benefits without a Device manager Layer.   

    Also OnLine has a better knowledge of where the table is stored when     doing read-ahead (if the table is not contiguous across the disk     then an operating system doing sequential read ahead may well read     areas of the disk which are then not used). Using a raw disk     overcomes this problem.

    How can the UNIX disk/filesystem algorithms be better when all they     see is a large file rather then the layout of tables/indices?

    Also the database engine can schedule high priority disk I/O e.g.     transaction log I/O ahead of say a search on a table.

>Raw device (/dev/rvol/,,,) read and writes go through the ptx/SVM layer
>which I thought introduced the same kinds of I/O optimizers as the filesystem
>(e.g. the elevator algorithm).
>It implements striping, and also balances the I/O load between mirrored copies
>(i.e. goes to the least busy side of the mirror for read requests).
>

   OnLIne also can implement striping (via table fragmentation) and    balances I/O load between mirrored copies using Informix mirroring.

>Is it not the case that raw volumes and raw volumes under SVM are very different
>in their performance capabilities?
>What about a new comparison based on the SVM enhanced raw volume?
>
>The post that spoke of a customer considering Oracle Parallel Server would
>clearly be referring to a system with SVM, but the arguments being made are
>not accounting for SVM, just dumb raw devices using basic stream I/O control.
>

  The database engine using raw devices should be faster then using   filesystems given that the filesystem code becomes just extra 'less   intelligent' layer sitting between the database engine and the disk   when using filesystems.

>Clarification from a guru requested please ...
>
>Regards, Steve Woolston. (woolsts_at_norwich_union.co.uk)

  Sorry it's been so long since my last post but I've had flu and have   just recovered. Also sorry if this sounds like an advert for Informix   but it's database engine I know the best. What do you mean Oracle   doesn't do all of the above? ;-> Answers on an e-mail please.

-- 
David Williams