![]() | 1 mortal 2017-12-18 10:41:29 +08:00 这是 ReFS 的特性?正在用 Win Server 的表示密切关注… |
2 honeycomb 2017-12-18 10:42:56 +08:00 via Android 这似乎是 intended behavior,refs 会自行丢掉错误数据,美其名曰数据打捞 |
![]() | 3 congeec 2017-12-18 10:45:54 +08:00 口怕。我还以为只有移动数据的时候可能会丢失数据 |
![]() | 4 liuxiaofengone 2017-12-18 10:46:35 +08:00 文件系统 ReFS 现在不敢用,感觉还是有问题~ |
![]() | 5 FFLY 2017-12-18 10:49:46 +08:00 重点关注,有点厉害。 |
![]() | 6 raptor 2017-12-18 10:49:59 +08:00 还是那句话,珍爱 S(heng)M(ing),远离 MS。233 |
![]() | 7 XiaoFaye 2017-12-18 10:57:08 +08:00 via Android 还是用成熟的 NTFS 吧 |
8 tomhuang 2017-12-18 11:57:48 +08:00 via Android ![]() 虚拟磁盘建在镜像储存池里 refs vhdx 挂载至 hyperv 群晖 想了解详细情况 |
![]() | 9 sadan9 OP @honeycomb 我以为 ReFS 至少会把能恢复的部分数据恢复出来,读不出来的部分会填 0 之类的。结果复制 vhdx 文件的时候直接整个砍掉了,跪了。在 Hyper-V 里至少能访问大部分数据。 早知道至少先在 Hyper-V 里把能复制的文件复制出来。 |
![]() | 10 sadan9 OP 用的系统是 Windows Server 2016,ReFS v2 |
![]() | 11 aliuwr 2017-12-18 12:14:13 +08:00 有 FOUND.000 文件夹吗? |
12 qweaszxcdf 2017-12-18 12:16:49 +08:00 这不是 ReFS 的 feature 么 |
13 skylancer 2017-12-18 12:19:15 +08:00 我去.. |
15 RqPS6rhmP3Nyn3Tm 2017-12-18 12:21:13 +08:00 via iPhone 我还以为 APFS 是最烂的现代文件系统了,ReFS 接过一棒 |
![]() | 16 codeeer 2017-12-18 12:21:43 +08:00 via iPhone ![]() 微软:硬盘好像有个问题,我帮你扔了 |
![]() | 17 edsheeran 2017-12-18 12:22:19 +08:00 via iPhone 微系做服器就是笑 |
18 honeycomb 2017-12-18 12:23:19 +08:00 via Android @tomhuang 说不定它根本没考虑过 refs 套 refs 的情况 https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview |
![]() | 20 likuku 2017-12-18 12:33:44 +08:00 |
21 Nitromethane 2017-12-18 12:42:48 +08:00 我在 VM ware 中,也发生过磁盘文件损坏的问题。 对于这种重要数据,至少要做到双机备份吧。 |
![]() | &bsp; 22 Shura 2017-12-18 12:45:20 +08:00 这叫截肢手术,避免扩散,233333 (大雾) |
23 honeycomb 2017-12-18 12:49:39 +08:00 via Android @sadan9 我表述不对,看链接里那个 salvage data 的特性(卷保持在线,受损的文件则直接删除),看完以后是不是很想骂娘。 至于它那个自动修复错误的特性,估计依赖于开启完整性流,而开启了这个特性后涉及的内容会变成 copy on write 模式,而 io 性能会因为随时对数据算 hash,降低很多 |
24 honeycomb 2017-12-18 12:53:12 +08:00 via Android ![]() @likuku 我试过在带完整性流的情况下,它确实能修复错误。 方法是这样: 建两个 vhdx,格式化成 refs,都开完整性流,在储存池里挂载为双向镜像的卷。 卸载掉其中一个 vhdx,用 hex 编辑器把里面稍微乱改一下,再挂载回去,储存池能检测到错误,然后修复。 |
![]() | 27 likuku 2017-12-18 13:01:15 +08:00 @honeycomb 那么看来路子没错,自动修复数据错误,前提必须是存储池 /卷 底层必须是带冗余的才可以。这和 ZFS 的作法一样的。 |
![]() | 29 momocraft 2017-12-18 13:11:33 +08:00 /安慰 要不要考虑上 zfs ... 一个 freebsd 的 zraid pool 能简单提供 nfs/samba/sshfs,也可以当 VM guest (bhyve) 的块存储用。就是要的盘有点多 (raidz2 要五块起)。io 也不算快,不过撑满家里 GB 网线还是够的。 如果有需要可以偷偷 qq 上找我 -_- |
![]() | 30 sadan9 OP @honeycomb 自动修复我试过没问题,这次估计磁盘硬件问题,然后 refs 自动修复失败。问题部分数据读取失败直接砍掉一个 100G 文件这个做法……… |
31 RqPS6rhmP3Nyn3Tm 2017-12-18 13:18:18 +08:00 @tyhunter 使用下来大问题没发现有,但是性能好慢……尤其是加密的情况下 然后 snapshot 这个功能不能脱离 time machine 使用,逻辑上挺难理解的 |
![]() | 32 sadan9 OP 忽然还发现一个问题……既然 ReFS 都已经认为 IO 读取失败了……存储池里的磁盘居然状态都是正常……没有告警…… OTZ。。。。 |
![]() | 34 gamexg 2017-12-18 15:02:15 +08:00 @sadan9 还好上次因为没有快照功能没选择 ReFs,微软这个操作真的很厉害... 一次电源故障造成双盘镜像掉了一个盘外加另一个盘出现错误,zfs 显示几个文件损坏,修正电源问题两个盘重新上线后错误被自动修复了。 另外磁盘状态有错误计数,这个计数需要手动才能清除。 |
![]() | 36 opengps 2017-12-18 16:40:30 +08:00 微软这个想法很实在,反正用不了,别浪费时间了 |
![]() | 37 ThatIsFine 2017-12-18 18:09:05 +08:00 我 kao |
![]() | 38 jingniao 2017-12-18 18:49:23 +08:00 via Android 这样啊…… |
![]() | 39 hyuwang 2017-12-18 19:47:54 +08:00 用 ReFS 在 RAID0 上做数据储存的表示好慌。。。 |
40 RobertYang 2017-12-18 20:09:25 +08:00 via Android 有块存照片的硬盘是 refs,有点虚 |
![]() | 41 Feiox 2017-12-18 21:20:51 +08:00 咦,奇怪了,Azure 中 Blob Service 用的就是 Refs,SLA 承诺可用性 6 个 9 |
![]() | 42 mhycy 2017-12-18 21:29:28 +08:00 ReFS 的 BUG 总让我觉得是印度佬的作品 |
![]() | 44 bookit 2017-12-18 22:42:08 +08:00 ms 和 apple 比烂,也许不相上下, 因为阿三比例正在迅速接近? |
![]() | 46 euyuil 2018-01-07 17:58:28 +08:00 @Feiox Azure Blob 应该并不是使用 ReFS 来保证数据完整性的,并且可用性没有到 6 个 9 (其实只有 3 个 9 ),而是承诺 durability 到 11 个 9 (对于 LRS )。我以前在 Azure Storage 组工作过,Blob / Table / Queue 都使用一个微软内部的用在集群上的文件系统,效果上相当于同一份数据存储 3 份,然而并不是存储在同一台服务器上的,甚至不是在同一个机架上,以确保 2 个机架同时都挂掉的情况下(同一个机架用的电源和交换机是相同的),数据还能恢复。而 ReFS 只能用在一台机器的存储空间里,所以…… SLA 参考: https://azure.microsoft.com/en-us/support/legal/sla/storage/v1_3/ https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction |
![]() | 47 ZRS 2018-05-30 01:09:08 +08:00 LZ 启用了完整性流吗? |