Re: Database Usage of Unix FFS

murphyn_at_orca.cig.mot.com (Neal P. Murphy) writes:
>pete_at_tecc.co.uk (Pete Bentley) writes:
>
>>>>>>> lparsons_at_world.std.com (Lee E Parsons) writes:
 

>>For what you are doing, putting a few big files on a big disk, it is
>>tempting to suggest that a more traditional, SVR3-type filesystem
>>might be more efficient...allocate a really small number of inodes,
>>put all the files as few directories as possible and the SVR3 layout
>>policy means you can get all the files contiguous if you create them
>>on another f/s and tar or cpio them to their destination. Comments?
>
>For what Lee is doing, would he be better off using raw or block
>devices, completely bypassing the filesystem? I should think that
>eliminating a level of processing would enhance performance. With
>15 slices/partitions on a 1GB disk, he could get 75MB slices, on
>average.

Raw is probably the best option, one of the things I'm doing is trying to is understand the best way of laying down a large database on a cooked FS in order to see which is the best.

I may go through all this only to find that raw is the absolute winner (Well actually I expect that).

Right now I'm just having a problem listening to people make this raw -vs- cooked argument when I don't think we have actually set up the cooked FS in a reasonable manner. I'm hoping to take the suggestions this post generates and bench a raw fs with a cooked fs that has been tuned for a dbase environment.

-- 
Regards, 

Lee E. Parsons                  		
Systems Oracle DBA	 			lparsons_at_world.std.com