用户为了能够让应用程序直接访问逻辑卷而创建了一个裸逻辑卷，大多数情况下应用程序会覆盖逻辑卷的LVCB，然而这并不是致命性的问题，用户仍然能在这个逻辑卷上执行维护命令：extendlv、mklvcopy、rmlv和crfs –d（这个命令会损坏LVCB中的所有信息），但并不是所有的LVM命令都能成功执行，例如就无法输入（Import）一个逻辑卷，所以它需要一个正确有效的LVCB才能执行成功。
因此通过应用程序直接访问LVCB是比较危险的，直接访问裸逻辑卷一般用于数据库系统。数据库系统使用裸设备存放数据以提高性能，例如informix的数据空间（DBSpace）可以建立在一个熟设备上（例如文件系统中的一个文件），也可建立在一个裸设备上（即裸逻辑卷，有时也称为生设备），当建立在裸逻辑卷时，最好不要让数据空间位于裸逻辑卷的开始，应该有一个偏移量（offset），偏移量的大小应大于LVCB的大小，一般用一个AIX逻辑块的大小做偏移量，即4096字节。但是有一些数据库厂商利用他们自己的方法管理逻辑卷，却覆盖了LVCB。
如果不知道逻辑卷开始的512个字节是LVCB，数据库程序覆盖了一个完整的LVCB，就破坏了逻辑卷的LVCB，这样非常有可能损坏数据库，要解决数据库问题只能找数据库厂商，而大多数数据库系统的最新版本都避免了这种问题的发生，除非是用户在建立数据空间时没有考虑LVCB的存在。
用上面提到的getlvcb命令可以检查逻辑卷的LVCB是否被损坏，如果字符串“AIX LVCB”出现，则表明LVCB是好的，除此之外，还可以用下面的命令检查逻辑卷的LVCB是否完整：
#od -c /dev/hd1
0000000 A I X L V C B \0 \0 j f s \0 \0 \0
0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0 0 0 d 2 8
0000060 7 3 5 3 6 9 7 1 3 0 . 1 6 \0 \0 \0
0000100 \0 \0 \0 l v 0 0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000120 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000200 \0 \0 \0 F r i A p r 1 3 1 7
0000220 : 1 6 : 3 5 2 0 0 1 \n \0 \0 \0 \0
0000240 \0 F r i A p r 1 3 1 7 : 1
0000260 6 : 3 8 2 0 0 1 \n \0 \0 \0 \0 \0 D
0000300 2 8 7 3 4 C 0 0 \0 y m m \0 y \0
0000320 \0 001 \0 001 / a l l e n f s \0 \0 \0 \0
0000340 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000520 \0 \0 \0 \0 l o g = / d e v / h d 8
0000540 : o p t i o n s = r w : a c c o
0000560 u n t = f a l s e \0 \0 \0 \0 \0 \0 \0
0000600 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
… …
当出现“AIX LVCB”字样，就说明LVCB是好的，否则就被损坏。如果逻辑卷的LVCB被损坏，而关于LVCB的内容还在ODM数据库中保存着，因此通过下面的命令可以恢复逻辑卷上的LVCB：
#echo "AIX LVCB\0" | dd of=/dev/lv1 bs=1 count=9
#updatelv lv1 datavg (lv0是逻辑卷名，它属于datavg卷组)
第一条命令是把逻辑卷标志写到从逻辑卷开始的9个字节中。第二命令是把ODM数据库中关于这个逻辑卷的LVCB内容写到从逻辑卷开始的512个字节中。
如果LVCB中的fs字段内容被删掉了，还必须用chfs命令按照ODM数据库中的其它内容，更新这一项：
# chfs -a log=/dev/hd8 /allenfs
如果在ODM数据库中找不到关于这个逻辑卷的信息，那么这个逻辑卷可能就无救了。
注:本文中的相关概念和内容请参阅《IBM UNIX&Linux—AIX 5L系统管理技术》一书。
