ASM 3——實現ASM磁碟的兩種方式：asmlib、udev
1、asmlib的介紹
ASMLib的是Oracle資料庫10g及以上版本的自動儲存管理功能的支援庫。 Oracle提供了該庫的Linux的具體實現。關於asmlib程式的介紹，可以參考如下文件：
http://blog.csdn.net/cymm_liu/article/details/7908962
從以上文件我們瞭解到，對於asmlib，常規情況下只是在單條路徑下使用，那麼，現在我們可以討論下，在多路徑的前提下，能否使用asmlib呢？
關於多路徑的簡介，參考文件：http://blog.csdn.net/cymm_liu/article/details/7927984
涉及多路徑磁碟的問題 ：使用ASM中的多徑磁碟有兩個問題。 ASM不能兩次看到了同樣的磁碟的處理。如果是這樣，它會導致錯誤。一個磁碟可以出現在一個多路徑配置三次： 1、第一條路徑到磁碟 2、第二條路徑到磁碟 3、多路訪問點
下面是一個例子：
系統有一個本地磁碟/dev/sda，和一個磁碟通過連線外部儲存。該機具有兩個連線或路徑到外部儲存。 Linux的SCSI驅動程式，會看到兩個路徑。他們將顯示為/dev/sdb和/dev/sdc的。系統可能會訪問sdb或sdc，訪問結束在同一個地方。
果啟用了多路徑，將有一個多路徑磁碟，例如/ dev/ multipatha，可以訪問兩個路徑。也就是說，所有的I / O去訪問multipatha這個磁碟可以使用兩條路徑。如果系統使用sdb這條路徑，並且這條線路被拔掉時，系統會得到一個錯誤。但多路徑磁碟會知道切換到sdc路徑。
大多數系統軟體並不知道的多路徑的配置。所以這些軟體可以使用任何路徑：sdb、sdc或multipatha，而且也不會知道其中的差別。 ASMLib程式也是這樣，預設的配置情況下，並不會去關心具體使用哪條路徑。只是提供了一個庫檔案。關於asmlib的作用，可以參考這篇文件：
ASMLib程式將只選擇的路徑之一，因為ASM無法處理兩次看到了同樣的磁碟。這就解決了第一個問題。 ASM只能看到一個路徑，這就比較好了。
但是，又有一個問題：ASM看到哪條路徑？ 在預設配置的情況下，ASMLib程式會選擇它找到的第一個路徑。這是由Linux 作業系統所報告的第一條路徑。這就會取決於儲存驅動程式，它可能是/dev/sdb，也可能是/dev/sdc/、還有可能是/dev/multipatha。。。
The system administrator wants ASMLib to always use the multipath disk. What's the point of having it if Oracle is not using it? There is no way, however, for ASMLib to know what a multipath looks like. It must be told via its configuration.
Disk掃描排序
ASMLib程式安裝後，磁碟被一個程序標記為專門供ASMlib使用的。在磁碟掃描程序執行的過程中，ASMLib會學習哪個磁碟可以被標記為供asmlib使用的。asmlib每次啟動的時候都會執行這個磁碟掃描程序，掃描所有的磁碟，來標記（或者檢查已被標記的）到底哪個磁碟可以被asmlib使用。系統管理員也可以手工執行磁碟掃描命令:/etc/init.d/oracleasm scandisks 強制掃描。 ASMLib程式檢查每個磁碟作業系統列出他們的確切順序。對於大多數系統來說，這是很好的。
在最後一節中，我們描述了一個情況：作業系統的順序是不夠好。系統管理員希望ASMLib看到單一路徑磁碟之前，先看到多路徑磁碟。這允許asmlib選擇多路徑磁碟，並提供給Oracle使用。
ASMLib程式允許兩個磁碟掃描順序的修改。首先，它允許排除某些磁碟。換句話說，ASMLib程式將完全忽略這些磁碟。其次，系統管理員可以指定首先要掃描的磁碟。在此列表中的磁碟先被掃描，其他不在此列表中的磁碟後被掃描。一個多路徑配置，可以用起來非常方便。系統管理員可以選擇排除所有的單一路徑磁碟， ASMLib程式將忽略他們，只掃描多路徑磁碟。相反，管理員可以指定多路徑磁碟掃描第一，的ASMLib將首先看到他們，在但路徑之前。
配置掃描的順序
配置檔案包含了許多的配置變數。 ORACLEASM_SCANORDER變數指定要掃描的磁碟的順序。 ORACLEASM_SCANEXCLUDE變數指定的磁碟將被忽略（不被掃描）。
The variables take a whitespace-seperated list of prefix strings to match。換句話說，如果一個磁碟開始的字首字元與配置檔案裡的匹配。例如，字首字串sd將匹配所有的SCSI裝置。磁碟sda開始與sd。請注意，他們不使用萬用字元。他們是簡單的字首，還要注意的是/dev/路徑並不是字首的一部分。
NOTE: When scanning, only the device names known by the kernel are scanned. With device-mapper, the kernel sees the devices as /dev/dm-XX. The /dev/mapper/XXX names are created by udev for human readability. Any configuration of ORACLEASM_SCANORDER orORACLEASM_SCANEXCLUDE must use the dm prefix.
A couple examples:
NOTE: If you are hand editing file /etc/sysconfig/oracleasm, make sure the link to /etc/sysconfig/oracleasm-_dev_oracleasm is not broken.
- Multipath Disks First
The system administrator configures ASMLib to scan the multipath disks first. In the ASMLib configuration file she edits the ORACLEASM_SCANORDER variable to look like so:
ORACLEASM_SCANORDER="multipath sd"
- Excluding Single Path Disks
The system administrator configures ASMLib to ignore the single path disks. In the ASMLib configuration, he edits the ORACLEASM_SCANEXCLUDE variable to look like so:
ORACLEASM_SCANEXCLUDE="sdb sdc"
2、udev簡單介紹
下面通過問答的形式，把udev的概念描述清楚：
問：udev是什麼? 它的目的何在?
答：udev是一種工具，它能夠根據系統中的硬體裝置的狀態動態更新裝置檔案，包括裝置檔案的建立，刪除等。裝置檔案通常放在/dev目錄下。使用udev後，在/dev目錄下就只包含系統中真正存在的裝置。
問：udev支援什麼核心？
答：udev只支援linux-2.6核心，因為udev嚴重依賴於sysfs檔案系統提供的資訊，而sysfs檔案系統只在linux-2.6核心中才有。
問：udev是一個核心程式還是使用者程式？
答：udev是一個使用者程式(user-mode daemon)。
問：udev和devfs有什麼差別？
答：udev能夠實現所有devfs實現的功能。但udev執行在使用者模式中，而devfs執行在核心模式中。據稱：devfs具有一些不太容易解決的先天缺陷。
問：udev的配置檔案放在哪裡？
答：udev是一個使用者模式程式。它的配置檔案是/etc/udev/udev.conf。這個檔案一般預設有這樣幾項：
udev_root=”/dev” ; udev產生的裝置檔案的根目錄是/dev
udev_db=”/dev/.udevdb” ; 通過udev產生的裝置檔案形成的資料庫
udev_rules=”/etc/udev/rules.d” ;用於指導udev工作的規則所在目錄。
udev_log=”err” ;當出現錯誤時，用syslog記錄錯誤資訊。
問：udev的工作過程是怎樣的？
答：由於沒有研究過udev的源程式，不敢貿然就說udev的工作過程。我只是通過一些網上的資料和udev的說明文件，大致猜測它的工作過程可能是這樣的：
當核心檢測到在系統中出現了新裝置後，核心會在sysfs檔案系統中為該新裝置生成一項新的記錄，一般sysfs檔案系統會被mount到/sys目錄中。新記錄是以一個或多個檔案或目錄的方式來表示。每個檔案都包含有特定的資訊。(資訊是如何表述的，還要另外研究？)
udev在系統中是以守護程序的方式udevd在執行，它通過某種途徑(到底什麼途徑，目前還沒搞懂。)檢測到新裝置的出現，通過查詢裝置對應的sysfs中的記錄得到裝置的一些資訊。udev會根據/etc/udev/udev.conf檔案中的udev_rules指定的目錄，逐個檢查該目錄下的檔案，這個目錄下的檔案都是針對某類或某個裝置應該施行什麼措施的規則檔案。udev讀取檔案是按照檔名的ASCII字母順序來讀取的，如果udev一旦找到了與新加入的裝置匹配的規則，udev就會根據規則定義的措施對新裝置進行配置。同時不再讀後續的規則檔案。
問：udev的規則檔案的語法是怎樣的？
答：udev的規則檔案以行為單位，以”#”開頭的行代表註釋行。其餘的每一行代表一個規則。每個規則分成一個或多個“匹配”和“賦值”部分。“匹配”部分用“匹配“專用的關鍵字來表示，相應的“賦值”部分用“賦值”專用的關鍵字來表示。“匹配”關鍵字包括：ACTION，KERNEL，BUS，SYSFS等等，“賦值”關鍵字包括：NAME，SYMLINK，OWNER等等。具體詳細的描述可以閱讀udev的man文件。
下面舉個例子來說明一下，有這樣一條規則：SUBSYSTEM==”net”, ACTION==”add”, SYSFS{address}==”00:0d:87:f6:59:f3″, IMPORT=”/sbin/rename_netiface %k eth0″
這個規則中的“匹配”部分有三項，分別是SUBSYSTEM，ACTION和SYSFS。而”賦值”部分有一項，是IMPORT。這個規則就是說，當系統中出現的新硬體屬於net子系統範疇，系統對該硬體採取的動作是加入這個硬體，且這個硬體在SYSFS檔案系統中的“address”資訊等於“00：0d…”時，對這個硬體在udev層次施行的動作是呼叫外部程式/sbin/rename_netiface，傳遞的引數有兩個，一個是“%k”，代表核心對該新裝置定義的名稱。另一個是”eth0“。 從上面這個例子中可以看出，udev的規則的寫法比較靈活的，尤其在“匹配”部分中，可以通過諸如”*“, ”?“,[a-c],[1-9]等shell萬用字元來靈活匹配多個匹配項。具體的語法可以參考udev的man文件。
問：udev怎樣做到不管裝置連線的順序而維持一個統一的裝置名？
答：實際上，udev是通過對核心產生的裝置名增加別名的方式來達到上述目的的。前面說過，udev是使用者模式程式，不會更改核心的行為。因此，核心依然會我行我素地產生裝置名如sda,sdb等。但是，udev可以根據裝置的其他資訊如匯流排（bus），生產商（vendor）等不同來區分不同的裝置，併產生裝置檔案。udev只要為這個裝置檔案取一個固定的檔名就可以解決這個問題。在後續對裝置的操作中，只要引用新的裝置名就可以了。但為了保證最大限度的相容，一般來說，新裝置名總是作為一個對核心自動產生的裝置名的符號連結（link）來使用的。
例如：核心產生了sda裝置名，而根據資訊，這個裝置對應於是我的內建硬碟，那我就可以制定udev規則，讓udev除了產生/dev/sda裝置檔案外，另外建立一個符號連結叫/dev/internalHD。這樣，我在fstab檔案中，就可以用/dev/internalHD來代替原來的/dev/sda了。下次，由於某些原因，這個硬碟在核心中變成了sdb裝置名了，那也不用著急，udev還會自動產生/dev/internalHD這個連結，並指向正確的/dev/sdb裝置。所有其他的檔案像fstab等都不用修改。
問：怎樣才能找到這些裝置資訊，並把他們放到udev的規則檔案中來匹配呢？
答：這個問題比較難，網上資料不多，我只找到一篇文章來介紹如何寫udev的規則。他的基本方法是通過udevinfo這個實用程式來找到那些可以作為規則檔案裡的匹配項的專案。有這樣兩種情況可以使用這個工具：
第一種情況是，當你把裝置插入系統後，系統為裝置產生了裝置名（如/dev/sda）。那樣的
話，你先用udevinfo -q path -n/dev/sda，命令會產生一個該裝置名對應的在sysfs下的路徑，如/block/sda。然後，你再用udevinfo -a -p/sys/block/sda，這個命令會顯示一堆資訊，資訊分成很多塊。這些資訊實際來自於作業系統維護的sysfs連結串列，不同的塊對應不同的路徑。你就可以用這些資訊來作為udev規則檔案中的匹配項。但需要注意的是，同一個規則只能使用同一塊中顯示的資訊，不能跨塊書寫規則。
第二種情況是，不知道系統產生的裝置名，那就只有到/sys目錄下去逐個目錄查找了，反覆用udevinfo -a -p/sys/path…這個命令看資訊，如果對應的資訊是這個裝置的，那就恭喜你。否則就再換個目錄。當然，在這種情況下，成功的可能性比較小。
問: udev和devfs是什麼關係
答: udev完全在使用者態(userspace)工作，利用裝置加入或移除時核心所傳送的hotplug事件(event)來工作。關於裝置的詳細資訊是由核心輸出(export)到位於/sys的sysfs檔案系統的。所有的裝置命名策略、許可權控制和事件處理都是在使用者態下完成的。與此相反，devfs是作為核心的一部分工作的。
問: 如果udev不能完成所有devfs的工作的話，為什麼把devfs標記為OBSOLETE/removed?
答: 引用 Al Viro (Linux VFS 核心維護者):
-devfs所做的工作被確信可以在使用者態來完成。
-devfs被加入核心之時，大家寄望它的質量可以迎頭趕上。
-devfs被發現了一些可修復和無法修復的 bug。
-對於可修復的 bug，幾個月前就已經被修復了，其維護者認為一切良好。
-對於後者，同樣是相當常一段時間以來沒有改觀了。
-devfs的維護者和作者對它感到失望並且已經停止了對程式碼的維護工作。
問: 但是當一個並不存在的/dev節點被開啟的時候，udev並不能如devfs一樣自動載入驅動程式。
答: 的確如此，但Linux的設計是在裝置被發現的時候載入模組，而不是當它被訪問的時候。
問: 不過等等，我確實希望 udev 可以在不存在的節點被開啟的時候自動載入驅動。這是我使用devfs的唯一原因了。給udev 增加這個功能吧。
答: 不，udev 是用來管理/dev 的，不是用來載入核心驅動的。
問: 嗨，求你們了。這不難做到的。
答: 這麼個功能對於一個配置正確的計算機是多餘的。系統中所有的裝置都應該產生hotplug 事件、載入恰當的驅動，而 udev 將會注意到這點並且為它建立對應的裝置節點。如果你不想讓所有的裝置驅動停留在記憶體之中，應該使用其它東西來管理你的模組(如指令碼, modules.conf, 等等) 這不是udev 的工作。
問: 但是我真的喜歡那個功能，還是加上吧
答: devfs用的方法導致了大量無用的modprobe嘗試，以此程式探測裝置是否存在。每個試探性探測都新建一個執行 modprobe 的程序，而幾乎所有這些都是無用的。
問: 我喜歡devfs的裝置檔案命名方式，udev 可以這樣命名麼?
答: 可以，udev 可以使用 /dev 的命名策略來建立節點。通過一個配置檔案，可以把核心預設的名字對映到 devfs 的名字。可以看看udev 中帶的 udev.rules.devfs 檔案。注意: devfs 的命名方式是不被建議並且不被官方支援的，因為它所用的簡單列舉裝置的方式在裝置可能被隨時加入或刪除的情況下確實是一個比較笨的方法。這些編號代給你的將只有麻煩，而並不能用來確定裝置。看看那個永久性磁碟 (persistentdisk) 的規則就知道如何在使用者態下正確的做這件事，而不是傻傻地列出裝置。
問: udev 可以為哪些裝置建立節點?
答: 所有在 sysfs 中顯示的裝置都可以由 udev 來建立節點。如果核心中增加了其它裝置的支援，udev 也就自動地可以為它們工作了。現在所有的塊裝置都在被支援之列，大部分的主字元裝置也是被支援的。核心開發者們正致力於讓所有的字元裝置都被支援。可以到linux-kernel郵件列表上尋找補丁或是檢視補丁的狀態。
問: udev 是否會去掉匿名裝置數量的限制?
答: udev 完全工作於使用者態。如果核心支援了更多的匿名裝置，udev就會支援。
問: udev 是否會支援符號連結?
答: udev 現在就支援符號連結，每個裝置節點擁有多個符號連結也是被支援的。
問: udev如何處理/dev檔案系統?
答: 建議使用一個每次啟動系統的時候重新建立的 tmpfs 作為 /dev 的檔案系統。不過實際上udev並不關心那種檔案系統在被使用。
問: 在 init 執行之前，udev 如何處理裝置?
答: udev 可以被放入 initramfs 之中，並在每個裝置被發現的時候執行。也可以讓udev 工作在一個真的根分割槽被載入之後根據 /sys 的內容建立的初始/dev目錄之中。
問: 我是否可以利用 udev 在一個 USB 裝置被載入的時候自動載入上這個裝置?
答: 技術上講是可以的，但是 udev 不是用於這個工作的。所有的主流釋出版 (distro)都包含了 HAL (http://freedesktop.org/wiki/Software_2fhal) 用於這個工作，它也是專門用於監視裝置變更的，並且整合進入了桌面軟體。
換個角度說，這可以簡單的通過 fstab 來實現:/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0
這樣，使用者可以用如下命令來訪問裝置:
$mount /media/PENDRIVE
同樣不需要管理員許可權，但卻擁有了裝置的全部訪問許可權。使用永久性磁碟連結(label, uuid) 將可以指定同一裝置，無論其實際上的核心名字是什麼。
問: 有什麼我需要注意的安全問題麼?
答: 當使用動態裝置編號的時候，一個給定的主/從裝置號可能在不同時間對應不同的裝置，如果一個使用者擁有對這個節點的訪問許可權，並且可以建立一個到這個節點的硬連結，他就可以如此得到一個這個裝置節點的拷貝。當裝置被移除之後，udev 刪除了裝置節點，但硬連結依然存在。如果這個裝置節點之後被重新使用不同的訪問許可權被建立的時候，其硬連結仍然可以使用先前的訪問許可權來訪問。(同樣的問題也存在在使用 PAM 改變訪問許可權的 login 上。)
簡單的解決方案就是通過把 /dev 放在 tmpfs 這樣的單獨的檔案系統之上來防止建立硬連結。
關於到底使用asmlib，還是使用udev更有優勢，可以參考文章：
http://www.oracledatabase12g.com/archives/why-asmlib-and-why-not.html