群晖 DSM6.22 休眠调试,分析,概括
调试新方法
9月13日发现的,这个方法特别好. snippetslab://snippet/283B1E35-8926-4597-840A-156020BF90A5/ 就是sysctrl开启vm的日志,然后dmesg一直查看.
1 root@BooksNas:~# sysctl vm.block_dump=1 2 vm.block_dump = 1 3 root@BooksNas:~# dmesg -Tw | grep -e md 4 [Fri Sep 13 19:51:59 2019] scemd(12920): dirtied inode 1075980 (volume2.lock.QNvXiK) on tmpfs
可以看到特大量的无关信息
1 Fri Sep 13 20:17:45 2019] scemd(12920): dirtied inode 1151427 (volume1.lock.2xA91s) on tmpfs 2 [Fri Sep 13 20:17:51 2019] scemd(12920): dirtied inode 1151537 (volume2.lock.MLROAS) on tmpfs 3 [Fri Sep 13 20:17:51 2019] scemd(12920): dirtied inode 1151538 (volume1.lock.egax9h) on tmpfs 4 [Fri Sep 13 20:17:57 2019] scemd(12920): dirtied inode 1151639 (volume2.lock.qYZAQU) on tmpfs 5 [Fri Sep 13 20:17:57 2019] scemd(12920): dirtied inode 1151640 (volume1.lock.QlXHxx) on tmpfs 6 [Fri Sep 13 20:18:03 2019] scemd(12920): dirtied inode 1151741 (volume2.lock.8AMumn) on tmpfs 7 [Fri Sep 13 20:18:03 2019] scemd(12920): dirtied inode 1151742 (volume1.lock.cXCkbd) on tmpfs
弄完了关掉
1 sysctl vm.block_dump=0
查看状态
1 sysctl vm.block_dump
所以原来某个人说的调试方法是真的好用的.
- 如果要改短到比如2分钟休眠,那就改配置文件,改了后去控制面板随便点点,让它有机会刷新吧. => 很遗憾的是,这个怎么都没弄成功. => 最好就还是10分钟吧.
- 怎么理解日志呢?就是看大概最后有md写入的,不放心可以[grep md]限制结果变坏.
- 所以理想的调试是什么呢?开着两个shell,慢悠悠的看着观察着,要几个有几个,那就很好了...恩...
- 用这个英文可以开着shell,所以可以一直观察休眠.
- 也可以看到一直出现的这个日志信息,可以调试Drive
- 确实的网页会带来一个该死的问题,看来就是错误了
-
1 [Fri Sep 13 20:53:51 2019] SYNO.Core.Curre(7876): dirtied inode 30814 (ftp_cur_con.log) on md0
Drive 结论
确实它导致的,过去两个月了,官方无法解决: https://koolshare.cn/thread-165759-1-1.html
降级Drive到1.1可以暂时用一用...
手动下载1.1的Drive,卸载2.0,忘掉备份功能,这样慢慢的开始吧:)
1.1的日志大概是这样的
1 [16360.262357] syno-cloud-clie(26959): READ block 36680128 on md3 (1024 sectors) 2 [16360.262453] syno-cloud-clie(26959): READ block 36681152 on md3 (1024 sectors) 3 [16360.262548] syno-cloud-clie(26959): READ block 36682176 on md3 (1024 sectors)
有个奇怪的东西...
1 [21511.587181] SYNO.Core.Curre(21466): dirtied inode 30667 (ftp_cur_con.log) on md0
如果乐意的话,也可以看大量实时的日志
1 dmesg -Tw
配合改短休眠时间,慢慢的观察它的情况...
早期基本结论
- 6.2.2 没有休眠的问题,系统没有问题.
- 星际蜗牛装在mSata会导致3~4分钟读取smart写scemd.log日志,而唤起硬盘.
- 日志调试很有用,主要依赖这两个命令,很多垃圾信息不用管 tail -f /var/log/hibernationFull.log | grep -v -e proc -e tmpfs -e WRITE
全部查看
1 cat /var/log/hibernationFull.log | grep -v -e proc -e tmpfs -e WRITE -
Driver 2.0是否会导致不能休眠,有待争议. - 一直开着命令行会导致无法休眠,开着网页,不知道.硬盘的休眠的一个前提是没有很多的数据访问.
- 休眠的设置时间文件
1 cat /etc/synoinfo.conf | grep stand 2 standbytimer="10"
可以弄成1,用vim改,使用[/]搜索stand,然后改成值1,这样待机就快了.
vim /etc/synoinfo.conf #命令 /stand => 寻找 #改值为1,完成
有意思的是....vim很聪明...还有...在控制面板里能看到1字呢!!!
影响因素
- 安装Drive 1.14后,也没机会休眠了,呵呵.
- 安装Drive 2.0套件后,会无法休眠,主要导致是
-
1 [ 1105.202362] cloud-workerd(17744): dirtied inode 92672 (job-db.sqlite-wal) on md3 2 [ 1105.202499] cloud-workerd(17744): dirtied inode 92673 (job-db.sqlite-shm) on md3
在资源查看器的进程里可以看到就是Driver Server的玩意在工作...
通过对raid的认识,我们现在知道了,数据会同时写道两个地方
1 [ 4507.641063] jbd2/md0-8(4572): WRITE block 2184264 on md0 (8 sectors) 2 [ 4507.641174] md0_raid1(4072): WRITE block 4980352 on sda1 (8 sectors) 3 [ 4507.641205] md0_raid1(4072): WRITE block 4980352 on sdc1 (8 sectors) 4 [ 4507.668850] jbd2/md0-8(4572): WRITE block 2184272 on md0 (8 sectors) 5 [ 4507.668872] jbd2/md0-8(4572): WRITE block 2184280 on md0 (8 sectors) 6 [ 4507.669633] jbd2/md0-8(4572): WRITE block 2184288 on md0 (8 sectors) 7 [ 4507.884497] md0_raid1(4072): WRITE block 4980352 on sda1 (8 sectors) 8 [ 4507.884536] md0_raid1(4072): WRITE block 4980352 on sdc1 (8 sectors)
所以硬盘很忙...真的...忙....
无关的部分
- 这人想出来让DSM不写其他盘的方法的.. http://www.nasyun.com/thread-59714-1-1.html 让某个盘的东西作废 我们的探索-可以直接用hdparm来调试
- 休眠调试的命令行
1 sysctl kernel.syno_hibernation_log_level