问题标签 [emc]

我将 kubernetes.io/scaleio 配置器与 Openshift Container Platform 3.9 一起使用。当我手动关闭节点时，它不会分离附加到节点分配的 pod 的卷。结果，新的 pod 无法在另一个节点上挂载这些卷（ScaleIO 仅限于 ReadWriteOnce）

症状：新 pod 卡在“Container Creating”状态，事件显示如下： Failed Mount - MountVolume.SetUp failed for volume "k8svol-xxxxxxx": 一次只能将单个 SDC 映射到此卷

有没有人遇到过这个问题？有什么解决办法吗？

用户可以在 Condor 上运行多个进程并访问 isilon 存储。有些人可能会以牺牲其他人为代价来滥用读取吞吐量。所以假设 isilon 可以处理 10GB/S 的读取速度。如果我有 3 个用户，每个用户有 100 个进程，每个进程都试图读取 1GB/S，那么其余的用户将被严重饿死。存在什么样的解决方案？单主机限制不起作用，因为用户通过 condor 读取。

我正在尝试将 emc ecs 社区软件作为独立的多合一节点部署安装在 ec2 上。我看到以下错误。任何帮助都感激不尽。

失败：[172.31.40.131] (item=/dev/nvme2n1) => {"changed": false, "failed": true, "item": "/dev/nvme2n1", "msg": "设备/dev/ nvme2n11 not found."}
失败：[172.31.40.131] (item=/dev/nvme1n1) => {"changed": false, "failed": true, "item": "/dev/nvme1n1", "msg" ：“未找到设备/dev/nvme1n11。”}

输出：
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:1 0 30G 0 disk
└─nvme0n1p1 259:2 0 30G 0 part /
nvme1n1 259:0 0 120G 0 disk
└─nvme1n1p1 259:5 0 120G
nvme2n1 259:4 0 108G 0 磁盘
└─nvme2n1p1 259:3 0 108G 0 部分
[root@luna log]#

日志片段

1 月 10 日 14:35:29 ip-172-31-40-131 期刊：TASK [common_baseline_install : Common | 在 ECS 块设备上创建 GPT 分区表] *********************************** ****************************************************** *********#015
Jan 10 14:35:29 ip-172-31-40-131 ansible-command：使用警告调用=True executable=None _uses_shell=False _raw_params=/sbin/parted -s /dev/nvme2n1 mklabel gpt removes=None 创建=None chdir=None stdin=None

1 月 10 日 14:35:30 ip-172-31-40-131 内核：nvme2n1：
1 月 10 日 14:35:30 ip-172-31 -40-131 日志：#033[1;36mchanged:[172.31.40.131] => (item=/dev/nvme2n1)#033[0m#015
1 月 10 日 14:35:30 ip-172-31-40-131 ansible-command：使用警告调用=True 可执行文件=None _uses_shell=False _raw_params=/sbin/parted -s /dev/nvme1n1 mklabel gpt removes=None 创建=无 chdir=None stdin=None
1 月 10 日 14:35:30 ip-172-31-40-131 内核：nvme1n1：

1 月 10 日 14:35:30 ip-172-31-40-131 日志：#033[1; 36mchanged: [172.31.40.131] => (item=/dev/nvme1n1)#033[0m#015
Jan 10 14:35:30 ip-172-31-40-131 journal: #015

Jan 10 14:35:30 ip-172-31-40-131 日志：TASK [common_baseline_install：Common | 分区 ECS 块设备] ****************************************** ****************************************************** *************************#015
1 月 10 日 14:35:30 ip-172-31-40-131 ansible-command：使用警告调用=True 可执行文件=None _uses_shell=False _raw_params=/sbin/parted -s /dev/nvme2n1 mkpart xfs 0% 100% 删除=None 创建=None chdir=None stdin=None
1 月 10 日 14:35:30 ip-172-31-40-131 期刊：#033[1;36mchanged:[172.31.40.131] => (item=/dev/nvme2n1 )#033[0m#015
Jan 10 14:35:30 ip-172-31-40-131 ansible-command: 使用警告调用=True executable=None _uses_shell=False _raw_params=/sbin/parted -s /dev/nvme1n1 mkpart xfs 0% 100% 删除=无 创建=无 chdir=无 stdin=无

1 月 10 日 14:35:30 ip-172-31-40-131 日志：#033[1;36mchanged:[172.31.40.131] => (item=/dev/nvme1n1)#033[0m#015
Jan 10 14:35:30 ip-172-31-40-131 期刊：#015

1 月 10 日 14:35:30 ip-172-31-40-131 期刊：TASK [common_baseline_install : Common | 检查 ECS 分区的对齐方式] ***************************************** ****************************************************** *******************#015
Jan 10 14:35:30 ip-172-31-40-131 ansible-command: 使用警告调用=True executable=None _uses_shell =False _raw_params=/sbin/parted -s /dev/nvme2n1 align-check opt 1 removes=None 创建=None chdir=None stdin=None
Jan 10 14:35:30 ip-172-31-40-131 内核：nvme2n1 : p1

Jan 10 14:35:30 ip-172-31-40-131 期刊: #033[1;36mchanged: [172.31.40.131] => (item=/dev/nvme2n1)#033[0m#015
1 月 10 日 14:35:30 ip-172-31-40-131 ansible-command：使用警告调用=True 可执行文件=None _uses_shell=False _raw_params=/sbin/parted -s /dev/nvme1n1 align-check opt 1 删除=无创建=无 chdir=无 stdin=无
1 月 10 日 14:35:30 ip-172-31-40-131 内核：nvme1n1：p1

