V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  acess  ›  全部回复第 16 页 / 共 108 页
回复总数  2148
1 ... 12  13  14  15  16  17  18  19  20  21 ... 108  
2021-11-27 22:18:43 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@geniussoft 我也希望这样啊,但我还是觉得这就是 too good to be true 了😂
另外单单是 ST2000LM007 其实也分不同固件版本来着,貌似新的支持 TRIM 、老的不支持,而且有的老固件能升级、有的老固件升不了:
https://club.lenovo.com.cn/forum.php?mod=viewthread&tid=5974555
2021-11-27 15:31:53 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@wanguorui123 @wtdd 最开始的时候我用 diskgenius 全盘填充过一遍随机数据,而且这盘不支持 TRIM ,更何况我还开了 BitLocker/LUKS 全盘加密,按理说主控压根就不知道哪里是剩余空间。
2021-11-27 11:10:41 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
(怎么老是误触回复按钮……尴尬)
CMR 盘也有碎片问题,但是只要整理碎片就能解决。( drive-managed ) SMR 呢,有个类似闪存上 FTL 的 STL (叠瓦翻译层),那么会不会打破碎片整理依赖的假设,也就是连续的 LBA 对应物理层面上基本连续的写入(之前我有听说硬盘主控可以在出厂时屏蔽少许坏扇区,直接跳过,所以对读写速度几乎没有影响,所谓的“P 表”),于是碎片整理不知道会不会帮倒忙。
啊我现在在 Linux livecd 下,还没注意 Windows 上啥情况,但我记得之前有人说某块 SMR 盘在 Windows 的磁盘碎片整理(改叫“优化”了)里面压根就不显示来着。
2021-11-27 11:04:56 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@ryd994
@2i2Re2PLMaDnghL
所以就有一个问题,
2021-11-27 11:04:29 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@ryd994
@2i2Re2PLMaDnghL
所以并不单纯是“脏盘掉速”,其实是“碎片掉速”?
2021-11-27 11:03:21 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@billgong (接上条,刚刚手滑按到回复按钮了)
那么我这样测试应该能看到 media cache 被写满后的断崖式掉速才对。
那么也许是像我一开始脑补的那样,主控很聪明,知道我是大量顺序写入,于是就直接朝 SMR 里写,这样只需要处理最后一点点收尾的(因邻近磁轨会被覆写而不得不进行的)搬运就 OK ?
2021-11-27 11:00:42 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@billgong 我是 dd bs=1M
感觉很奇怪。网上说 DM-SMR 用户直接写的是 Media cache
2021-11-26 22:12:46 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@geniussoft
就是为了防止主控发现全是 0 而偷懒,我才开了 BitLocker ,并且指定加密方式为 XTS-AES 128 (而且 manage-bde -on -fet hardware 会报错“不支持基于硬件的加密”)。而且在此之前还是全盘随机填充过一次的。
而且不重复的随机文件我也算试过了(尽管本来就已经是隔着一层 BitLocker 了),跑了大概一两百 GB 吧(不过我是先在 ramdisk 里生成好再写进去,这样会有个短暂“喘息时间”,生成随机数据大约 300 多 MB/s )……但好像没看出明显掉速。
再然后我就不再给每一个文件重新生成一份新的数据了,直接从 ramdisk 里复制同一份随机数据,这样跑出来和(透过 BitLocker )写 0 的情况几乎是一模一样的。

也许在 Linux 下测试才能彻底从心理上打消所有疑虑,但我感觉现在这个状况好像不太可能是缓存、主控对写 0 特殊处理之类的。
2021-11-26 21:55:57 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@Cooky 又看了一下设备属性,删除策略是“快速删除(默认)”,应该是因为盘并没有拆出来,还是 USB 线连着原装的移动硬盘盒。下面的写入缓存之类并没有启用。
而且即便是缓存也应该只影响突发的少量写入,这样直接写满接近 2T 应该迟早要露原形,毕竟我这边的物理内存大小也比 2TB 小太多太多了。
2021-11-26 21:44:33 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@Cooky 另外任务管理器显示的磁盘写入速度,好像时不时瞥一眼,看上去也没有出现显著的掉速。
2021-11-26 21:42:27 +08:00
回复了 acess 创建的主题 硬件 SMR 叠瓦盘究竟在什么情况下会显著掉速?
@Cooky 我用的 cygwin 里的 dd ,加了 conv=notrunc,fdatasync
2021-11-16 19:59:37 +08:00
回复了 sungnix 创建的主题 宽带症候群 2021 年 11 月 IPv6 有什么实际应用场景吗?
啊,突然又想起来 shodan 上能搜到一堆摄像头这个梗……摄像头之类可能本来就是放在内网,只有套一层 ssh 或 vpn 才能访问才比较靠谱吧。
2021-11-16 19:58:14 +08:00
回复了 sungnix 创建的主题 宽带症候群 2021 年 11 月 IPv6 有什么实际应用场景吗?
PS4 不知道啥情况。摄像头我想应该可以 socat 之类转发一下?

