>
> Raw devices per se are already deprecated. They are now merely
I know, but it don't work properly yet (not on all platforms). Anyway it is
well known improvement.

> You probably want to use ASMLib, though. Even if you are using
> block device names ("/dev/sdb1", etc), you still have to manage all
> device naming and permissions. This is frustrating enough on one node,
I disagree. Oracle user have 'disk' permissions so it have access to all
disks. ASM by itself is
Volume Manager which take care of disk recognizion etc. All I must do in
case, for example, iSCSI and SLES9, is
to allow ASM to see /dev/disk/by-id/* disks. Another way is _100% primitive_
script just doing symlinks or 'using udev'.

Managing disk permissions can be a minor problem (if you wnat to separate
oracle from all disks except ASM enable ones, which is not common task
because most Orazcle serevrs are 100% oracle dedicated ones), but it don't
require KERNEL MODULE -
using small script with 'ln -s' inside can be more than enough, Then, this
task (manage disks) is one-time task - it happen only when you
add/delete tasks - once/year in real life.

So I don't see ANY management benefits from ASMLibrary but only problems
caused by one more third-party module in the kernel.

I could agree with ASMLibrary IF:
- it provides virtual file system in the kernel;
    OR
- if it was outside of the kernel.

For now, it is just one more layer doing virtually nothing and complicating
system management. As I said already, there is not any problem in
disk permission management and it's always 100% simple to add (if necessary)
one more directory and script to post all required disks to the ASM. And of
cource no one sysadmin in a good health use /dev/sd* - we do use /dev/disk/*
disks instead for a few years (already) with persistent names, and new
Linuxes with enforced multipath makes it even more necessary for us.

> but a real pain across a cluster. As you probably know already, ASMLib
As I already know, ASMLib DON'T make this tasks easier. Adding the whole
kernel layer just to maintain permissions and extra 8K buffer(s) for a few
disks is not a right thing to do in Linux.

What I'd like to see instead:
- ASMLibrary 100% outside of the kernel;
- ASMLibrary have commands such as:
 - ASMfsck
 - ASMcmd with 'cp, mv, rm, find' commands inside (not as now);
 _ ASMrepair command allows off-line (without SM instance up) access to
the data on the disk;
 - ASMdisk command with disable, enable, makefail, makespare, rebuild
options;
 - ASMdf command (all outside of the kernel).
Then, I agree, it could be a good improvement to the ASM.

And here (this thread) is a very good example why it is always BAD to add
kernel module(s) without urgent need in it. Linux kernel is too complicated
and fragile thing to allow asmlibrary be running inside it.

In addition, again, I told with ASM Library designers on a few Oracle
forums.I can be wrong, but I got imporession that ASM Library was designed
for the cluster primarily, and was never completed (so it is not doing tasks
it was designed for). As a result, it is really useless, and the best we can
do as a system administrators is to remove it from the system.


--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting