Re: raw vs. cooked files under linux

I guess almost all of us are convinced at this point of the performance improvement from using raw devices. But it would be great if we could get a benchmark report with a couple of Filesystems, specially on Linux, just in case we really need to use Filesystems. (JFS, Ext3, XFS , ReiserFS, ... ) I am a fan of XFS on Linux, because of its speed/stability/reliability against the other filesystems. I would be glad to see if XFS is better for database-OLTP performance or not. Could someone point us to a benchmark report of filesystems/raw devices ? Best Regards ----- Original Message ----- From: "Art S. Kagel" <kagel@bloomberg.net> To: <informix-list@iiug.org> Sent: Wednesday, May 11, 2005 1:30 PM Subject: Re: raw vs. cooked files under linux > Heinz Weitkamp wrote: > > Hi all, > > Go RAW all the way. Contrary to the Goob's understanding my own testing > shows RAW devices to be 15-25% faster than COOKED devices which are in turn > 10-15% faster than filesystem files, even on the best filesystem > implementations that adds up to a 25% improvement. Well worth any minor > inconveniences in my book. I have not yet tested Linux RAW devices versus > the various filesystems that Linux directly supports, but early reports when > Linux RAW devices were first rolled out showed similar results. The > performance gain was one reason why Linus Torvalds was convinced finally to > include RAW devices in Linux, a development he had resisted for years. The > other major reason being the need to provide high speed low level IO > capability to software like IDS that manages its own disk space. > > I also don't know why Data Goob thinks that you can backup cooked files or > devices for IDS any differently than you can raw devices. An archive taken > without using ontape or onbar is known as an 'external' archive. In all > three cases you can use ontape or onbar to perform online backups. In all > three cases if you want to produce an external archive successfully (read > "be able to restore the data later") you have to perform the archive while > the engine is not modifying the disk contents. That means one of three > scenarios 1, 2a, or 2b: > > 1) Shutdown the engine and use dd, tar, Legato Networker, or whatever to > copy the chunk files to tape/CD/DVD/whatever. > 2) Run onmode -c block to force a hard checkpoint and block the server from > modifying anything until you're backup is complete. Then you either: > a) Back up the chunks as in 1) or > b) Break mirrors, onmode -c unblock, backup the mirrors, recreate the > mirrors. > > UNDER NO CIRCUMSTANCES can you successfully archive the underlying chunk > files - whether they are RAW, COOKED, or files - while the IDS engine is > actively processing transactions! For an OLTP or OLTP-like server, you > could not reliably successfully restore the resulting archive. AN > unreliable archive is no archive at all! > > Sure if you're running a DW server and nothing's been modified in a week and > there was a recent hard checkpoint (or you forced one) you'll probably luck > out and get a usable external backup without blocking or shutting down the > engine. > > Art S. Kagel > > > i am an linux newbie. > > I must shift our Databases from SCO Unix (IDS 7.31 UD4) to SuSE Linux > > Enterprise Edition 8.1 (2.4.21-190-smp glibc 2.2.5) or (8.2) or 9 and SuSE > > Linux Professional 9.3 (2.6.11.4 glibc 2.3.4) (IDS 7.31 UD8). > > > > Later on i want to upgrade (in place) to IDS 10.0. > > Which Version of SuSE Linux Enterprise Edition must I use (8.? , 9 ..)? > > > > Under Sco Unix we use raw-devices. > > Is it better to use cooked files or raw files under these Linux-Versions? > > A colleague mentioned, it can be, that later releases of Linux don't support > > raw-devices. Is that correct? > > > > Experiences or comments are welcome. > > Thanks in advance. > > (Excuse my poor school-english) > > > > Heinz > > > > sending to informix-list sending to informix-list

