Jump to content

追悔莫及


Recommended Posts

On 1/31/2024 at 1:09 AM, JackieWu said:

遇到问题可以在论坛里面提出来让大家帮忙,别人不理你我帮你解决。

果然还是有热心人的,我试用过几个版本,发现在版本更新时会出现之前的配置不匹配或出错的情况,这个就很难受,用UNRAID的人都是应用Docker一大堆的,出现了问题,有可能导致全都重新配置!!!!

Link to comment
On 2/7/2024 at 9:34 AM, sevenmade said:

我能明白你的意思,但是就生产环境而言,实在不能让人安心啊。

unraid定位就不是面向生产环境的吧。为了支持最新的特性,经常更新最新的组件。不可避免会有各种兼容性、奇奇怪怪的问题。需要用于生产环境最好不更新,或者用群晖那样远古内核、应用全部自己研发的系统。

Link to comment

unraid就不是一个可以让你爽玩折腾的系统 前1,2年用的时候经常折腾它 ,重装我也不记得多少次了,但是它不管怎么死,数据都是无损的,就费时间,6.11.5更新后 我就不管他了.稳定不稳定也就集中在webui死,容器死,网卡死, 更新列表的已知问题里都写了,有些也修复了. 网卡可以不用螃蟹换个新的,那些非要用螃蟹用要一直囔囔的人我看见帖子都不想回. unraid 系统有好的地方也有不成熟的地方,内核更新也没有pve激进. 生产力就不要难为小作坊了 23333

Link to comment
On 1/31/2024 at 1:09 AM, JackieWu said:

遇到问题可以在论坛里面提出来让大家帮忙,别人不理你我帮你解决。

比如这个https://forums.unraid.net/bug-reports/stable-releases/unraid-zfs-hybrid-mode-read-slow-read-multipe-disk-r2833/?tab=comments#comment-27175

开发者还装死,我都发现unraid不止一个性能问题,我之前还发现user目录的文件系统驱动似乎是没有做缓存,每次目录遍历操作都要访问所有硬盘的文件系统,导致通过/mnt/user/节点遍历文件时性能十分糟糕。

Link to comment
6 hours ago, competent-bailout3425 said:

比如这个https://forums.unraid.net/bug-reports/stable-releases/unraid-zfs-hybrid-mode-read-slow-read-multipe-disk-r2833/?tab=comments#comment-27175

开发者还装死,我都发现unraid不止一个性能问题,我之前还发现user目录的文件系统驱动似乎是没有做缓存,每次目录遍历操作都要访问所有硬盘的文件系统,导致通过/mnt/user/节点遍历文件时性能十分糟糕。

 

/mnt/user 会存在 shfs overhead 问题,这导致了 I/O 性能会受到影响,你提到的没有做缓存、遍历性能差这些情况是基于 shfs overhead 之上而客观存在的,这主要是由于 urnaid 开发的 shfs 文件系统所带来的问题,我在我博客的这篇文章里面解释过相关的情况。

 

Unraid 阵列的可伸缩性和阵列 I/O 性能的损失是硬币的两面,这个“硬币”是 Unraid 与生俱来的,我个人对此问题的看法是没有绝对的好与坏,适合自己的就是最好的。

 

另外我也看了你链接的这个帖子,JorgeB 不是已经和你一起提交了 BUG 么,他也说了这个问题可能优先级没那么高(另外我也觉得帖子里的这个应用场景也确实相对没那么普遍),就看 Limtech 后续是否把这个问题的处理提上日程了,毕竟相比其他的问题,官方可能更在意其他待处理的事情,这个我倒不觉得官方在“装死”。

 

 

Edited by JackieWu
  • Like 1
Link to comment
8 hours ago, JackieWu said:

 

/mnt/user 会存在 shfs overhead 问题,这导致了 I/O 性能会受到影响,你提到的没有做缓存、遍历性能差这些情况是基于 shfs overhead 之上而客观存在的,这主要是由于 urnaid 开发的 shfs 文件系统所带来的问题,我在我博客的这篇文章里面解释过相关的情况。

 

