raw vs. cooked files under linux

Hi all, 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

If you are in a slow-change environment raw-files are not a bad thing. They create extra problems on the management side that cooked files do not. Fast-changing environments create more demand on your time so why put yourself into extra work with raw files? They don't give you enough of a difference in performance to really warrant them unless you are really demanding that extra 10%. Cooked files are also also more flexible on backups, you can back the dbspaces up with a regular backup tool or use the Informix backup tools, but raw files will have to be backed up with Informix tools only. SLES9 is quite a sea change from SLES8, and you could probably get away without SLES and go with the workstation Pro 9.3 if you are on a budget. SLES has better support for SCSI than the workstation versions and you must buy support or the online update doesn't work. It's an enterprise lock-in you might not need so try before you buy. SLES9 can be downloaded for trial, so give it a spin. You should be able to download IDS 10 for trial as well, thus no out of pocket to try it before paying for it. Heinz Weitkamp wrote: > Hi all, > > 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

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

Art S. Kagel wrote: > 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. OK so you get some speed increases, but also the additional management of linking raw files. The original post indicated he was a newbie. Raw files are not necessarily difficult, but they ARE optional and not something I would entrust to a newbie. It's a great learning experience, but who's paying for it?? But another point to make is that in many SAN environments, raw files are a complete waste of time, with the data already being spread out over many drives, and, with speeds typically in the 10-15K rpm range, or even faster, you get speeds today on cooked files that are faster than raw was even a couple of years ago. Another point, if **YOU** are the one managing the system, do you want to create extra work for yourself, and extra risk if you don't have to or don't have the experience to work with them? In a lot of shops where ONE DBA is the rule, dear god, make sure you know what to do with raw systems before taking on the additional management. ( Your tips below illustrate the point ) Do you know what to do to restore? This will typically happen right as you were about to go on your vacation, so be prepared. Lastly, many environments change so rapidly that implementing raw disks can actually impede repurposing or modifying architectures at the pace necessary for the environment/business. To be sure you can argue all my points to the opposing view, but the bottom line is to do what is right for your environment and the best overall risk for you and your career. I would argue RAW is great if you can, but I'd argue more that it isn't worth the risk in most circumstances, even if you can. If you want to assume the risks, go for it, making doggone sure you do the backups, and perform an actual restore test to your satisfaction, something very few DBAs are willing to do. You will be quite surprised what your options are at restore-time, make sure you communicate them to management ahead of a disaster--you **will** be surprised what you can and cannot do if you never do a restore test--reading documentation and never restoring at least once is begging the boss to fire you for incompetence. Of course with the almost zero number of Informix people available to replace you, your job is probably pretty secure even if you screw it up. :-) 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. Certainly doable for a noob. :-) I learn something new every day, but this is not for newbies. Even experienced people will be challenged, especially if they don't do this every day. Knowing the current IT market and the talent pool you will not find many people who can do this, or would want to, thusly, they will opt for cooked--it's easier on the blood pressure and the family. > > 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