我有一个2TB的ext4文件系统（Ubuntu运行Linux内核2.6.31-22-服务器x86_64）。 该文件系统是通过USB插入的Drobo盒上的第二个驱动器。 我们在第一个驱动器上没有问题（由于一些操作系统的限制，Drobo限制驱动器大小为2TB，所以如果你有更多的空间，它显示为两个独立的驱动器）。
我使用Samba（smbd 3.4.0）与Windows和Linux工作站混合共享这些文件。
最近我们在多个文件中遇到了一些数据损坏。 在很多情况下，我有一个工作站上存储的未损坏的原始文件。 这些是各种格式的二进制文件（例如SQLite，但也有其他格式）。
我用“拆分”将损坏和未损坏的文件拆分为4096字节的块（这是ext4文件系统的块大小）。 然后我在成对的块上运行md5sum，发现块在许多情况下匹配，并且在每个不匹配的情况下，被破坏的块都是零块（ 620f0b67a91f7f74151bc5be745b7110 ）。
我试图find一个罪魁祸首，但有点不知所措。 我不相信桑巴是错误的，因为我在Drobo出口的第一个驱动器上使用它没有问题。
我能做些什么来缩小这个范围，找出发生了什么？
drobo-utils FAQ不会列出对ext4的支持。 也许你应该尝试使用ext3？
Drobo支持指出Drobo不支持ext4。
在黑暗中的一个狂野的镜头，但是如果Drobo不支持ext4，并且您看到大块零的问题…您是否已经在ext4中启用了扩展？ 如果drobo不知道如何处理它们，它可能会以某种方式将空格解释为要被复制的数据而不是被忽略，并且通过一些奇怪的内部逻辑来引起不匹配。 然而我的build议是和ptman一样的。 如果Drobo不支持ext4，请不要使用它。 文件系统足够复杂，如果没有得到正确的支持，覆盖的应用程序就会在低级别与其交互，像Drobo将不得不做他们的磁盘/ RAID /黑魔法一样，会造成各种各样的奇怪问题。
根据Drobo的支持，EXT3已经正式支持Linux内核2.6.36+，ZFS显然不被支持。 它看起来不像EXT4或XFS列在那里。 http://support.drobo.com/app/answers/detail/a_id/29/~/which-file-systems-do-drobo-storage-devices-support%3F
根据另一个支持文件，明确不支持EXT4： http : //support.drobo.com/app/answers/detail/a_id/165/related/1
（如果有人看到任何官方对XFS的支持，我会对此感兴趣）。