Description:
DS's Volume randomly crashes, a reboot will bring the volume back. Usually the root cause is because of improper shutdowns to the system in the past or faulty disks. Other symptoms may include not able to delete certain directory/sub-folders, media server and its database are not being able to restart or pglsql database not being able to be created. Here is how to determine if there are file system errors
[Message in log]
These messages are likely to be shown when Disk Station has file system errors:
Apr 28 23:28:22 kernel: [ 90.384521] EXT3-fs warning (device dm-0): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
Apr 28 23:28:22 kernel: [ 90.384540] EXT3-fs warning (device dm-0): ext3_clear_journal_err: Marking fs in need of filesystem check.
Apr 28 23:43:11 kernel: [ 979.276317] EXT3-fs error (device dm-0): htree_dirblock_to_tree: bad entry in directory #189366275: rec_len % 4 != 0 - offset=34256, inode=2132178368, rec_len=14, name_len=42
Feb 26 07:30:52 kernel: [ 43.483994] EXT3-fs error (device md2) in ext3_free_blocks_sb: Journal has aborted
Feb 26 07:30:52 kernel: [ 43.509978] EXT3-fs error (device md2) in ext3_free_blocks_sb: Journal has aborted
Feb 26 07:30:52 kernel: [ 43.542180] EXT3-fs error (device md2) in ext3_free_blocks_sb: Journal has aborted
[Solution]
There are two ways to approach this issue:
1. Backup all data from the volume then remove and recreate the volume which will have a fresh file system.
2. This is not recommended but if user ask for alternative solution, the other approach is to run a "fsck" file system scan to see if the errors can be corrected.
To do so, please telnet to system with the user root and the admin's password, then run the following commands to repair the filesystem. Before attempting this process, It is highly suggest to make backup for all important data from the volume first, then run the commands below:
* syno_poweroff_task
* umount /volume1
* fsck.ext3 -pvf -C 0 /dev/md2
* reboot the system after the scan is completed
If the user has lvm volume:
* syno_poweroff_task
* umount /volume1
* vgchange -ay
* fsck.ext3 -pvf -C 0 /dev/vg1/lv
* reboot the system after the scan is completed
Note that usually file system error usual is not correctable and officially we do not offer this service to users. User has to perform this task at his/her own risk.
If the volume is in EXT3 format, It is recommend to follow the first approach as the volume will be upgraded to EXT4 when created in DSM3.0 which has better performance and stability.
Kliknij, aby rozwinąć...