Oracle ASMLib: Physical and Logical Blocksize

This article is about the use of Advanced Format devices on Oracle’s ASMLib kernel library for Linux. For background, read this page on 4k sector sizes first, otherwise it might all sound like nonsense. Mind you, it mind sound like nonsense anyway, I can’t guarantee anything here. By the way, a big hello to my buddy Nate who asked for this information: you rock, dude.

In more recent versions of ASMLib, Oracle introduced a new parameter into the /etc/sysconfig/oracleasm file:

[root@half-server4 mapper]# tail -5 /etc/sysconfig/oracleasm
# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'

To understand what this parameter does, consider this device which I am presenting from a Violin array:

[root@half-server4 ~]# ls -l /dev/mapper/testlun
lrwxrwxrwx 1 root root 8 Feb 27 15:33 /dev/mapper/testlun -> ../dm-19
[root@half-server4 ~]# fdisk -l /dev/mapper/testlun

Disk /dev/mapper/testlun: 34.4 GB, 34359738368 bytes
255 heads, 63 sectors/track, 4177 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 524288 bytes

The important bit there is highlighted in red. This device has a 4k physical blocksize (as all Violin devices do, as well as many other modern storage systems) but has a 512 byte logical blocksize. Essentially, this LUN is pretending to be a 512 byte based.

Now that’s all well and good. Operating systems and applications that cannot support 4k block sizes (e.g. Red Hat 5 and Oracle Linux 5) will happily use this, because they believe it to be 512 byte. But later versions of ASMLib have started being too clever for their own good.

Don’t Look Behind The Curtain

Let’s create an ASMLib label on this device:

root@half-server4 ~]# oracleasm createdisk TESTLUN /dev/mapper/testlun 
Writing disk header: done
Instantiating disk: done

And now we can attempt to put an ASM diskgroup on it:

     'compatible.asm' = '11.2',
     'compatible.rdbms' = '11.2';  
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15038: disk '' mismatch on 'Sector Size' with target disk group [4096]

What happened? Well, ASMLib has looked behind the smoke and mirrors and decided that this is actually a 4k device. It’s therefore presenting this to Oracle ASM as 4k, which causes the problem (because I explicitly asked for sector size to be 512 byte on this diskgroup).

One possible solution is to change the ASM_DISKSTRING from it’s default value of NULL (meaning ‘ORCL:*’) to ‘/dev/oracleasm/disks/*’, i.e. the location where ASMLib creates its own block devices. We can test this theory with fdisk:

[oracle@half-server4 ~]$ ls -l /dev/oracleasm/disks/TESTLUN 
brw-rw---- 1 oracle dba 252, 19 Feb 27 15:38 /dev/oracleasm/disks/TESTLUN
[oracle@half-server4 ~]$ fdisk -l /dev/oracleasm/disks/TESTLUN | grep "Sector size"
Sector size (logical/physical): 512 bytes / 4096 bytes

So that would work. But it would lose many of the claimed benefits of ASMLib such as reduced file descriptors and context switching. Also, it feels like a hack.


The answer, as you probably guessed, is to set this new parameter. It defaults, wrongly in my opinion, to using the physical block size. We can either edit the value in the file to be true in order to use the logical blocksize, or preferably use the oracleasm configure command:

root@half-server4 ~]# oracleasm configure -b
Writing Oracle ASM library driver configuration: done
[root@half-server4 ~]# oracleasm configure | grep ORACLEASM_USE_LOGICAL_BLOCK_SIZE

It can be set back to using the physical blocksize with the following command:

[root@half-server4 ~]# oracleasm configure -p
Writing Oracle ASM library driver configuration: done
[root@half-server4 ~]# oracleasm configure | grep ORACLEASM_USE_LOGICAL_BLOCK_SIZE

Finally, a word of warning. If you are like me, then you are a bit stupid and can’t follow instructions properly. I set the value of the parameter to TRUE in upper case and then spent hours wondering why it didn’t work. The answer, to my embarrassment, is that it’s case sensitive. TRUE is not a valid value so it defaults to false. Doh.


13 Responses to Oracle ASMLib: Physical and Logical Blocksize

  1. Freek D'Hooge says:


    Is the link to the 4K sector size page correct?
    it seems to point to a general asmlib page from oracle.



  2. wgray611 says:

    Can this parameter be switched without corrupting data in existing disk groups?

    • flashdba says:

      I would expect it to cause significant issues if you changed it for preexisting ASM devices.

      • Abraham says:

        Just to clarify:
        If a disk group called +DISKG1 is already working with 512 (logical size)/512 disks (physical size) disks configured with parameter ORACLEASM_USE_LOGICAL_BLOCK_SIZE=”false” and then ORACLEASM_USE_LOGICAL_BLOCK_SIZE is changed to true, could the disk group data +DISKG1 be corrupted?

        • flashdba says:

          I can’t see any way in which the disk group could be corrupted. As worst, it might make it impossible for ASM to mount the diskgroup and then you’d have to change ORACLEASM_USE_LOGICAL_BLOCK_SIZE back to false, but I can’t think of a circumstance in which you would actually lose data.

          Note: I do not accept responsibility for any consequences! 🙂

  3. wgray611 says:

    That is what I was expecting. Thank you FlashDBA ^_^

  4. Anil says:

    Hi there

    I have a question you may know the answer to?

    If we present the 4k sector disks as 512 logical size to ASM, can the disks be added to an existing diskgroup based on 512 sector size? If so, would there be any detriment?

    Would highy appreciate your response.


    • flashdba says:

      From memory, I believe that Oracle checks the physical block size of the devices you present to ASM. Thus, even if you present your 4k LUNs as 512e, Oracle will know that they are 4096 byte physical sector size and refuse to add them to an existing 512 byte diskgroup.

      Also, while I haven’t asked them, I am pretty sure that my friends in the Oracle ASM product management team would advise against mixing different sector size volumes within a diskgroup. I’m almost certain that Oracle won’t be testing this particular scenario – and you do not want to be heading down the route of implementing an untested, uncertified and potentially unsupported configuration with ASM. After all, the consequences could be pretty severe – like the loss of your data!

  5. Anil says:

    Thanks for the prompt reply!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: