Re: raw vs. cooked files under linux

On Wed, 11 May 2005 21:08:53 -0400, Data Goob <datagoob@netscape.net> wrote: >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?? > All it takes is for someone with the correct access to delete those "large" files out there to save space. >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 ) > Extra work? Not too much, that I know of . . . >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. > Sure, just backup the cooked files, right, Goob? Bad advice out of the box, dude. You'd lose all transactional integrity . . . . >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. :-) > Takes fewer Informix DBA to do the job. 8-)