You should try Google, a search engine on the internet. You can put phrases into it and results come back with page links to different web sites. This is but a partial listing for raw vs cooked files and some other similar phrases: http://fsbench.netnation.com/ Home of ReiserFS: http://www.namesys.com/ http://linuxgazette.net/102/piszcz.html http://www.linux-mag.com/2002-10/jfs_01.html http://www.yolinux.com/TUTORIALS/LinuxClustersAndFileSystems.html http://pgmeter.sourceforge.net/pgmeter.pdf http://kerneltrap.org/node/715 This one is really good: http://www.quest-pipelines.com/newsletter-v2/linux2.htm http://librenix.com/?inode=3495 What Legato thinks: http://www.nocoug.org/download/2003-02/ora_backup.ppt Francisco Roldan wrote: > I guess almost all of us are convinced at this point of the performance > improvement > from using raw devices. But it would be great if we could get a benchmark > report > with a couple of Filesystems, specially on Linux, just in case we really > need to use Filesystems. > (JFS, Ext3, XFS , ReiserFS, ... ) > I am a fan of XFS on Linux, because of its speed/stability/reliability > against the other > filesystems. I would be glad to see if XFS is better for database-OLTP > performance or not. > > Could someone point us to a benchmark report of filesystems/raw devices ? > > Best Regards > > ----- Original Message ----- > From: "Art S. Kagel" <kagel@bloomberg.net> > To: <informix-list@iiug.org> > Sent: Wednesday, May 11, 2005 1:30 PM > Subject: Re: raw vs. cooked files under linux > > > >>Heinz Weitkamp wrote: >> >>>Hi all, >> >>Go RAW all the way. Contrary to the Goob's understanding my own testing >>shows RAW devices to be 15-25% faster than COOKED devices which are in > > turn > >>10-15% faster than filesystem files, even on the best filesystem >>implementations that adds up to a 25% improvement. Well worth any minor >>inconveniences in my book. I have not yet tested Linux RAW devices versus >>the various filesystems that Linux directly supports, but early reports > > when > >>Linux RAW devices were first rolled out showed similar results. The >>performance gain was one reason why Linus Torvalds was convinced finally > > to > >>include RAW devices in Linux, a development he had resisted for years. > > The > >>other major reason being the need to provide high speed low level IO >>capability to software like IDS that manages its own disk space. >> >>I also don't know why Data Goob thinks that you can backup cooked files or >>devices for IDS any differently than you can raw devices. An archive > > taken > >> without using ontape or onbar is known as an 'external' archive. In all >>three cases you can use ontape or onbar to perform online backups. In all >>three cases if you want to produce an external archive successfully (read >>"be able to restore the data later") you have to perform the archive while >>the engine is not modifying the disk contents. That means one of three >>scenarios 1, 2a, or 2b: >> >>1) Shutdown the engine and use dd, tar, Legato Networker, or whatever to >>copy the chunk files to tape/CD/DVD/whatever. >>2) Run onmode -c block to force a hard checkpoint and block the server > > from > >>modifying anything until you're backup is complete. Then you either: >> a) Back up the chunks as in 1) or >> b) Break mirrors, onmode -c unblock, backup the mirrors, recreate the >>mirrors. >> >>UNDER NO CIRCUMSTANCES can you successfully archive the underlying chunk >>files - whether they are RAW, COOKED, or files - while the IDS engine is >>actively processing transactions! For an OLTP or OLTP-like server, you >>could not reliably successfully restore the resulting archive. AN >>unreliable archive is no archive at all! >> >>Sure if you're running a DW server and nothing's been modified in a week > > and > >>there was a recent hard checkpoint (or you forced one) you'll probably > > luck > >>out and get a usable external backup without blocking or shutting down the >>engine. >> >>Art S. Kagel >> >> >>>i am an linux newbie. >>>I must shift our Databases from SCO Unix (IDS 7.31 UD4) to SuSE Linux >>>Enterprise Edition 8.1 (2.4.21-190-smp glibc 2.2.5) or (8.2) or 9 and > > SuSE > >>>Linux Professional 9.3 (2.6.11.4 glibc 2.3.4) (IDS 7.31 UD8). >>> >>>Later on i want to upgrade (in place) to IDS 10.0. >>>Which Version of SuSE Linux Enterprise Edition must I use (8.? , 9 ..)? >>> >>>Under Sco Unix we use raw-devices. >>>Is it better to use cooked files or raw files under these > > Linux-Versions? > >>>A colleague mentioned, it can be, that later releases of Linux don't > > support > >>>raw-devices. Is that correct? >>> >>>Experiences or comments are welcome. >>>Thanks in advance. >>>(Excuse my poor school-english) >>> >>>Heinz >>> >>>sending to informix-list > > > sending to informix-list

Francisco Roldan wrote: > I guess almost all of us are convinced at this point of the performance > improvement > from using raw devices. But it would be great if we could get a benchmark > report > with a couple of Filesystems, specially on Linux, just in case we really > need to use Filesystems. > (JFS, Ext3, XFS , ReiserFS, ... ) > I am a fan of XFS on Linux, because of its speed/stability/reliability > against the other > filesystems. I would be glad to see if XFS is better for database-OLTP > performance or not. > > Could someone point us to a benchmark report of filesystems/raw devices ? > > Best Regards > A few years ago running IDS 9.1 on Solaris 7, I found that 2GB chunk initialize was 2 to 3 times slower on cooked vs raw chunks. Row Inserts on cooked chunks were at barely 50% of the speed compared to raw chunks. Currently we are testing a RAID-10 cooked configuration big chunks and it still appears slower than the old config with raw devices. However no test times for comparisons were actually recorded. (Just user complaints) Bob

Francisco Roldan wrote: > I guess almost all of us are convinced at this point of the performance > improvement > from using raw devices. But it would be great if we could get a benchmark > report > with a couple of Filesystems, specially on Linux, just in case we really > need to use Filesystems. > (JFS, Ext3, XFS , ReiserFS, ... ) > I am a fan of XFS on Linux, because of its speed/stability/reliability > against the other > filesystems. I would be glad to see if XFS is better for database-OLTP > performance or not. > > Could someone point us to a benchmark report of filesystems/raw devices ? Anyone doing this remember to test the COOKED devices and FS files using open with O_SYNC to force a physical write wait which is how IDS always performs non-RAW writes so that it knows the write was committed to the platters before acknowledging the IO as completed. Otherwise you are comparing disk IO speed with memory write speed and the results will not hold in production. Be careful of OS and SAN vendor benchmarks which compare RAW to uncommitted COOKED! This is just smoke and mirrors. Art S. Kagel > Best Regards > <SNIP>