1 月 10 日 14:35:30 ip-172-31-40-131 日志：# 033[1;36mchanged: [172.31.40.131] => (item=/dev/nvme1n1)#033[0m#015
Jan 10 14:35:30 ip-172-31-40-131 期刊：#015
Jan 10 14 :35:30 ip-172-31-40-131 期刊：TASK [common_baseline_install : Common | 格式化 ECS 分区] ******************************************* ****************************************************** ******************************#015
1 月 10 日 14:35:31 ip-172-31-40-131 ansible-filesystem：使用 resizefs=False force=True opts=None dev=/dev/nvme2n11 fstype=xfs 调用
1 月 10 日 14:35:31 ip-172 -31-40-131 日志：#033[1;31mfailed: [172.31.40.131] (item=/dev/nvme2n1) => {"changed": false, "failed": true, "item": "/dev /nvme2n1", "msg": "设备 /dev/nvme2n11 未找到。"}#033[0m#015
Jan 10 14:35:31 ip-172-31-40-131 ansible-filesystem: 使用 resizefs=False 调用force=True opts=None dev=/dev/nvme1n11 fstype=xfs
Jan 10 14:35:31 ip-172-31-40-131 journal: #033[1;31mfailed: [172.31.40.131] (item=/dev /nvme1n1) => {"changed": false, "failed": true, "item": "/dev/nvme1n1", "msg": "设备 /dev/nvme1n11 未找到。"}#033[0m#015

每个人！我本月开始使用 Documentum，这是我的问题。有柜子的多选下拉列表。我必须选择其中一些才能在下面的结果列表中获取内部文件夹列表。这个查询：

或者

其中参数是 object_name

适用于单个下拉选择。我试图插入“in”

结果与

或者

结果与

并在上面的查询中返回多值标志，但它不起作用。有人可以帮忙吗？谢谢！

如何在 Linux 中将外部温度传感器与风扇 emc2103 绑定。由于 emc2103 有自己的温度传感器，用于控制风扇速度。但我想根据 CPU 温度控制风扇速度。如何用这个 emc2103 风扇构建这个 CPU 温度传感器

我有一个像下面这样的文件。我想搜索模式 ABC_DATA 作为变量，匹配后，我想从前一个“多路径”行删除到包含“}”字符的行。"}" 可以在 ABC_DATA 之后或在同一行中。

样本输出

预期输出

我从一家公司购买了一台使用过的 EMC VNXe3150，因为它已停产，但它的硬件状况良好，工作正常。随着 Flash 的死亡迫在眉睫，并且管理 UI 仅在 Flash 中可用，它很快就会成为一个昂贵的镇纸，无论是否有许可证。

我正试图让一个真正的操作系统在机器上运行，但最好是 unRAID。我已经启动 unRAID 并启动了 Ubuntu 实时会话，但我一直遇到一个大问题：我无法访问磁盘，我不知道为什么。

这是我目前掌握的所有信息。我可以根据需要提供更多。第一组输出来自现场 Ubuntu：

调查 lspci

调查 dmesg

查看 pm80xx 内核模块

使用默认操作系统查看此设备时，除了没有提及 pm80xx 和 lspci 外，没有什么不同，因为它看起来像这样：

对此的任何和所有帮助将不胜感激。

对于此表，结果显示在结果的顶部。对于此表，结果显示在结果的底部。

我尝试了几种方法，加入。但是连接需要交替
表1记录表2记录表
1记录
表2记录

我需要表
1记录
表2记录
表2记录
表2记录

我有一个关于 ESP32 无线接口的问题。长话短说，我要做硕士研究，我希望它是关于 ESP32 Wi-Fi + BL/BLE。我的主管建议我们可以利用我部门大楼上的 EMC 室，并测量 ESP 在传输过程中对电磁干扰的处理能力（ESP 到 ESP 通过 Wi-Fi、BL 和 BLE，正如我所提到的）。问题是我们必须让它依赖于一些可变参数。首先，我考虑过使用各种协议，但从长远来看，这没有任何意义。然后我的主管建议更改例如 MTU。我进行了搜索，发现如何为 BL 更改它，但找不到如何为 Wi-Fi 进行更改。有人知道如何在 ESP 中修改 Wi-Fi 的 MTU，以及我还能改变什么来影响电磁电阻？

这是一个合理的主题吗？也许作为一个非常了解 ESP 的社会，您可以提出一些其他有趣的研究想法？

感谢您的时间和精力！

用户扫描文档后，这些将显示在 Captiva Administrator (v7.10) 上的“错误”状态，当尝试在分类编辑应用程序上打开分类时，它将保持空闲并显示消息“等待任务”，还注意到优先级设置为“离线”。

我尝试手动导入一个文档，它进入“正常”状态，我能够为它运行分类编辑应用程序，需要帮助了解可能导致扫描文档进入错误状态的原因。

注意：扫描是在带有实际扫描仪设备的笔记本电脑上使用本地 ScanPlus 安装完成的。

在 Documentum 导出模块中，我可以看到此错误：

由于 Documentum 错误，无法将生命周期策略附加到对象 46015da88304f7be、LifeState Open、LifeAlias：[DM_SESSION_E_LAUNCH_BP_TRANSITION] 错误：“由于错误无法启动 BP 转换评估流程：未知错误”。[CR][LF]

并且每当我在模块设置上禁用生命周期时，都不会发生错误。

更新 在启动 JBOSS JMS 后，问题似乎已解决，我不清楚 Documentum 导出模块与 JMS 的通信如何工作（因为我们有 2 个内容服务器，但 JMS 仅在其中 1 个中停止），但是我知道他的特定流程失败在 Documentum 导出模块设置 (Captiva) 上设置了生命周期，并且 JMS 负责将生命周期分配给文档。