Unraid 阵列的可伸缩性和阵列 I/O 性能的损失是硬币的两面,这个“硬币”是 Unraid 与生俱来的,我个人对此问题的看法是没有绝对的好与坏,适合自己的就是最好的。

 

另外我也看了你链接的这个帖子,JorgeB 不是已经和你一起提交了 BUG 么,他也说了这个问题可能优先级没那么高(另外我也觉得帖子里的这个应用场景也确实相对没那么普遍),就看 Limtech 后续是否把这个问题的处理提上日程了,毕竟相比其他的问题,官方可能更在意其他待处理的事情,这个我倒不觉得官方在“装死”。

 

 

至少我在一个软件开发者的视角来看,这俩都是代码写的挫导致的,io性能损失指的是不能条带化,因此多盘性能不会增加,不代表盘越多性能越差,遍历文件系统的问题显然可以通过在内存中维护一个shfs的目录树解决,即使考虑到内存占用的问题,每次都遍历访问所有硬盘文件系统我也不认为应该有如此之大的性能差距,很可能代码上是依次同步io导致的,换成异步io多半也能缓解这个问题(8+2盘的情况下,20倍的性能差距,这显然是不符合预期的性能差距)。

至于我链接里的那个帖子,至少在我所任职的公司所有任务都是有一个排期的流程的,优先级低的任务一会明确在什么版本提供,而不是就不提上日程了。不能给出修复时间,在我看来和装死没啥区别。

Edited by competent-bailout3425
Link to comment
3 hours ago, competent-bailout3425 said:

至少我在一个软件开发者的视角来看,这俩都是代码写的挫导致的,io性能损失指的是不能条带化,因此多盘性能不会增加,不代表盘越多性能越差,遍历文件系统的问题显然可以通过在内存中维护一个shfs的目录树解决,即使考虑到内存占用的问题,每次都遍历访问所有硬盘文件系统我也不认为应该有如此之大的性能差距,很可能代码上是依次同步io导致的,换成异步io多半也能缓解这个问题(8+2盘的情况下,20倍的性能差距,这显然是不符合预期的性能差距)。

至于我链接里的那个帖子,至少在我所任职的公司所有任务都是有一个排期的流程的,优先级低的任务一会明确在什么版本提供,而不是就不提上日程了。不能给出修复时间,在我看来和装死没啥区别。

 

你的观点可能是对的,可能就是代码写的不好导致,并且 Unraid 官方也没有那个意愿去修复这个问题,但是不是就是这样,我保持谨慎态度。

 

Unraid 作为一个收费系统,已经在市场上立足了十几年的时间, 我并不是想表达“存在即合理”的观点,而是如果一个显而易见的现象存在了很长的时间,并且从开发者的角度很容易得出结论(例如代码写的挫)和相应的解决办法(例如异步io),那么我会对这种问题保持更谨慎的态度(包括“不能给出修复时间,在我看来和装死没啥区别”的观点)。

 

Edited by JackieWu
Link to comment
5 hours ago, JackieWu said:

 

你的观点可能是对的,可能就是代码写的不好导致,并且 Unraid 官方也没有那个意愿去修复这个问题,但是不是就是这样,我保持谨慎态度。

 

Unraid 作为一个收费系统,已经在市场上立足了十几年的时间, 我并不是想表达“存在即合理”的观点,而是如果一个显而易见的现象存在了很长的时间,并且从开发者的角度很容易得出结论(例如代码写的挫)和相应的解决办法(例如异步io),那么我会对这种问题保持更谨慎的态度(包括“不能给出修复时间,在我看来和装死没啥区别”的观点)。

 

