⑴ 绑定存储target至客户端失败
客户端不支持。绑定存储target是一种为客户端提供存储的方式。失败是因为当前客户端不支持创建存储池，只需要对客户端进行升级即可。
⑵ 硬盘变成存储池怎么取消
在存储池页面，单击目标存储池右侧的修改或删除，执行相关操作。
存储池是 Data Protection Manager (DPM) 服务器在其中存储副本、卷影副本和传输日志的一组磁盘。
必须向存储池添加至少一个磁盘才可开始保护数据。添加到存储池的磁盘应是空的。为了准备数据保护，DPM重新格式化磁盘并擦除磁盘上的任何数据。DPM服务器必须安装至少两个磁盘，一个专用于启动、系统和DPM安装文件，而另一个专用于存储池。
在DPM环境中，”磁盘“是指在Windows磁盘管理工具中显示为磁盘的任何磁盘设备。DPM不会将含有启动文件、系统文件或DPM安装的任何组件的任何磁盘添加到存储池。
在删除存储池前，要确保：已删除存储池中的全部卷，可发出MOVE DATA命令，确保已保存了希望保留的所有可读数据。 要移动希望保留的全部数据，可能需要发出几次MOVE DATA命令。
在开始删除属于存储池的全部卷之前，需将存储池的存取方式更改为不可用，以便不能从存储池中的卷写入或读取任何文件。有关删除卷的信息，请参阅删除有数据的存储池卷。
不将存储池标识为存储器层次结构内的下一个存储池，要确定该存储池是否作为存储器层次结构中的下一个存储池被引用，可查 询监视存储池中的可用空间中所述的存储池信息。
通过执行下列步骤之一，更新任何存储池的定义已将该存储池从存储器层次结构中除去，有关定义和更新存储池的信息，请参阅定义或更新主存储池。
1、将另一个存储池命名为存储器层次结构中的下一个存储池。
2、将 NEXTSTGPOOL 参数值用 ""（双引号）输入，从存储器层次结构定义中除去此存储池。
3、要删除的存储池不能被指定为任何域的活动策略集内管理类中任何副本组的目标。要删除的存储池也不能为空间管理文件的目标（在任何域的活动策略集内的管理类中指定）。
如果该存储池为目标，且要加以删除，则操作会因为没有保存数据的存储空间而失败。
⑶ ZFS问题zpool status pool
第 9 章 ZFS 疑难解答和数据恢复本章介绍如何确定 ZFS 故障模式以及如何从相应故障模式中恢复。还提供了有关预防故障的信息。
本章包含以下各节：
ZFS 故障模式
检查 ZFS 数据完整性
确定 ZFS 中的问题
修复损坏的 ZFS 配置
修复缺少的设备
修复损坏的设备
修复损坏的数据
修复无法引导的系统
作为组合的文件系统和卷管理器，ZFS 可以呈现许多不同的故障模式。本章首先概述各种故障模式，然后讨论如何在正运行的系统上确定各种故障。本章最后讨论如何修复问题。ZFS 可能会遇到以下三种基本类型的错误：
缺少设备
设备已损坏
数据已损坏
请注意，单个池可能会遇到所有这三种错误，因此完整的修复过程依次查找和更正各个错误。
ZFS 存储池中缺少设备如果某设备已从系统中彻底删除，则 ZFS 会检测到该设备无法打开，并将其置于 FAULTED 状态。这可能会导致整个池变得不可用，但也可能不会，具体取决于池的数据复制级别。如果镜像设备或 RAID-Z 设备中的一个磁盘被删除，仍可以继续访问池。如果删除了镜像的所有组件，删除了 RAID-Z 设备中的多个设备，或删除了单磁盘顶层设备，则池将变成 FAULTED。在重新连接设备之前，无法访问任何数据。
ZFS 存储池中的设备已损坏术语“损坏”包含各种可能出现的错误。以下是错误示例：
由于损坏的磁盘或控制器而导致的瞬态 I/O 错误
磁盘上的数据因宇宙射线而损坏
导致数据传输至错误目标或从错误源位置传输的驱动程序错误
只是另一个用户意外地覆写了物理设备的某些部分
在一些情况下，这些错误是瞬态的，如控制器出现问题时的随机 I/O 错误。在另外一些情况下，损坏是永久性的，如磁盘损坏。但是，若损坏是永久性的，则并不一定表明该错误很可能会再次出现。例如，如果管理员意外覆写了磁盘的一部分，且未出现某种硬盘故障，则不需要替换该设备。准确确定设备出现的错误不是一项轻松的任务，在稍后的一节中将对此进行更详细的介绍。
ZFS 数据已损坏一个或多个设备错误（指示缺少设备或设备已损坏）影响顶层虚拟设备时，将出现数据损坏。例如，镜像的一半可能会遇到数千个绝不会导致数据损坏的设备错误。如果在镜像另一面的完全相同位置中遇到错误，则会导致数据损坏。
数据损坏始终是永久性的，因此在修复期间需要特别注意。即使修复或替换基础设备，也将永远丢失原始数据。这种情况通常要求从备份恢复数据。在遇到数据错误时会记录错误，并可以通过常规磁盘清理对错误进行控制，如下一节所述。删除损坏的块后，下一遍清理会识别出数据损坏已不再存在，并从系统中删除该错误的任何记录。
检查 ZFS 数据完整性对于 ZFS，不存在与fsck等效的实用程序。此实用程序一直以来用于两个目的：数据修复和数据验证。
数据修复对于传统的文件系统，写入数据的方法本身容易出现导致数据不一致的意外故障。由于传统的文件系统不是事务性的，因此可能会出现未引用的块、错误的链接计数或其他不一致的数据结构。添加日志记录确实解决了其中的一些问题，但是在无法回滚日志时可能会带来其他问题。对于 ZFS，这些问题都不存在。磁盘上存在不一致数据的唯一原因是出现硬盘故障（在这种情况下，应该已复制池）或 ZFS 软件中存在错误。
假定fsck实用程序设计用于修复特定于单独文件系统的已知异常，为没有已知反常的文件系统编写这样的实用程序就是不可能的。将来的经验可能证明某些数据损坏问题是足够常见、足够简单的，以致于可以开发修复实用程序，但是使用复制的池始终可以避免这些问题。
如果未复制池，则数据损坏造成无法访问某些或所有数据的可能性将始终存在。
数据验证除了数据修复外，fsck实用程序还验证磁盘上的数据是否没有问题。过去，此任务是通过取消挂载文件系统再运行fsck实用程序执行的，在该过程中可能会使系统进入单用户模式。此情况导致的停机时间的长短与所检查文件系统的大小成比例。ZFS 提供了一种对所有数据执行常规检查的机制，而不是要求显式实用程序执行必要的检查。此功能称为清理，在内存和其他系统中经常将它用作一种在错误导致硬盘或软件故障之前检测和防止错误的方法。
控制 ZFS 数据清理每当 ZFS 遇到错误时（不管是在清理中还是按需访问文件时），都会在内部记录该错误，以便您可以快速查看池中所有已知错误的概览信息。
显式 ZFS 数据清理检查数据完整性的最简单的方法是，对池中所有数据启动显式清理操作。此操作对池中的所有数据遍历一次，并验证是否可以读取所有块。尽管任何 I/O 的优先级一直低于常规操作的优先级，但是清理以设备所允许的最快速度进行
⑷ 求助WIN10如何恢复配置错误的存储池硬盘
创建存储空间的具体步骤如下：
1、右击Windows 10开始菜单，选择“控制面板”命令。以“小图标”方式查看控制面板选项，在“所有控制面板项”列表中选择“存储空间”选项。
2、进入“存储空间”创建窗口。
3、在“存储空间”创建窗口中，点击“创建新的池和存储空间”。
小提示：如果没有看到任务链接，请单击“更改设置”进行设置。
4、选择要用来创建存储池的驱动器，然后点击“创建池”。指定驱动器名称和驱动器号，然后选择一种布局，指定存储空间大小，然后单击“创建存储空间”。
该方法是通过将内部硬盘与外界存储设备相互连接，形成一个存储空间，一旦硬盘数据遭到破坏或是丢失就可以自动备份到其他空间上。
⑸ 求助WIN10如何恢复配置错误的存储池硬盘
因为重装系统，之前做存储池的硬盘的磁盘信息丢失了，故而新系统无法重新识别3TB机械硬盘的内容，而且仅用一块磁盘做存储池的情况我在网上也没有找到相似的例子。
⑹ 创建池错误057
它的意思是处理ZFS存储池创建错误。
磁盘或其中一分片包含当前挂载的文件系统。要更正此错误，请使用 umount 命令。
磁盘包含 /etc/vfstab 文件中列出的文件系统，但当前未挂载该文件系统。要更正此错误，请删除或注释掉 /etc/vfstab 文件中的相应行。正在将磁盘用作系统的专用转储设备。
要更正此错误，请使用 mpadm 命令。磁盘或文件是活动ZFS存储池的一部分。要更正此错误，请使用 zpool destroy 命令来销毁其他池（如果不再需要）。或者，使用 zpool detach 命令将磁盘与其他池分离。您只能将磁盘从镜像存储池中分离。
⑺ ceph分布式存储-常见 PG 故障处理
创建一个新集群后，PG 的状态一直处于 active ， active + remapped 或 active + degraded 状态， 而无法达到 active + clean 状态 ，那很可能是你的配置有问题。
你可能需要检查下集群中有关 Pool 、 PG 和 CRUSH 的配置项，做以适当的调整。
一般来说，你的集群中需要多于 1 个 OSD，并且存储池的 size 要大于 1 副本。
有时候，我们需要搭建一个单节点的 Ceph 实验环境。此时，在开始创建 monitor 和 OSD 之前，你需要把 Ceph 配置文件中的 osd crush chooseleaf type 选项从默认值 1 （表示 host 或 node ）修改为 0 （表示 osd ）。这样做是告诉 Ceph 允许把数据的不同副本分布到同一 host 的 OSDs 上。
如果你已经启动了 2 个 OSD，它们都处于 up 和 in 的状态，但 PG 仍未达到 active + clean 状态，那可能是给 osd pool default size 设置了一个大于 2 的值。
如果你想要在 active + degraded 状态（ 2 副本）操作你的集群，可以设置 osd pool default min size 为 2 ，这样你就可以对处于 active + degraded 的对象写入数据。然后你还可以把 osd pool default size 的值改为 2 ，这样集群就可以达到 active + clean 状态了。
另外，修改参数 osd pool default size/min_size 后，只会对后面新建的 pool 起作用。如果想修改已存在的 pool 的 size/min_size ，可用下面的命令：
注意： 你可以在运行时修改参数值。如果是在 Ceph 配置文件中进行的修改，你可能需要重启集群。
如果你设置了 osd pool default size 的值为 1 ，那你就仅有对象的单份拷贝。OSD 依赖于其他 OSD 告诉自己应该保存哪些对象。如果第一个 OSD 持有对象的拷贝，并且没有第二份拷贝，那么也就没有第二个 OSD 去告诉第一个 OSD 它应该保管那份拷贝。对于每一个映射到第一个 OSD 上的 PG （参考 ceph pg mp 的输出），你可以强制第一个 OSD 关注它应该保存的 PGs ：
PG 达不到 clean 状态的另一个可能的原因就是集群的 CRUSH Map 有错误，导致 PG 不能映射到正确的地方。
有失败发生后，PG 会进入“degraded”（降级）或“peering”（连接建立中）状态，这种情况时有发生。通常这些状态意味着正常的失败恢复正在进行。然而，如果一个 PG 长时间处于这些状态中的某个，就意味着有更大的问题。因此 monitor 在 PG 卡 （ stuck ） 在非最优状态时会告警。我们具体检查：
你可以用下列命令显式地列出卡住的 PGs：
卡在 stale 状态的 PG 通过重启 ceph-osd 进程通常可以修复；卡在 inactive 状态的 PG 通常是互联问题（参见 PG 挂了 —— 互联失败 ）；卡在 unclean 状态的 PG 通常是由于某些原因阻止了恢复的完成，像未找到的对象（参见 未找到的对象 ）。
在某些情况下， ceph-osd 互联 进程会遇到问题，阻值 PG 达到活跃、可用的状态。例如， ceph health 也许显示：
可以查询到 PG 为何被标记为 down ：
recovery_state 段告诉我们互联过程因 ceph-osd 进程挂了而被阻塞，本例是 osd.1 挂了，启动这个进程应该就可以恢复。
或者，如果 osd.1 发生了灾难性的失败（如硬盘损坏），我们可以告诉集群它丢失（ lost ）了，让集群尽力完成副本拷贝。
重要： 集群不能保证其它数据副本是一致且最新的，就会很危险！
让 Ceph 无论如何都继续：
恢复将继续进行。
某几种失败相组合，可能导致 Ceph 抱怨有找不到（ unfound ）的对象：
这意味着存储集群知道一些对象（或者存在对象的较新副本）存在，却没有找到它们的副本。下例展示了这种情况是如何发生的，一个 PG 的数据存储在 ceph-osd 1 和 2 上：
这时， 1 知道这些对象存在，但是活着的 ceph-osd 都没有这些副本。这种情况下，读写这些对象的 IO 就会被阻塞，集群只能指望 down 掉的节点尽早恢复。这样处理是假设比直接给用户返回一个 IO 错误要好一些。
首先，你应该确认哪些对象找不到了：
如果在一次查询里列出的对象太多， more 这个字段将为 true ，你就可以查询更多。
其次，你可以找出哪些 OSD 上探测到、或可能包含数据：
本例中，集群知道 osd.1 可能有数据，但它挂了（ down ）。所有可能的状态有：
有时候集群要花一些时间来查询可能的位置。
还有一种可能性，对象存在于其它位置却未被列出。例如，集群里的一个 ceph-osd 停止且被剔出集群，然后集群完全恢复了；后来一系列的失败导致了未找到的对象，它也不会觉得早已死亡的 ceph-osd 上仍可能包含这些对象。（这种情况几乎不太可能发生）。
如果所有可能的位置都查询过了但仍有对象丢失，那就得放弃丢失的对象了。这仍可能是罕见的失败组合导致的，集群在写操作恢复后，未能得知写入是否已执行。以下命令把未找到的（ unfound ）对象标记为丢失（ lost ）。
上述最后一个参数告诉集群应如何处理丢失的对象。
拥有 PG 拷贝的 OSD 可能会全部失败，这种情况下，那一部分的对象存储不可用， monitor 也就不会收到那些 PG 的状态更新了。为检测这种情况，monitor 会把任何主 OSD 失败的 PG 标记为 stale （不新鲜），例如：
可以找出哪些 PG 是 stale 状态，和存储这些归置组的最新 OSD ，命令如下：
如果想使 PG 2.5 重新上线，例如，上面的输出告诉我们它最后由 osd.0 和 osd.2 管理，重启这些 ceph-osd 将恢复之（可以假定还有其它的很多 PG 也会进行恢复 ）。
如果你的集群有很多节点，但只有其中几个接收数据， 检查 下存储池里的 PG 数量。因为 PG 是映射到多个 OSD 的，较少的 PG 将不能均衡地分布于整个集群。试着创建个新存储池，设置 PG 数量是 OSD 数量的若干倍。更详细的信息可以参考 Ceph 官方文档 —— Placement Groups 。
如果你的集群已启动，但一些 OSD 没起来，导致不能写入数据，确认下运行的 OSD 数量满足 PG 要求的最低 OSD 数。如果不能满足， Ceph 就不会允许你写入数据，因为 Ceph 不能保证复制能如愿进行。这个最低 OSD 个数是由参数 osd pool default min size 限定的。
如果收到 active + clean + inconsistent 这样的状态，很可能是由于在对 PG 做擦洗（ scrubbing ）时发生了错误。如果是由于磁盘错误导致的不一致，请检查磁盘，如果磁盘有损坏，可能需要将这个磁盘对应的 OSD 踢出集群，然后进行更换。生产环境中遇到过不一致的问题，就是由于磁盘坏道导致的。
当集群中出现 PG 不一致的问题时，执行 ceph -s 命令会出现下面的信息：
1、查找处于 inconsistent 状态的问题 PG ：
这个有问题的 PG 分布在 osd.1 、 osd.2 和 osd.0 上，其中 osd.1 是主 OSD。
2、去主 OSD（ osd.1 ）的日志中查找不一致的具体对象 。
从日志中可以知道，是 rbd_data.1349f035c101d9.0000000000000001 这个对象的属性 _ 丢失了，所以在 scrub 的过程中产生了 error 。
3、执行 ceph pg repair 命令修复问题 PG 。
4、检查 Ceph 集群是否恢复到 HEALTH_OK 状态。
osd.1 的日志里也提示修复成功：
如果经过前面的步骤，Ceph 仍没有达到 HEALTH_OK 状态，可以尝试用下面这种方式进行修复。
1、停掉不一致的 object 所属的 osd 。
2、刷新该 osd 的日志。
3、将不一致的 object 移除。
4、重新启动该 osd 。
5、重新执行修复命令。
6、检查 Ceph 集群是否恢复到 HEALTH_OK 状态。
有时候，我们在 ceph -s 的输出中可以看到如下的告警信息：
这是因为集群 OSD 数量较少，测试过程中建立了多个存储池，每个存储池都要建立一些 PGs 。而目前 Ceph 配置的默认值是每 OSD 上最多有 300 个 PGs 。在测试环境中，为了快速解决这个问题，可以调大集群的关于此选项的告警阀值。方法如下：
在 monitor 节点的 ceph.conf 配置文件中添加:
然后重启 monitor 进程。
或者直接用 tell 命令在运行时更改参数的值而不用重启服务：
而另一种情况， too few PGs per OSD （16 < min 20） 这样的告警信息则往往出现在集群刚刚建立起来，除了默认的 rbd 存储池，还没建立自己的存储池，再加上 OSD 个数较多，就会出现这个提示信息。这通常不是什么问题，也无需修改配置项，在建立了自己的存储池后，这个告警信息就会消失。
⑻ JDBC调用存储过程,存储过程中事务回滚,报错
ConnCloseThread中关闭连接的时候，不是立刻返回的。Connection.close()会触发Connection.commit()，而因为调用的存储过程中，存储过程起了自己的事务，connection.commit()必须等到存储过程结束才能完成(这个是microsoft论坛上看到的)。如果所有connection.close()都等到tx commit或rollback完成才执行的话，这个问题就不会出现了
从测试结果来看，凡是close connection耗时比execute statement短的，连接（物理连接）都会报出该问题。分析原因：通过weblogic datasource获取的connection并不是物理connection，而是由weblogic wrapped的connection。这些conection在被close后，并不会关闭物理连接，而只是将物理连接还池。我们对connection的所有操作，最终都会被delegated到底层物理连接上，即commit()，rollback()最终都是在物理连接上执行。如果上面的connection.close()，底层物理连接没有等到存储过程事务结束就返回的话，那么物理连接上应该还带有此次操作的事务，而weblogic这边不会关系物理连接的情况，直接将连接放入connection pool供其它客户端使用。这时候如果设定了test on reserve的话，下次客户端从data source获取连接时，weblogic会检查这个物理连接，作一个select操作的，这个有问题的连接就会暴露出来，也就是上面的异常。这个问题如果使用driver manager来获取连接的话（如果每次都关闭的话），则不会出现，因为使用的物理连接每次都是不同的。还好，weblogic会帮忙重新创建有问题的连接。原因大概了解了，但这是谁的问题呢？ 为什么connection.close()不等存储过程的事务结束？
结论：一般而言，我们不建议通过JDBC调用存储过程的时候，在存储过程中定义事务，应该将tx的管理工作交给jdbc去做。 non-xa如此，xa亦如此，毕竟事务嵌套了以后，管理起来是个问题，完整性更是个问题。
⑼ ds a81016s 添加存储池 命令执行失败
ds a81016s 添加存储池 命令执行失败如下：
1.CloudStack创建主存储失败（SR已经被使用），删除SR后成功 由于最近工程需要用到这个东西，于是乎，在网上找了些资料解决了CloudStack创建主存储失败（SR已经被使用），删除SR后成功，的问题，这里就记录下： 创建.
2.SAN方案必须提供自管理能力，尤其在错误恢复、数据可用性以及性能管理方面，纠错和失败恢复也是企业存储的关键问题，RAID使存储管理员从由于硬盘失败而引起的数据丢失的担心中解脱出来。自动的负载平衡减轻了对存储。
⑽ windows server 2016 储存池显示不存在
用过2012R2和2016，储存池都是全部硬盘插上后自动识别的。
2012R2的可以被2016识别，但是把储存池升级到2016版的话就不能再被2012识别了。