Re: HP/UX to Linux - raw space setup question

On Wed, Nov 10, 2010 at 12:20 PM, Art Kagel <art.kagel@gmail.com> wrote: > The developer of the Linux RAW module still maintains it and it is a viable > option. However, following Linus Torvald's lead, Red Hat has deprecated RAW > (as was already mentioned). Linus never wanted RAW devices included in > Linux and has always opposed it on philosophical bases. This is from an > email Linus sent on the subject in 1996 (before the RAW module was > released): "The main reason there are no raw devices is that I personally > think that raw devices are a stupid idea ...there are old-fashioned > databases that think they can do a better job of it than the kernel does. > They are usually wrong". Linus just doesn't get it and now he is on a > campaign to eradicate RAW from all Linux releases. So far, AFAIK, he has > only been successful in convincing RH to drop them, but you can get the > module separately and include it yourself if you want. > > On using other options: > > - Block devices go through the cache unless DIRECT_IO is enabled. I do > not know if DIRECT_IO works with block devices on Linux. They will not work > together on AIX for example. > - Filesystem files - > - With DIRECT_IO enabled and KAIO configured correctly (so you have > to tune the Linux KAIO resources) filesystems are about 5-8% slower than RAW > on Linux. Without DIRECT_IO filessystem chunks are about 30-35% slower than > RAW. > - You should NEVER use ANY journaled filesystems for database > chunks. That means no EXT3 or EXT4 filesystems on Linux, no ZFS on Linux or > Solaris, only EXT2 filesystems should be used on Linux for database chunks. > AIX's JFS2 (and the equivalent open source JFS filesystem) is less > problematic since it only journals meta-data and not data pages. Fully > journaling filesystems do not overwrite data pages but instead write a new > page to replace it logically in the file and unlink the original version > releasing it to freespace. This results in files that are massively > fragmented internally and, since databases rewrite the same pages many times > a day, results in a serious increase in IO and disk bandwidth requirements. > Also, journaled filesystem meta-data writes are NOT affected by O_SYNC or > O_DIRECT, so they are still cached even though the database is forcing a > data flush - yet another chance for file corruption. - see my Journaled > Filesystem Rant in the July entry on my blog ( > www.informix-myview.blogspot.com) for more details. > - BTW, Linus says that EXT4 was "designed by idiots" and it is not > safe (it writes out the meta-data indicating the new location of a modified > page BEFORE it actually writes out the new version of the data resulting in > a hole in the file if the system crashes). I don't know if the problems > have been fixed recently, but caviat emptor. EXT3 with write-back enabled > has similar safety problems (EXT4's write-back mode is the default and > cannot be disabled - that's another main problem). > > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > IIUG Board of Directors (art@iiug.org) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, implicitly, > or by inference. Neither do those opinions reflect those of other > individuals affiliated with any entity with which I am affiliated nor those > of the entities themselves. > Informix supports KAIO on block devices on Linux since v10: http://www.ibm.com/developerworks/data/library/techarticle/dm-0503szabo/ So, block devices may be a good compromise between ease of use, supportability and performance. File system is the best for usability, but still has some performance impact. "Pure" raw devices aren't properly supported (whether Linus is right or not - and I believe he's not -) and are harder to setup. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...