V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ryd994  ›  全部回复第 70 页 / 共 497 页
回复总数  9921
1 ... 66  67  68  69  70  71  72  73  74  75 ... 497  
2020-07-03 18:01:43 +08:00
回复了 7DLNU56W 创建的主题 硬件 RAID5 的数据重建真的很糟糕么?
**如果你有 6 盘 raid10,那它用盘比 5 盘 raid6 多一块,可用容量一样
2020-07-03 17:59:28 +08:00
回复了 7DLNU56W 创建的主题 硬件 RAID5 的数据重建真的很糟糕么?
@594duck raid10 的优点是性能而不是安全性。如果你有 4 盘,那 raid6 比 raid10 更安全,因为 raid6 可以容许任意 2 盘,而 raid10 有 1/3 的概率损毁。
如果你有 6 盘,raid10 不仅用盘多一块,安全性还比不上 raid6 。因为随机挂两块的情况下,raid10 依然有 1/5 的概率损毁。
但 raid10 不计算 parity,所以非常适合高随机写入的 SSD 阵列。因为随机写入意味着每个写入都要重新计算 parity 。如果只写 1byte,raid10 会影响 2 个盘,raid6 会写 3 个盘以及读剩下的所有盘。


@7DLNU56W
@goldenalex
群晖大部分是软件阵列。很多甚至没有 hba 。软阵列指的是单盘暴露给主机,CPU 管理阵列的写入。硬阵列指的是单盘隐藏(或者只可以通过特定维护 API 访问,不走工作负载) CPU 不参与阵列的写入与维护。操作系统只能看到虚拟单盘。
群晖虽然不需要外部主机管理,但它自己也是有 CPU 的,数据是在 CPU 是完成阵列操作的。
硬 raid 基本只有 raid 卡一种(少数情况是 USB 硬盘柜支持硬 raid )
核心区分是操作系统能看到和管理单盘。

@libook 3 是 by design 。因为 raid 的设计目标是可用性而不是数据安全。raid 虽然有 parity 但并不要求校验。而且 raid5 的情况下如果校验失败也只能报错,因为发现 1bit 的错误需要额外 1bit,纠正需要额外 2bit 。实际上一般读的时候跳过 parity 。这也是为什么 raid5 的性能比 raid4 要好。
zfs 有校验,scrub 可以检测并(在有额外冗余度时)修复冷错误。
2020-07-03 09:55:40 +08:00
回复了 7DLNU56W 创建的主题 硬件 RAID5 的数据重建真的很糟糕么?
不至于那么慢,但也快不到哪去。你说的例子可能是 CPU 或者内存不够。那别说重建了,正常读写都费劲。

就算是 2TB 单盘,100MB/s 读写,那也要 5.5 小时才能重建完成
4T 单盘翻倍,8T 单盘又翻倍,就是 22 小时了
你所有硬盘要满负荷工作 22 小时,坏一块的可能性太大了
更恶劣的是硬盘都有 ure,一般盘的 ure 也就 10^-15 。这么多数据,还没有任何冗余度,重建过程中有错误数据很正常

用不用 raid5 取决于你对数据损坏的容忍度以及单盘大小。所以组 raid 单盘太大不是好事。单盘太小主要是性能问题。

zfs 会稍微好一点。首先 zfs 有校验,遇到 ure 能查出来,你可以死个明白。
其次 zfs,和大多数软 raid 和各种高级硬件 raid 一样,可以只重建已用的部分。但是 zfs 因为是文件系统自带,可以更细致一点。
2020-07-03 05:26:13 +08:00
回复了 XsterreX 创建的主题 Chrome Chromebook 乞丐配置无压力跑油管的 4K 视频
Chromebook 不能硬解 VP9
据说 YouTube 如果发现是 Chromebook 就会给 h264,如果是其他电脑就给 VP9
mac 的话可以试试强制 YouTube 使用 h264 的各类插件
看到了你的附言,看来你还是没有明白问题的根源
你以为那里有个果实,其实那里早就没有了。人家只是指出了这一事实而已。是你自己的疏忽大意让果实没了,而不是那个指出的人。
没人劝你大度,大家都在一边倒地说你傻逼而已。
平台公开漏洞存在而不公开漏洞细节,这就完全没问题。你的客户跑了是你自己的问题。如果你能尽快修复并公开漏洞细节,给你的客户看到问题不大而且你行动迅速,这都是可以理解的。
如果平台完全不公布会怎样?客户系统上线了,出事了,后来查出来平台早就知道,平台负得起这个责任吗?
只要漏洞在那里,它就有可能会出事,而不是有人公布了才会出事。

还是请楼主公布一下公司哪家。做生意不讲诚信的公司不能合作。
2020-07-02 01:29:53 +08:00
回复了 px920906 创建的主题 Dell u2720q hdr 过曝
你这可能是播放器不支持或者解码器没装好
用 MPC-HC 播放器试试
2020-07-02 01:27:33 +08:00
回复了 jackchao7432 创建的主题 投资 求 v 友们推荐有稳定收益的基金...
你又想稳定,又想要赚钱,这很难办啊。因为只赚不亏的买卖都在刑法上。

你首先需要一个明确的投资目标,这笔钱是多少年后要用。如果是十年以上,那在此之前市值就算下跌 50%又怎样?在目标日期之前涨回来不就好了?
@ihciah 大错特错
raid 卡的 bbu 是给 raid 卡的 ram cache 通电用的。不会任何其他元件供电。nas 不需要 bbu
bbu 是企业环境下提高随机写入 iops 用的

