群暉 DSM6.22 休眠除錯,分析,概括
阿新 • • 發佈：2021-06-23
除錯新方法
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 tmpfs5 [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