RE: raw vs. cooked files under linux

We use raw chunks on all our unix versions. Most are Linux. We find it easier to set up and manage raw devices, including under Linux. We also have a SAN environment running RAW devices under Linux - no problems at all. We have not had any issues and that includes recovering systems. Its all very simple when using RAW devices. MW > -----Original Message----- > From: owner-informix-list@iiug.org > [mailto:owner-informix-list@iiug.org] On Behalf Of Data Goob > Sent: Thursday, 12 May 2005 1:09 p.m. > To: informix-list@iiug.org > Subject: Re: raw vs. cooked files under linux > > 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 > > > sending to informix-list