我们有运行Avaya CMS软件的Sun Solaris系统。 该软件使用Informix数据库。 我们在服务器中有一个驱动器。 驱动器开始坏了，腐败的文件。 我们购买了一个新驱动器，并能够将数据从旧驱动器复制到新驱动器，并成功启动并运行服务器。 我们还有一个问题，因为数据库报告的是坏块，不会写入新的数据。 我们该如何修复？ 它只是一个Informix命令来运行，还是我们必须取消分配和重新分配数据库存储？ IBM Informix Dynamic Server版本9.40.UC4 编辑：我们实际上不再关心旧的数据，只是我们想写新的数据，但它不会让我们。 无论如何解决这个问题？
我有以下基于NFS的存储设置： 计算节点是Linux。 NFS服务器是Solaris。 一个不太重要的用户在计算节点的一个子集上运行一堆读取密集型作业。 结果，整个计算节点组变得非常慢（ ls块30秒）。 我能够追踪到专用NFS服务器达到SAN读取吞吐量的限制。 如何实现服务质量（QoS），限制节点，进程或用户的NFS带宽？
我正在寻找使用dladm在Solaris框中创build聚合。 据我所知，一旦创build了聚合，802.3ad将被用来根据策略（L2，L3或L4）来平衡负载。 唯一的要求是接口连接到支持802.3ad的单个交换机，并且接口以相同速度/全双工运行。 有几个问题希望有人评论： 默认情况下，LACP在每个聚合上都被禁用。 启用LACP有什么好处？ 我不会用802.3ad和默认的L4策略进行负载平衡，据我所知，这个策略是根据源端口和目的端口的哈希select出站接口。 阅读维基百科，似乎只有两个好处LACP（1）故障转移和（2）自动configuration。 802.3ad是否已经支持故障切换？ 如果链路断开，交换机仍会尝试将数据包传输到该接口？ 很难相信这是事实。 而就自动configuration而言，我不确定在交换机上需要configuration什么。 对于802.3ad，我假定交换机只需要知道哪个负载均衡策略（L2，L3或L4）用于发送数据包到聚合。 我错过了什么吗？ LACP比802.3ad有什么优势？ 我在线阅读NFS时，在服务器/客户端之间使用两个连接：一个用于数据，另一个用于元数据，聚合中数据包的典型传输是循环，导致所有数据stream量都通过一个接口其他接口（假设有两个端口聚合）。 这似乎违背了我读到的有关802.3ad负载平衡策略的内容。 如果正在使用L4（Solaris dladm default），则出站接口将基于源端口和目标端口，并且假设交换机也使用L4，则入站接口也将基于src / dst端口。 我错了吗？ 顺便说一句，层2交换机真的看着src / dst端口？ 似乎资源密集型交换机将数据包拉开以计算散列，然后重新组合。 我也不希望传出和传入接口被用于相同的src / dst散列，也就是说主机使用的散列algorithm可能与交换机不同，或者它们计算来自不同端的端口。 出于这个原因，我很困惑为什么一个单一的stream将被限制在单个接口的最大吞吐量 – 如果传入和传出的传输可能在不同的接口。 我为分散的post道歉。 我试图理解这些技术，而且我还没有find一个很好的教程或文章来说明这些协议是如何实现的。 我看到很多文章将802.3ad和LACP归为一个。 任何意见将不胜感激。 谢谢！
在Solaris 11.3上安装ZFS L2ARCcaching是否有一个好方法？ L2ARC旨在忽略从文件中顺序读取的块。 这对于正在进行的操作是有意义的，但是使初始预热或基准testing中的高速caching变得困难。 另外，高度分散的文件可能会因在L2ARC中caching的连续读取而受益匪浅（因为磁盘上是随机读取的），但是就目前的启发式而言，即使L2ARC仅占满10％，这些文件也永远不会被caching。 在以前的Solaris 10和11发行版中，我成功地在每个文件上连续使用了dd两次。 第一个dd将文件读入ARC，第二个dd似乎让缓冲区发痒，所以他们有资格进行L2ARCcaching。 相同的技术在Solaris 11.3中似乎不起作用。 我已经证实，有问题的文件有一个8Klogging， 我试过设置zfs_prefetch_disable但这对L2ARC行为没有影响 更新： zfs_prefetch_disable结果是重要的，请参阅下面的答案。 如果没有好的办法做，我会考虑使用一个工具，产生100％的文件随机读取。 考虑到高速caching现在保持在11.3，这可能是值得的。 像这样的工具存在吗？
可能重复： sudo -i和sudo su有什么区别 – 我知道这两个命令都会导致获得root-shell。 但是有一些差异。 在一些服务器上，例如提示符是不同的： nomike@testerver:~> sudo -i root@testerver:~> logout nomike@testerver:~> sudo su – [root@testerver ~]# 所以我想“.bashrc”“.bash_profile”和“.profile”的处理方式有些不同。 有人调用一个loginshell而另一个不是？
我ZFS每月清理一次，72TB需要24小时。 对于我可以find多less次我应该擦洗的是： 非常繁忙的泳池，每周一次 不是那么繁忙的水池，每月一次 或运行擦洗，测量时间，并相应地进行调整。 但在线碎片整理呢？ 题 在线碎片整理被认为是像擦洗一样的好习惯吗？ 如果我应该多久降级一次？
我开始厌倦了在我越来越多的Solaris服务器上维护单个系统文件（现在是2，现在是10，并且日益强大）。 我将Sun Java Directory Server视为非NIS / NIS +解决scheme。 我们在这里经营一个主要的Windows商店，所以我也玩弄以下两件事之一： 使用Kerberos身份validation直接从Solaris客户端到AD（使用域控制器上的相应实用程序），或 使用Directory Server并使用其身份同步产品同步到Windows域 在这一点上，我更倾向于＃2，因为如果我（或用户社区）希望在服务器之间共享凭据，那么我只需要使用AD。 任何洞察力或恐怖故事都表示赞赏。
我有一个已经运行了一段时间的ZFS文件系统，最近我有机会升级它（最后！）到最新的ZFS版本。 我们的数据不会尖叫重复数据删除，但我坚信基于小testing，我们可以从5-10％的空间中获取任何地方的空间。 我已经在文件系统上启用了重复数据删除function，新文件正在慢慢地被重新数据删除，但是大部分（95％以上）的数据已经存在于文件系统中。 除了将数据池移出然后重新复制之外，有没有办法触发现有数据的重复数据删除扫描？ 它不一定是asynchronous的或活的。 （和FYI没有足够的空间来复制整个文件系统到另一个，然后只是切换安装。）
在尝试从FreeBSD 9.0-RC3挂载到Debian Linux机器时遇到了一个奇怪的问题。 我正在使用的命令是： sudo mount -v gorkon：/垃圾箱/ tmp / test 这将返回以下即时信息： mount：没有给出types – 因为冒号mount.nfs：超时设置为假设nfs 1月5日17:37:40 2012 mount.nfs：尝试基于文本的选项vers = 4，addr = [serverip ]，clientaddr = [cllientaddr]'mount.nfs：mount（2）：权限被拒绝mount.nfs：挂载gorkon时服务器拒绝访问：/垃圾箱 在服务器（gorkon）上没有可以find的日志条目，并且下面的日志条目位于我的系统日志中的debian框中： [30082.224612] RPC：服务器gorkon需要更强的身份validation。 NFS服务器有nfsuserd运行，rpcbind正在运行。 我试图设置/ etc / exports中的共享来使用sec = sys（并以同样的方式连接）。 我没有在这个networking上build立Kerberos，我也不打算开始。 Debian NFSv4服务器连接到Solaris 10 NFSv4服务器，如果我强制使用nfsv4（错误是mount_nfs：/ tmp / test，：Permission denied），FreeBSD服务器不能通过NFS挂载自己的共享。 一个FreeBSD 8.2-RELEASE盒子不会安装，同样的错误。 Solaris 10盒子也不能安装FreeBSD盒子的挂载。 这台机器的错误是： genunix：[ID 664466 kern.notice]服务器gorkon的NFS复合失败：错误7 genunix：[ID 532867 kern.warning]警告：NFS服务器初始调用gorkon失败：权限被拒绝。 […]
我正在试图添加一个新的磁盘到我的zfs根池。 这是我目前的configuration： # zpool status pool: rpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 c0d0s0 ONLINE 0 0 0 errors: No known data errors bash-3.00# df -h Filesystem Size Used Avail Use% Mounted on rpool/ROOT/s10x_u7wos_08 311G 18G 293G 6% / swap 14G 384K 14G 1% /etc/svc/volatile […]