服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

磁盘大小可由操作系统寻址

我有一个3ware 9550SXU-12存储控制器和750G的磁盘连接到它。 磁盘被configuration为单个单元(不是JBOD)。 我一直在进行一些性能testing,主要是看看分区alignment,encryption,RAID级别等对读/写/ iops性能的影响。 我感到惊讶的是,在我的情况下,相同的存储configuration的读/写性能与alignment的分区相比略低于未alignment的分区。 这促使我开始检查当通过3ware控制器连接时,以及在使用主板上的端口时,操作系统对于操作系统的可见性是否存在差异。 我知道3ware控制器放在磁盘上的磁盘控制块(DCB)元数据,允许更换控制器,而无需重新configuration控制器,因为configuration数据是从磁盘上的DCB块中读取的。 我的控制器使用“新格式”,这显然意味着控制器将DCB写入磁盘的最后1024个LBA中。 我很感兴趣,看看我的alignment方式是不是被3ware控制器给操作系统提供了一部分磁盘。 我发现了什么: 连接有或没有3ware控制器时,磁盘的开始看起来完全一样。 这里的alignment不应该有任何影响。 通过dd / md5sumvalidation。 磁盘的最后一个1024 * 512B的确包含了3ware的内容(由可读的string判断) 现在有趣的部分是:在3ware控制下,磁盘报告的媒体大小为749988741120 B,直接连接 – 750156374016 B,这意味着通过3ware控制器连接时,操作系统可以访问约160MB的磁盘介质。 如果仅仅是1024x512B(DCB)的差异,160MB似乎有太多的空间来存储这种types的控制器元数据是可以理解的。 问题: 有没有人知道是否有其他的考虑,当alignment连接到控制器的磁盘上的磁盘分区,这些磁盘存储单元configuration,我可能会错过? 出于好奇 – 有没有人知道最后160MB的磁盘媒体用于什么? 谢谢

DFSR积压滞留在不存在的文件夹中

我有两个2008r2服务器安装在全网状多用途复制组中。 (01和02)。 01是源服务器。 最初的同步刚刚完成,昨天晚上有两个文件夹没有出现在任何一台服务器上,但是他们被困在积压的变化中,从02推到01.从01到02的积压是清楚的,并且正在复制完美。 我试图重新启动02,这没有做什么。 两台服务器的事件查看器都没有任何帮助。 我试图创build和删除“蝙蝠侠”文件夹,希望能清除它。 它没有。 当我在01上创build它时,它将它推到02.当我在02上创build它时,它在积压时创build了一个冗余项。 还有一些其他的随机文件卡在积压。 他们是不必要的,所以我刚刚从01中删除他们,并清理他们从积压。 我希望只是对文件夹做同样的事情… 有什么地方可以帮我们find为什么这些文件夹卡住了? 编辑: 我也从DFSRdebugging日志中find了这个(昨天晚上初始同步正在完成时发生这种情况): 20140513 23:27:39.254 2372 CSMG 6769 ContentSetManager::Initialize csId:{2D9CF1D7-50E2-4B3E-AC6B-3D60C6B026EB} csName:Art rootPath:E:\Art state:InitialSync(Sync) ptr:0000000000F83D50 20140513 23:27:39.254 2372 CSMG 5547 ContentSetManager::CheckContentSetState Updating content set record csId:{2D9CF1D7-50E2-4B3E-AC6B-3D60C6B026EB} csName:Art ghosted:0 readOnly:0 readOnlySince:16010101 00:00:00.000 20140513 23:27:39.254 2372 CSMG 5590 ContentSetManager::CheckContentSetState Content set csId:{2D9CF1D7-50E2-4B3E-AC6B-3D60C6B026EB} state:InitialSync(Cleanup) 20140513 23:27:39.395 2372 […]