> I think you got the terminology shifted. In linux speak you can put your DB on > - a file > - a block device > - a set of raw devices > To confuse us more, some people refer to the 2nd option as "raw > partitions" LVM operates in that 2nd layer.
It is likely that you and I are in violent agreement. Perhaps I should simply have not used the term "raw". I only meant bypassing the filesystem layer. Bypassing the block layer is a whole nutha thing. I have been doing Unix since before Linux existed. In traditional Unix speak, block mode and "raw" mode are handled by the same major/minor numbers but making it a block mode special or character mode special. This is inode magic. Linux doesn't have that feature. Oracle doing true raw on Linux must be going through some funky ioctl() call. (Someone please enlighten me if this is not correct. No such thing as "character" disks.) Now is the time when I should crack the source to LIBAIO. Both DB2/UDB and Oracle seem to have a fondness for it. LVM is just a way of managing blocks. PVs (input) consist of blocks; LVs (output) consist of blocks. Bypassing Linux block cache would be a different flag to set, and would need to be applied to the LV and to all PVs backing it. How much overhead with LVM? Dunno. Less than for a filesystem, I guess, ... but that is just a guess. In any case, LIBAIO may help here too. If Oracle (or DB2/UDB) wants to manage its own content, the fight is between Oracle and the customers (eg: sysadmins). So ... which is easier? Enlarge a volume? (either LV or physical device) -or- slap another dev on there and let Oracle handle it? We could go around the mountain several times discussing that one. (Not today, please!) -- R; <>< On Tue, Jan 26, 2010 at 08:00, Rob van der Heij <rvdh...@gmail.com> wrote: > On Tue, Jan 26, 2010 at 1:29 PM, Richard Troth <vmcow...@gmail.com> wrote: >> Rob -- >> >> Some might let Oracle have one large "raw" LV instead of putting a >> filesystem on it (instead of giving Oracle plain files). So LVM would >> still be in scope even though filesystems not. > > I think you got the terminology shifted. In linux speak you can put your DB on > - a file > - a block device > - a set of raw devices > To confuse us more, some people refer to the 2nd option as "raw > partitions" LVM operates in that 2nd layer. > > The 3rd case is what I would prefer. It bypasses the block device > layer in Linux (they show to Oracle as character devices). The > intention is that you avoid the overhead of the Linux block device > layer and associated page cache (assuming Oracle can do a better job > in predicting its own actions than the Linux cache algorithms can > guess). > >> LVM is the way to go for managing storage spaces. You can grow an LV >> much more easily than a PV. (For some values of PV, growth means >> physical drive swap.) > > For file systems, indeed. But when the database can manage its own > disks, that might be an advantage. > > Rob > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