另外怎么说呢,今天用 Win11 开了个移动热点,发现貌似还是不支持 IPv6 共享上网。
2021-11-07 18:03:53 +08:00
回复了 acess 创建的主题 Android setprop 设置 persist 属性值后怎么删除?
@AoEiuV020 getprop | grep persist.a 还有
2021-11-01 02:53:03 +08:00
回复了 Sekai 创建的主题 Bitcoin 现在哪个钱包客户端比较稳?
@wangkun025 你要不说我都没看出来……@jasonzhouu2 ,electrum 明摆着不止有电脑客户端啊😂不过手机端也就只有 Android 了,貌似没 iOS 的。
要说 Android 上的 electrum ,我没感觉到有多卡,只是中文一直都支持不了,貌似是 kivy 的问题。
2021-10-29 12:11:41 +08:00
回复了 viberconnection 创建的主题 宽带症候群 請教 NAT 相關問題
MTU 的话……我记得 OpenWrt 里就有个默认的 TCPMSS clamp-mss-to-pmtu 的 iptables 规则……好像并不需要专门去设置什么?
2021-10-29 12:09:50 +08:00
回复了 viberconnection 创建的主题 宽带症候群 請教 NAT 相關問題
UPnP 这个我也想问来着……
前两天我在维基百科上才(火星)知道了一个协议 PCP ( Port Control Protocol ),维基百科上说,部署 CGNAT (运营商级 NAT )后,因为运营商和用户自己家有了两层 NAT ,于是 UPnP 只在自己家这一层设置了端口映射,再往上一层运营商那里仍然没有设置端口映射。然后就提出了(标准化了) RFC 6887 PCP 协议。但具体这玩意长啥样我都没见过,在 V 站上搜一圈我也只搜到两三年前的帖子,说“协议比较新”“(大概是因为某些面向运营商的设备厂商把这个搞成了付费功能模块?)可能用不了”
2021-10-28 13:21:44 +08:00
回复了 emberzhang 创建的主题 宽带症候群 一大早北京联通公网地址没了
@aureole999
@ericwoflskin
还有 CGNAT 的 100.64.0.0/10 吧
2021-10-28 03:10:59 +08:00
回复了 xu2060 创建的主题 Bitcoin 关于比特币钱包恢复问题
@jayLink (啊,哈希其实也是数字签名必不可少的一个部分来着……比特币签名交易时用的哈希也是 256bit 的,于是我记得之前看到过,很显然因为生日攻击的存在,256bit 的哈希只有 128bit 的抗碰撞强度,所以从这个角度也可以说比特币系统只有 128bit 这个强度的安全性……)
2021-10-28 03:07:27 +08:00
回复了 xu2060 创建的主题 Bitcoin 关于比特币钱包恢复问题
@jayLink 额……并没有专门学过这方面……但是可以读精通比特币这本书、还可以搜 bitcoin wiki 、维基百科、bitcoin stackexchange 之类的……

从 2048 个单词表里抽取 12 个单词,2048^12=2^132 ,可以编码表示 132bit 的数据; BIP39 是把这 132bit 的最后 4bit 拿去做 checksum ,前 128bit 才是随机生成的 raw entropy 。(后 4bit 是前 128bit 推算出来的)
128bit 的强度其实已经和比特币用的 ECDSA secp256k1 数字签名等同。没错,虽然比特币私钥确实是 256bit 这么长,但毕竟这是非对称加密,只相当于 128bit 对称密钥的强度(我记得内在的原理还是生日攻击,但具体咋回事就不懂了)

所以说 12 单词的 BIP39 助记词已经足够安全了……(当然前提是生成助记词的随机数源靠谱,以及自己没有泄漏被骗什么的)

还有,老款的 trezor ( trezor one ,没有触屏)我记得就是为了防止键盘记录木马而打乱单词输入顺序,才用了 24 单词的 BIP39 。后来 trezor model t 有触屏了,不依赖电脑输入助记词了,于是就改成(默认) 12 单词了。(而且对于 trezor one ,后来也新加了远比打乱单词顺序更靠谱的“高级恢复”,也就是打乱键盘。打乱单词顺序能提供的熵我记得是差一点到 80bit ,比 128bit 还是减弱了不少,打乱键盘就不会像这样减弱强度了)。
1 ... 12  13  14  15  16  17  18  19  20  21 ... 108  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3350 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 11:42 · PVG 19:42 · LAX 04:42 · JFK 07:42
Developed with CodeLauncher
♥ Do have faith in what you're doing.