@cyang 那是个取巧的办法而已。但是如果有 UPS 连接的话还可以指定剩下多少电量才关机
你想想数据贵还是 UPS 贵?
UPS 首先功率要够,然后时间要够。其他问题不大,是不是正弦波也无所谓。反正 psu 里都要整流的
最好买能通知主机的,一般是 USB 口。否则断电了还不关机就没有意义了
你以为只有公布的那个人发现了漏洞吗?
他不告诉别人,就是没人知道?
一般来说,在安全领域,如果有白帽发现了漏洞,基本可以认为已经有黑帽在此之前已经发现并有可能利用这个漏洞。因为黑帽有真金白银的利益诱惑。

麻烦公司名字发一下,今后我们发现有什么漏洞保证不告诉任何人
2020-06-30 08:22:42 +08:00
回复了 Livid 创建的主题 硬件 Intel NUC Compute Element
不算新操作了
某云计算厂就有用 arm 核处理虚拟网络流量的操作
某种意义上来说也可以说是固件,但对外可独立访问

优点是 arm 核不支持虚拟化但非常便宜,比烧物理机 CPU 要便宜
2020-06-28 03:38:47 +08:00
回复了 dxgfalcongbit 创建的主题 随想 我发现现代社会有个 bug
不然怎么让他们专心学习和建设国家?!
2020-06-26 14:01:39 +08:00
回复了 henryshen233 创建的主题 NAS 关于机械硬盘的寿命疑问
定期监测 smart,每天一个 short test,每周一个 long test 。失败了就邮件通知
剩下的有 raid 顶着
2020-06-26 02:13:04 +08:00
回复了 Smash 创建的主题 问与答 入了个 5 盘位的 DS1019+,如何选择 RAID?
@bclerdx raid 几都不能防脑残管理员和本地天灾人祸
如果要数据安全,必须要异地备份
2020-06-25 18:51:41 +08:00
回复了 zhangyanwen2 创建的主题 互联网 有那个域名邮箱支持.tk 的域名?
别用 tk
tk 发现你用的多了,或者多次续期的话,就会把你的域名划成收费域名,一年 12 美元
一年 8 美元就可以买到 com,10 美元可以买到 net,12 美元可以买到 im
域名只是一点小钱,稳定最重要
2020-06-25 16:22:49 +08:00
回复了 Smash 创建的主题 问与答 入了个 5 盘位的 DS1019+,如何选择 RAID?
单盘超过 1T 就不应该用 raid5
raid5 在重建途中没有任何额外保障。重建负载重时间长,途中再挂一块很正常
而且硬盘还有读取错误率,重建时没有足够的额外冗余度来校验的话,很可能重建成功但数据错了

SSD 缓存反而是没必要的。家庭网不过百兆最多千兆。一块硬盘读写能力一般 100MB/s 以上,也就是 800Mbps,整个阵列加起来绝对超过千兆了

而且 nas 主要是连续读写,队列深度收 TCP 缓冲影响,实际上队列深度很深。可以充分利用缓存预读 /回写 /指令重排。单盘性能可以在 raid 下叠加。瓶颈只是连续读写带宽

SSD 缓存的主要应用是服务器上需要高性能随机写而且队列深度浅的情况,这时候性能主要受写入延迟影响。内存缓存因为易失所以无法使用。非易失的 SSD 就非常有用,optane 更佳。这种情况下 raid 基本没用,因为每个请求太小,都是打在单盘上。瓶颈是延迟而不是带宽。

带 UPS 的系统,哪怕只有小电池只保护 raid 缓存,也可以一定程度上改善此问题。因为只要写到 raid 卡缓存就可以认为非易失。延迟只限于 CPU 到 raid 卡缓存。
但是现在一般用软 raid,而且带 bbu 的 raid 卡一般很贵,bbu 也是易耗件。所以 optane 还是很有前途的。
2020-06-24 18:49:16 +08:00
回复了 coolair 创建的主题 京东 京东买的周黑鸭惊现白色粒状物品(密集恐惧症患者慎入)
@coolair 找工商投诉
举证义务不在你,在商家
@codehz 1.这不是 Unix socket 传统模型。在超算上我还用过类似的 mpi send/recv,也是发送接收完成之前不能使用 buffer 。还比你说的这个多个 recv 的能力。
但这不是标准的 bsd socket 。

2. 说白了就是让应用层来分配和维护 buffer

使用 splice,效果如下
A 有 user space 的数据 X0
写到 pipe 里,拷贝一次得 X1
B 从 pipe buffer splice 到 socket buffer
内核处理完 TCP 发送后释放
拷贝次数和 A 直接 send 一样

使用 shm,效果如下
A 处理数据的时候直接放到 shm 里
B 调用 send,从 shm 拷贝到 socket buffer
结果还是一次拷贝,但好处是 B 可以看到数据而且能进行一定的操作。splice 则必须直通


使用你说的 zero copy send,效果如下
A 有要发送的数据 X0
zero copy send,没有拷贝到 send buffer
B 从 socket 里接收,一次拷贝 X1
B 再 zero copy send,没有拷贝
总的来看拷贝次数也是一样,但是缺点是 A 和 B 都必须有一套逻辑来维护发送未完成的 buffer
A 这边比较简单,因为 B 大概率立刻接收。其实加起来和 shm 也差不多。但是 B 这边是出网络,情况就复杂得多。而维护 buffer 的逻辑内核里早就有了,何必重新发明轮子?

把 shm 和 zero copy send 结合,确实可以做到 zero copy 。缺点就是跨进程协调 buffer 的释放会非常非常蛋疼。

考虑到各种开销,实际哪个好还真未必
@zivyou socket 哪来的零拷贝? send recv 都要 buffer,buffer 就是一边一个拷贝
1 ... 66  67  68  69  70  71  72  73  74  75 ... 497  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2712 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 4041ms · UTC 12:37 · PVG 20:37 · LAX 04:37 · JFK 07:37
Developed with CodeLauncher
♥ Do have faith in what you're doing.