V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  eric107008  ›  全部回复第 1 页 / 共 1 页
回复总数  7
@iBugOne 昨天还在拜读 [201.ustclug]( https://201.ustclug.org) 中关于 ZFS 和 LVM 相关文章,在这儿遇见 iBug 本尊有种教科书里的人物跑到了现实中的既视感,非常亦可赛艇 [鞠躬]

我确实深入考虑了你说的全 HDD ZFS 方案,也研读过 UTSC 镜像站相关的许多内容(如前面提到的 201 )。目前来说仍然在进行思想斗争主要是这台 NAS 的使用场景与镜像站有着较大不同。我看到镜像站相关的很多文章讨论的是“读取的时候尽可能减小存储设备负担”的问题,因为镜像站的使用场景似乎是“少量且确定的写”(镜像站通常会有计划地进行同步)+“大量且随机的读”(没人知道哪个 PCDN 什么时候开始刷流),这时候 ZFS 针对读操作的优化就显得非常有用。同时,镜像站使用的是内存更大,CPU 性能更强的专业服务器硬件,有充足的内存资源支持 ZFS 的 ARC 缓存。在镜像站的使用场景下,ARC 的作用被非常充分地发挥了出来。相比之下,这台 NAS 面向的场景是日常工作过程中的数据存储。通常的使用场景是,为了某个明天打算跑训练的模型,把某个数据集下载下来,稍微做一些预处理,训练的时候写个 data loader 从 NAS 上读取数据。其通常会面对的是支持大量耗时且高 IO 的数据处理过程中工作站上的 SSD 装不下那么多数据的问题。

从这个角度来说,最理想的情况是,某种我不知道的东西可以“预约”SSD ,同时让 NAS 自己异步地在 SSD 和 HDD 之间 migration 。比如我即将要跑个数据处理,大量的中间数据和结果会通过网络写到 NAS 的 SSD 上,然后 NAS 自己在后台吭哧吭哧把这些数据慢慢挪到 HDD 里的同时,我处理完数据要跑模型训练的时候可以继续用 SSD 上处理好的数据集。等到我用完了这些数据,这些数据还会在 HDD 上好好呆着当作收藏(bushi),或是下次用的时候再或是慢慢从 HDD 读取或是“预约”一下挪到 SSD 上。倒不是因为 ZFS 或 LVM 好还是不好,而是纯粹地这台 NAS 它既是一个用于存储冷数据的 NAS ,又是半个工作站的外置硬盘。

不过显然这有些既要又要了。所以 ZFS 依然是我非常认真考虑的选择。
个人认为,大家一直说的 Raid 不是备份,只解决可用性不解决可靠性之类的说法,通常是在更广义或者更严格的“可靠性”语境下提出的。对于个人和家用的 NAS ,RAID 实际上可以提升一些使用体验,降低一些心智负担。特别是,实际上个人和家用环境并不会有企业环境那么大量的硬盘和数据,同时自己用的东西对成本也会比企业更敏感,结合好校验以及备份,数据丢失的风险实际上可以在家用 NAS 上降低到一个可以容忍的程度。如果个位数的硬盘组个 RAID1 ,绝大部分情况下可以做到“换块硬盘就能继续用”的效果的。

只依赖 RAID 确实并不能避免所有可能导致数据丢失的风险,比如多盘同时故障,人为或程序误操作(比如软件层误删除或勒索病毒),文件系统/RAID 系统的元数据丢失或出错导致的恢复失败等等。对于这些情况,RAID 并不会给你“后悔药”。但在“一块硬盘坏了”的情况下,我希望能够做到“换块硬盘就能用”,那么 RAID 还是可以提升一些可靠性的。毕竟相比起没有冗余没有备份的大多数非专业用户的使用情况,如果他们遇到“一块硬盘坏了”的情况,大概率是所有数据全丢。从这个角度看,RAID 确实帮我提升了一些可靠性。

RAID 最初设计的主要目标之一确实是为了减少硬盘故障对系统带来的停机时间,提高整体存储的吞吐、可用性以及对单盘故障的容忍度。站在运维或服务连续性的角度,RAID 更常被提到的是“系统还能不能继续运行”——这就是可用性的范畴。因此,如果单纯从“某块硬盘坏了之后还能不能快速、无痛地继续工作、并且重建数据”来看,RAID 确实能让你在硬件层面做到数据不丢失、系统不中断,也就是具备“提升部分可靠性+可用性”的作用。但如果放到“所有可能导致数据出问题的场景”这个更大范畴下,RAID 只是众多保护机制中的一环,做不到“全方位无死角”的数据可靠。

结合我自己的使用策略来看,RAID 对提升“数据可靠性”是有帮助的——至少能抵御一定数量的硬盘物理损坏,让你“坏盘不丢数据”。数据本身的安全性当然是需要备份,容灾,校验等多层次的保护手段来实现的,良好的数据管理习惯才是确保数据不丢。

我刚刚也在 NAS 的话题下提了个关于存储规划方案的帖子,在我目前的方案中,除了备份以外,我也打算用 RAID1 来降低我维护的心智和体力负担。如果一个硬盘坏了,我可以以一个还不错的概率赌一把我换块硬盘就能继续用且不会丢数据。如果真的阵列恢复失败,那我就把备份恢复回来,毕竟问题比“换块硬盘就能用”还严重了的话,多花点力气似乎也是理所应当的事情。
2023-11-13 20:32:25 +08:00
回复了 Masami7 创建的主题 程序员 毕业设计想要做一个网盘
不知道 OP 是什么专业,如果是纯计算机专业的话,可能还需要有一些技术上的创新点。但对于其他的可以考虑一些技术之外的因素(例如市场,道德,隐私)的专业,比如数媒或者信息管理,网盘(如 @Selenium39 所言,“基于云平台的文件管理系统”)还是可以做个毕设的,主要是需要把话说得好听一些。

立意点(意义)可以从人们对数据隐私的重视和目前环境下对数据隐私的担忧考虑。我之前遇到一个学生拿网盘作为毕设,也是说因为目前市面上的网盘也好 NAS 也罢,难以同时满足易用+可控。虽说百度网盘谷歌网盘之类的产品功能丰富设计精良(其实百度之流也并不精良),但终归是把自己的东西放在别人那里。仔细看看百度的用户协议可以发现基本上传上去的东西就是百度的了。而自部署(self-hosted)的一些选择也各有缺点,例如 Nextcloud 的单点架构设计不利于横向拓展之类的,你还可以对比一下 Seafile 和 Cloudreve 之类的产品. 商业 NAS 虽然数据存储在用户本地但软件上也并不能完全令人放心,毕竟没人知道不开源的 NAS 系统(例如群晖)会不会偷偷夹带什么私货。

总之就是论文的那些套路,别人的东西有哪些缺点,我的东西怎么怎么好之类的。具体实现的话就看自己的能力和喜好,不同的语言不同的方案都可以,还有很多开源方案可以借鉴参考。

总之就是根据学校毕设的评价方式,如果学校看重作品实现就把完成度做高一点,如果学校只看论文那就把论文改漂亮一些,想过并不难。
2023-04-26 10:53:42 +08:00
回复了 eric107008 创建的主题 问与答 请教一个前后端分离项目部署的问题
@cslive @soislom 非常感谢回复。我同意使用重定向的方式在 React-MVC 页面之间实现跳转,项目中也确实是这样实现的。

目前的问题主要集中在,应该如何将 React 和一个带 MVC 页面(意味着它有自己的 html 模板和静态资源)的 Spring boot 程序打包起来部署 /无缝衔接地分离部署。如果打包起来的话,React 编译出来的静态文件应该如何集成进 Spring Boot?

刚刚尝试了一些操作,目前发现勉强可行的是,将 React 的编译产物拷贝到 Spring Boot 的静态资源文件夹中,并将 React 编译产物中的 index.html 移动到 Spring Boot 的 html 模板文件夹中,这样 Spring Boot 打包时可以将 React 提供的 index.html 当作一个模板,以至于可以在 Controller 中返回这个 html 文件,并由 index.html 加载打包在 Spring Boot 中的静态资源。

但这样做存在一些问题,例如:React SPA 中的路由是由`react-router-dom`管理的。这意味着在 MVC 和 React 间跳转时,双方对路由的“认知”有所不同,会导致 React 认为 404 的地方其实 MVC 是有界面的,或是 MVC 本应重定向到 React 提供的类似 /404 这样的页面却意外返回了 WhiteLableErrorPage...

另外,我并不认为将 React 的编译产物拆开,混装进 Spring Boot 再 Build 是一个好主意,我仍然希望可以找到更优雅的方式。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   905 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 15ms · UTC 21:59 · PVG 05:59 · LAX 13:59 · JFK 16:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.