Re: The old raw devices chestnut.

Mark Bole wrote:
>
> Gawd, this cross-posting is a little scary...

Not wrong :) but we're being very well-behaved so far. I did see one slur against Sybase's market position, but they've been patient and I thank them for that. We still love you, folks... I was a big fan of Watcom 15 years ago, and i believe it's the spiritual ancestor of Sybase and MS? Sybase split from the Evil Empire, so that's a point in their favour, and in some simple play with MS SQL, it looks like fun... Has that buttered up enough people to keep things happy?

> I've touched DB2,
> administered Sybase for four years in the mid-nineties, otherwise
> Oracle is it... so take the following for whatever it's worth.
>
> To answer the question above: no, actually my experiences with Oracle
> raw devices were under DEC Ultrix, SGI Irix, and HP-UX. I've only
> managed "normal" filesystems under Solaris, Linux, and Windows. To
> this day the thought of messing with the /dev filesystem stresses me
> out... --)

True. If you MUST move a lump of data, which the engine thinks is called /dev/rdk0101, then there's no way that can be renamed on many O/S due to naming conventions. I got stuck with that several years ago. I actually cheated and broke the O/S naming convention just to get things working. That was an object lesson. However, common wisdom in the Informix world (probably discovered 1000 times by different people) is to use symbolic links. Personally I use something like /DBCHUNKS/enginename/lump01 -> /dev/blahblah and then the engine can always use the logical name; the physical space will be wherever it's pointed.

> Yes, I've had to recover production (Oracle, Sybase) systems in real
> life disaster situations: Score: raw filesystems, W-1, L-1. cooked
> filesystems, W-2, L-0. So you can see where I'm heading...

OK - that's a warning from experience on them engines. OP take note. We have a bunch of Oracle admins in this company, and I don't believe they use raw spaces either. I don't know how they do backups either; I really should lurn from them, but never quite get 'round to it.

> I use "adminstration" in a very tool-oriented sense. With cooked file
> systems (which I am defining as filesystems the OS is designed for...
> tautology or no...), there are lots of tools: tools for timestamps,
> tools for sizes, tools for checksums, tools for copying, tools for
> finding, tools for checking open handles, and so on. With raw
> filesystems, I have none of these tools. (OK, wrong if you consider
> "dd" under Unix to be a tool....)

ok - I've heard that Oracle has a "variety" of backup procedures, some of them home-cooked, some of them tools you have to pay for. In that case, you would need suitable tools to manage the objects. With Informix, it's shipped with one (now two) tools that perform complete, live, point-in-time archives along with continuous storage of logical logs. Any timestamps etc that need touching are self-contained within the engine spaces, so it's completely unnecessary and almost certainly destructive to do anything with informix spaces apart from via the utilities provided.

By the way, you can still perform something like

cksum < /dev/rawspace

or

dd if=/dev/rawspace bs=64k count=XXXk | cksum

and so on. Raw devices on unix are still just files. They are just not appropriate to use without some smart access algorithms, such as might be found in database engines... Sure, dd is a wierd utility that doesn't match typical unix command line syntax, but it can still move "files" around. Not that I ever need to do that.

Haven't heard any opinions from a DB/2 bod yet.

> Your own example serves to make my point: the set of admins, naive or
> otherwise, who stand a chance of disaster recovery with raw
> filesystems in the 21st century is an order of magnitude less than
> those who stand a chance of disaster recovery with "normal"
> filesystems.

By the same token, a dumb-**** naive sysadmin could easily destroy cooked files in their desperate and thoughtless search for more space. An inexperienced but over-confident admin is a dangerous creature no matter what product they are near. I don't think anyone could do a recovery using the cleaning tapes I mentioned in another reply. Murphy's law at work there.

> And just to put the skin on the pudding, isn't the stated direction of
> MSFT to turn the entire filesystem into a database? Whither raw
> partitions then?

MSFT? ?? Micro Soft Something Something? Not interested !:) UNIX and Linux suits me, our application and our customers well. Good luck to Microsoft with their FT, whatever that might be.

I'm waiting for any Informix users to contradict me about always using raw with Informix. When the subject comes up over in c.d.i, we get 3 counter-responses. One is the "complicated" argument. One is about certain platforms which contain system calls and filesystems which are specifically tailored for write-through and no buffering. I've seen Solaris has a filesystem option to apply that on the entire file system. On such a machine, you'd only have to ensure contiguity, and to keep other peoples dirty hands out of your spaces. The third counter argument to raw is large high performance storage boxes - good luck to you if your customers or site can afford them. I think a few of our customers should be using them, but aren't.

I think a history and principles of raw space on UNIX is worth posting, so the OP can make his/her own decisions... [looks - ok, him, Jim] That will have to wait a few hours, and be yet another oversized posting :-) There are many interesting points and developments along the way, not to mention big fast storage boxes. Received on Tue Apr 13 2004 - 23:54:49 CDT