原因很简单,这只是小型的公司,技术和人力都是不足的,家用用户出的钱太少,也不足以养活一个多人技术强劲的团队,只能通过一些简单的办法凑合一个能用的方案和实现出来。比如unraid目前的cache就是这样,只能说在家用端适当的配置之后能用。当然这套也确实低成本的切中了大部分家用用户的需求,比如非条带化带来的最差情况也只会损失坏掉硬盘上的数据,这种企业用户完全不需要但是家用很实用的需求。

至于装死这个问题,我不太理解你如何持有一个谨慎的态度,假如你买了个东西,出了个问题,你联系卖家售后,卖家收到的货之后说,确实有问题,你慢慢等吧,我什么时候有时间了给修好再给你寄回去,大概你觉得这是一个正常可以接受的回复吧,至少我是接受不了。

Link to comment
6 hours ago, JackieWu said:

 

你的观点可能是对的,可能就是代码写的不好导致,并且 Unraid 官方也没有那个意愿去修复这个问题,但是不是就是这样,我保持谨慎态度。

 

Unraid 作为一个收费系统,已经在市场上立足了十几年的时间, 我并不是想表达“存在即合理”的观点,而是如果一个显而易见的现象存在了很长的时间,并且从开发者的角度很容易得出结论(例如代码写的挫)和相应的解决办法(例如异步io),那么我会对这种问题保持更谨慎的态度(包括“不能给出修复时间,在我看来和装死没啥区别”的观点)。

 

另外我解释下,可能在你看来,不吱声默默的下个y版本修好,和承诺下个y版本修好是没有区别的。但是实际上这是一个可能可以绕过的bug,因为我以前在用btrfs的时候是这个问题没有这么严重,一个G的吞吐量还是有的,xfs很可能没有这个问题。如果他下个z版本修,我会选择等,如果他下个y版本都不修,我就会选择全部刷回xfs。所以我十分在意承诺修复时间。

Edited by competent-bailout3425
Link to comment
35 minutes ago, competent-bailout3425 said:

可能在你看来,不吱声默默的下个y版本修好,和承诺下个y版本修好是没有区别的。

 

你的观点我都了解了,我保留我的观点,其他的不多做评价了。

 

另外虽然你用了“可能”,但请不要假设一个我的观点然后基于这个观点来阐述你的观点,我没有表达过这个想法。

Link to comment

就上个版本和之前的版本,还是颇为稳定的,新出的zfs功能稳定性和可用性十分堪忧,我迁移到zfs的时候还遇到了unraid的zfs限制了最大文件名长度的问题,导致我有部分文件无法正确拷贝过去,加上前段时间zfs出的那个恶性bug。官方真应该给zfs功能打个experiment标,最坑的是https://unraid.net/blog/zfs-guide对zfs还给予了一个比较高的评价。其他方面勉强可以达到凑合能用的水平的。

Link to comment

感觉大佬讲的都太难懂了。我作为刚接触nas的小白,将unraid作为第一款nas软件家用,讲一下我的使用。就看看zdm上文章和b站的教学视频,跟着虚拟了一个群晖一个openwrt,一个影音一个魔法。顺便提一下很多人在论坛上讲应用市场无法更新的问题,openwrt装wireguard,在unraid vpn配置一下很简单的,魔法想开就开想关就关,我记得这个方法还是在这个论坛看到的。docker和插件的配置攻略网上一大堆,不折腾的前提下也完全够用。硬盘没奇偶效验,太吵了,选择了冷备份,缓存盘开了个raid1。最后我感觉最麻烦的部分其实是硬件的选择,因为很多情况下问题都是出在硬件上。

1708332414377.jpg

  • Like 1
Link to comment
On 1/31/2024 at 1:09 AM, JackieWu said:
On 1/31/2024 at 1:09 AM, JackieWu said:

遇到问题可以在论坛里面提出来让大家帮忙,别人不理你我帮你解决。

 

感谢大佬,各方面已经稳定运行  只要不折腾 任何系统都是稳定的。  最近喜欢上了UNRAID的Docker和VMS 应用市场更是方便  界面直观 直通方便 我越来越喜欢它了 希望它越来越好

微信截图_20240222230333.png

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...