DSM 6.x und darunter DS1512+ => DSM 5.2-5592 Update 2 => log. LW "Volume1" zerstört, Festplatten o.k.

[arcade]

DS1512+ => DSM 5.2-5592 Update 2 => log. LW "Volume1" zerstört, Festplatten o.k.

...ich hab die Zeilen bereits im Update-Beitrag gepostet, hoffe aber, dass mir hier, wenn überhaupt noch möglich, schneller geholfen wird..

Bei mir sieht es ganz düster aus... und ich weiss mir ehrlich gesagt keinen Rat...
Meine Volume 1 (10x 3TByte WD Green, Raid5 mit Datenschutz) ist abgestürzt und lässt sich weder durch Hard noch Soft-Reset wieder zum Leben erwecken. Ich habe eine DS1512+ inklusive vollbestückter Expansion-Einheit im Einsatz, hatte noch ungefähr 4,5TByte frei auf dem Volume. Der Speichermanager bietet mir nur ein "Entfernen" des Volumes an.
Und nun... ?? Alle 10 Platten funktionieren fehlerfrei. Hatte den NAS auch vor einigen Tagen ne Woche aus. Da waren keine Probleme nach dem Neustart. Erst heute früh mit dem Update auf die Version 2 ... alles hinüber.
Was kann man tun?? Eine technische Telefon-Hotline ist wohl nicht verfügbar? Bei der Datenmenge lassen sich auch nicht mal so nebenbei Backups realisieren. Von vielen Daten existieren BU´s, aber leider nicht von allen.. :-(

 

[arcade]

Bevor ich jetzt anfange irgend einen Blödsinn über die Console zu erreichen. Die WEB-GUI bietet aus meiner Sicht keine Möglichkeit das Volume zu reparieren. Hat jemand einen Tip, wie man dies zumindest über Console sinnvoll versuchen könnte?
Hier noch einige techn. inf. zum Raid5-Volume.. "volume1" zeigt im listing keines meiner ursprünglichen Verzeichnisse ... :-(

MonsterDisk> mdadm --query --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Jul 21 20:50:40 2012
Raid Level : raid5
Array Size : 26329898304 (25110.15 GiB 26961.82 GB)
Used Dev Size : 2925544256 (2790.02 GiB 2995.76 GB)
Raid Devices : 10
Total Devices : 10
Persistence : Superblock is persistent

Update Time : Tue Aug 4 07:42:31 2015
State : clean
Active Devices : 10
Working Devices : 10
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

Name : MonsterDisk:2 (local to host MonsterDisk)
UUID : ee49a613:cff9a927:0a1d4323:391c2797
Events : 810260

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3
4 8 67 4 active sync /dev/sde3
7 131 99 5 active sync /dev/sdga3
6 131 115 6 active sync /dev/sdgb3
8 131 131 7 active sync /dev/sdgc3
10 131 163 8 active sync /dev/sdge3
9 131 147 9 active sync /dev/sdgd3
MonsterDisk> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdgd3[9] sdge3[10] sdgc3[8] sdgb3[6] sdga3[7] sde3[4] sdd3[3] sdc3[2] sdb3[1]
26329898304 blocks super 1.2 level 5, 64k chunk, algorithm 2 [10/10] [UUUUUUUUUU]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[4] sde2[3]
2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4]
2490176 blocks [5/5] [UUUUU]

unused devices: <none>
MonsterDisk> pwd
/volume1
MonsterDisk> ls
@eaDir @tmp cd ls mdadm
MonsterDisk> pwd
/volume1
MonsterDisk> cd ..
MonsterDisk> ls
1 etc lib mnt run tmp var.defaults
bin etc.defaults lib64 proc sbin usr volume1
dev initrd lost+found root sys var volumeUSB1
MonsterDisk> cd volume1
MonsterDisk> ls -lsia
57345 4 drwxr-xr-x 4 root root 4096 Aug 4 10:51 .
2 4 drwxr-xr-x 25 root root 4096 Aug 4 07:42 ..
57528 4 drwxrwxrwx 13 root root 4096 Aug 4 07:10 @eaDir
57625 4 drwxrwxrwx 2 root root 4096 Aug 4 07:42 @tmp
57417 0 -rw-r--r-- 1 root root 0 Aug 4 10:51 cd
57567 0 -rw-r--r-- 1 root root 0 Aug 4 10:51 ls
57626 0 -rw-r--r-- 1 root root 0 Aug 4 10:51 mdadm
MonsterDisk>

 

[arcade]

Ich antworte mir nochmal selbst... und hoffe, dass hier ein erfahrener Serveradmin bzw. Linux-Profi folgendes bewertet...
Kann es helfen, wenn ich über die Konsole:

1. das Raid anhalte: mdadm --stop /dev/md2

2. mein Raid5-Volume mittels:

mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3 /dev/sdga3 /dev/sdgb3 /dev/sdgc3 /dev/sdge3 /dev/sdgd3

versuche zu reparieren?

=> das ganze selbstverständlich als root...

Könnte nach einem Reboot das Volume wieder laufen?

PS: Parallel hab ich eine offizielle Anfrage an Synology gestellt... Mal sehen ob da überhaupt ne antwort kommt...

 

[arcade]

hmmmm, ich schreib mir hier einfach selbst weiter

Was ich "erschreckender" Weise nach dem Auslesen der "messages" festgestellt habe ist, dass der "volume1"-Crash tatsächlich unmittelbar nach dem Einspielen des aktuellen Updates gestern früh auftrat! Am 02. bzw. 03.08. sind keine Auffälligkeitein im Logging festzustellen. Da die 10HDD´s offensichtlich keine Fehler zeigen, der Smarttest problemlos durchlaufen wird, kann aus meiner Sicht tatsächlich nur das Update für den Volume-Crash verantwortlich sein. Was für ein Mist!!
Falls jemand die Log´s besser interpretieren kann, ich bin für jede Meinung offen...
Eine Reaktion auf mein TT bei Synology liegt leider noch nicht vor...

Hier seht Ihr, dass das Update gestern komplett gelaufen ist... Den gesamten Log mit den relevanten Fehlermeldungen häng ich als Datei an..

Anhang anzeigen SynologyCrash.txt

Aug 2 13:41:24 MonsterDisk synorelayd: src/libsynoportmapHelper.cpp:56 SLibGetRouterConf() failed
Aug 2 13:41:24 MonsterDisk synorelayd: src/libsynoportmapHelper.cpp:139 GetInitState() failed
Aug 2 21:29:50 MonsterDisk mountd[13176]: /volume1/video exported to both 192.168.100.0/24 and 192.168.100.6, arbitrarily choosing options from first
Aug 3 02:00:36 MonsterDisk SecurityScan.py: /usr/syno/synoman/webman/modules/SecurityScan/FuncAPI.py:412:updateCheck(): Fail to get version <urlopen error timed out>
Aug 3 02:02:27 MonsterDisk synopkg: pkgcurltool.cpp:261 Failed to curl perform, code=35, err=Error
Aug 3 02:02:27 MonsterDisk synopkg: pkgcurltool.cpp:423 Failed to download https://payment.synology.com/api/getPackageList.php, code=35, err=Error
Aug 4 06:55:11 MonsterDisk touchVolumeRemap.cgi: lvm_path_parse.c:35 Unsupported vg path: /dev/md2
Aug 4 07:05:57 MonsterDisk entry.cgi_SYNO.Core.Upgrade[1].start[19960]: update_cpputil.cpp:806 synoservice: stop all packages ...
Aug 4 07:06:09 MonsterDisk scheduler: scheduler.cpp (2236) Got signal. Die gracefully.
Aug 4 07:06:09 MonsterDisk synodldbd: synodldbd.cpp:18 Get sig [15] and set gblDaemon to false
Aug 4 07:06:09 MonsterDisk synodldbd: socket.c:115 Failed to select [Interrupted system call]
Aug 4 07:06:09 MonsterDisk synodldbd: synodldbd.cpp:139 Failed to accept socket
Aug 4 07:06:11 MonsterDisk root: CS: [start-stop-status]: Cloud station stop...
Aug 4 07:06:11 MonsterDisk cloud-indexd: select(socket_fd): Interrupted system call (4)
Aug 4 07:06:17 MonsterDisk synorelayd: src/libsynoportmap.cpp:586 get max rule fail
Aug 4 07:06:17 MonsterDisk synorelayd: src/libsynoportmapHelper.cpp:56 SLibGetRouterConf() failed
Aug 4 07:06:17 MonsterDisk synorelayd: src/libsynoportmapHelper.cpp:139 GetInitState() failed
Aug 4 07:06:18 MonsterDisk synoaudiod: synoaudiod.cpp:2093 synoaudiod exit
Aug
Aug 4 07:06:34 MonsterDisk [149166.431025] init: smbd main process (13657) killed by TERM signal
Aug 4 07:06:38 MonsterDisk kernel: [149170.857738] nfsd: last server has exited, flushing export cache
Aug 4 07:06:40 MonsterDisk [149172.932514] init: ftpd main process (20990) killed by TERM signal
Aug 4 07:06:43 MonsterDisk [149176.287942] init: crond main process (5865) killed by TERM signal
Aug 4 07:06:49 MonsterDisk [149181.449507] init: synosnmpcd main process (21781) killed by KILL signal
Aug 4 07:06:50 MonsterDisk updater: updater.c:5483 Start of the updater...
Aug 4 07:06:50 MonsterDisk updater: updater.c:5615 ==== Start flash update ====
Aug 4 07:06:50 MonsterDisk updater: updater.c:5619 This is X86 platform
Aug 4 07:06:50 MonsterDisk updater: updater.c:5633 The SynoBoot partitions exist.
Aug 4 07:06:50 MonsterDisk updater: updater.c:3594 SYNORedBootUpdCheckAndApply(3594): Skip bootloader update, no uboot_do_upd.sh exists
Aug 4 07:06:51 MonsterDisk updater: updater.c:482 Moving [checksum.syno.tmp.21831] to [/tmp/bootmnt/checksum.syno], result[0]
Aug 4 07:06:51 MonsterDisk updater: updater.c:490 [checksum.syno.tmp.21831] is removed
Aug 4 07:06:51 MonsterDisk updater: updater.c:558 checksum updated by UpdateCksum
Aug 4 07:06:51 MonsterDisk updater: updater.c:570 file [zImage] is being copied to [/tmp/bootmnt]
Aug 4 07:06:51 MonsterDisk updater: updater.c:578 file [/tmp/bootmnt/zImage] process done.
Aug 4 07:06:51 MonsterDisk updater: updater.c:482 Moving [checksum.syno.tmp.21831] to [/tmp/bootmnt/checksum.syno], result[0]
Aug 4 07:06:51 MonsterDisk updater: updater.c:490 [checksum.syno.tmp.21831] is removed
Aug 4 07:06:51 MonsterDisk updater: updater.c:558 checksum updated by UpdateCksum
Aug 4 07:06:51 MonsterDisk updater: updater.c:570 file [rd.gz] is being copied to [/tmp/bootmnt]
Aug 4 07:06:51 MonsterDisk updater: updater.c:578 file [/tmp/bootmnt/rd.gz] process done.
Aug 4 07:06:51 MonsterDisk updater: updater.c:482 Moving [checksum.syno.tmp.21831] to [/tmp/bootmnt/checksum.syno], result[0]
Aug 4 07:06:52 MonsterDisk updater: updater.c:490 [checksum.syno.tmp.21831] is removed
Aug 4 07:06:52 MonsterDisk updater: updater.c:558 checksum updated by UpdateCksum
Aug 4 07:06:52 MonsterDisk updater: updater.c:570 file [grub_cksum.syno] is being copied to [/tmp/bootmnt]
Aug 4 07:06:52 MonsterDisk updater: updater.c:578 file [/tmp/bootmnt/grub_cksum.syno] process done.
Aug 4 07:06:52 MonsterDisk updater: updater.c:565 file [/tmp/bootmnt/updater] is being removed
Aug 4 07:06:52 MonsterDisk updater: updater.c:578 file [/tmp/bootmnt/updater] process done.
Aug 4 07:06:52 MonsterDisk updater: updater.c:565 file [/tmp/bootmnt/VERSION] is being removed
Aug 4 07:06:52 MonsterDisk updater: updater.c:578 file [/tmp/bootmnt/VERSION] process done.
Aug 4 07:06:53 MonsterDisk updater: updater.c:1470 BIOS is up to date
Aug 4 07:06:53 MonsterDisk updater: updater.c:6062 ==== Finish flash update ====
Aug 4 07:06:53 MonsterDisk updater: updater.c:6079 ==== Finish updater post-action ====
Aug 4 07:06:53 MonsterDisk updater: updater.c:6135 Congratulations!! The update has been completed!!

 

[arcade]

...und weil eh nichts mehr funktioniert... das "volume1" auch nicht mehr angemounted ist:

MonsterDisk> mount
/dev/root on / type ext4 (defaults)
/sys on /sys type sysfs (0)
none on /dev/pts type devpts (gid=4,mode=620)
/tmp on /tmp type tmpfs (0)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
none on /sys/fs/cgroup type tmpfs (uid=0,gid=0,mode=0755,size=4k)
/dev/bus/usb on /proc/bus/usb type bind (bind)
none on /sys/kernel/debug type debugfs (0)
securityfs on /sys/kernel/security type securityfs (0)
none on /proc/fs/nfsd type nfsd (0)
MonsterDisk>

...kann ich zumindest als ersten Schritt einen File-System-Check fahren... Bin auf das Endergebnis gespannt:

MonsterDisk> e2fsck -yf /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
1.41.10-2216: recovering journal
Journal transaction 5705630 was corrupt, replay was aborted.
Pass 1: Checking inodes, blocks, and sizes
...

 

[dil88]

Gute Idee, vielleicht bringt das etwas.

 

[arcade]

Filesystemcheck läuft noch... Parallel dazu hat sich ein netter Kollege von Synology gemeldet, er versucht mit dem remoteAccess den/die Fehler einzugrenzen...

MonsterDisk> e2fsck -yf /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
1.41.10-2216: recovering journal
Journal transaction 5705630 was corrupt, replay was aborted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? yes

Pass 4: Checking reference counts
Unattached inode 857808898
Connect to /lost+found? yes

Inode 857808898 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795589
Connect to /lost+found? yes

Inode 1321795589 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795591
Connect to /lost+found? yes

Inode 1321795591 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795593
Connect to /lost+found? yes

Inode 1321795593 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795596
Connect to /lost+found? yes

Inode 1321795596 ref count is 2, should be 1. Fix? yes

Pass 5: Checking group summary information
Block bitmap differences: +3431236099 +(3772580968--3772580983) -(5321428873--5321428879)
Fix? yes

 

[dil88]

Der fsck fördert auf jeden Fall einiges zutage ...

 

[arcade]

Hier das komplette Ergebnis:

MonsterDisk> e2fsck -yf /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
1.41.10-2216: recovering journal
Journal transaction 5705630 was corrupt, replay was aborted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? yes

Pass 4: Checking reference counts
Unattached inode 857808898
Connect to /lost+found? yes

Inode 857808898 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795589
Connect to /lost+found? yes

Inode 1321795589 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795591
Connect to /lost+found? yes

Inode 1321795591 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795593
Connect to /lost+found? yes

Inode 1321795593 ref count is 2, should be 1. Fix? yes

Unattached inode 1321795596
Connect to /lost+found? yes

Inode 1321795596 ref count is 2, should be 1. Fix? yes

Pass 5: Checking group summary information
Block bitmap differences: +3431236099 +(3772580968--3772580983) -(5321428873--5321428879)
Fix? yes

Free blocks count wrong for group #104713 (1530, counted=1529).
Fix? yes

Free blocks count wrong for group #115130 (1304, counted=1288).
Fix? yes

Free blocks count wrong for group #162397 (4525, counted=4532).
Fix? yes

Free blocks count wrong for group #171757 (32252, counted=32253).
Fix? yes

Free blocks count wrong (1237741426, counted=1220837913).
Fix? yes

Inode bitmap differences: +857808898 +1321795589 +1321795591 +1321795593 +1321795596
Fix? yes

Free inodes count wrong for group #104713 (8187, counted=8186).
Fix? yes

Free inodes count wrong for group #161352 (8184, counted=8180).
Fix? yes

Free inodes count wrong for group #171757 (8190, counted=8191).
Fix? yes

Free inodes count wrong (1644820383, counted=1644820337).
Fix? yes


1.41.10-2216: ***** FILE SYSTEM WAS MODIFIED *****
1.41.10-2216: 805007/1645625344 files (3.2% non-contiguous), 5361636663/6582474576 blocks
MonsterDisk>

Habe Ergebnis den Spezialisten von Synology übergeben. Sie entscheiden was getan werden kann, oder eben nicht...

 

[Dennis1002]

Auch wenn ich zu deinem aktuellen Problem nichts beitragen kann, habe ich einen Tipp für dich:
Du solltest unbedingt auf ein Raid6 umsteigen. Bei 10 Festplatten, kann gerne mal mehr als eine gleichzeitig aussteigen

 

[Tommi2day]

Bei einem Raid5 Volume über die DS+DX genügt ein Wackler am Verbindungskabel, um das ganze Volumen in Garbage zu verwandeln. Einzige sinnvolle Anwendung von nur einem Volumen über beides: man spiegelt alle Platten der DS auf die DX (Raid10).

 

[arcade]

Nochmal Glück gehabt...
Der FileSystem-Check hat das Volume wieder repariert. Da ich im Upload meines Routers und auf dem NAS keine Aktivitäten seitens Synology festellen konnte, war ich so frei und hab das Maschinchen durchgebootet.
Nach diversen Test kann ich aktuell keine Probleme mehr erkennen. Das Streaming vom NAS zu bspw. meiner Dreambox, egal ob Film, Musik, Photos funktioniert wieder fehlerfrei. Zu den beiden vorherigen Ratschlägen...
Ich habe mich ganz bewusst und nicht grundlos für das Raid5 entschieden. Die Kombi läuft bei mir seit Jahren stabil. Bisher hat eine einzige Platte Probleme bereitet und die hab ich vorsorglich tauschen können. Es existieren von fast allen Dateien Backups, aber ich werde wohl noch eine "große" (z.B. http://www.amazon.de/Seagate-Deskto...qid=1438809107&sr=1-3&keywords=8TB+Festplatte) externe USB3.0-Platte hinten ans NAS nageln...
Bezgl. des über Main- und Erweiterungseinheit aufgespannten Volumes... Die Geräte stehen bei mir so gut, da kann das Verbindungskabel nicht wackeln... Es bräuchte schon ein Erdbeben... Auch hier hatte ich mir im Vorfeld Gedanken gemacht. Ich wollte ein maxSize-Volume über alle 10Platten, muss aber eingestehen, dass die HDD-Bestückung der beiden Einheiten immer mit dem Speicherbedarf wuchs... Ursprünglich dachte ich, dass ich mit 5x 3TB locker auskomme... Damals wars egal...
Ich warte noch auf eine Meldung von Synology selbst, vermute aber, dass die Spezis wegen dem laufenden FS-Check keine weiteren Aktivitäten auf dem NAS ausgeführt haben.

Eines ist aber sicher. Vor dem Update lief das Volume stabil. Der NAS wurde letzte Woche vom Strom getrennt und am vergangenen WE problemlos wieder hochgefahren. Der Reboot nach dem Update brachte das böse Erwachen. Ob das seitens Synology nachvollzogen werden kann, bleibt abzuwarten. Ob ich allerdings zukünftig jedes offizielle DSM-Update in den NAS lade, weiß ich noch nicht genau..



MonsterDisk> mdadm --query --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Jul 21 20:50:40 2012
Raid Level : raid5
Array Size : 26329898304 (25110.15 GiB 26961.82 GB)
Used Dev Size : 2925544256 (2790.02 GiB 2995.76 GB)
Raid Devices : 10
Total Devices : 10
Persistence : Superblock is persistent

Update Time : Wed Aug 5 23:29:02 2015
State : clean
Active Devices : 10
Working Devices : 10
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

Name : MonsterDisk:2 (local to host MonsterDisk)
UUID : ee49a613:cff9a927:0a1d4323:391c2797
Events : 810260

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/sdc3
3 8 51 3 active sync /dev/sdd3
4 8 67 4 active sync /dev/sde3
7 131 99 5 active sync /dev/sdga3
6 131 115 6 active sync /dev/sdgb3
8 131 131 7 active sync /dev/sdgc3
10 131 163 8 active sync /dev/sdge3
9 131 147 9 active sync /dev/sdgd3
MonsterDisk>

MonsterDisk> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdgd3[9] sdge3[10] sdgc3[8] sdgb3[6] sdga3[7] sde3[4] sdd3[3] sdc3[2] sdb3[1]
26329898304 blocks super 1.2 level 5, 64k chunk, algorithm 2 [10/10] [UUUUUUUUUU]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[4] sde2[3]
2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4]
2490176 blocks [5/5] [UUUUU]

unused devices: <none>
MonsterDisk>

MonsterDisk> cd /volume1
MonsterDisk> ls -lisa
2 4 drwxr-xr-x 28 root root 4096 Aug 5 22:45 .
2 4 drwxr-xr-x 25 root root 4096 Aug 5 22:45 ..
846667777 4 drwxrwxrwx 5 root root 4096 Jan 1 2001 @MailScanner
1408155649 168 d--------- 15 root root 163840 Jul 26 00:08 @PC-TrueCrypt@
1092509704 4 drwxr-xr-x 2 root root 4096 Nov 7 2014 @S2S
270337 4 drwxrwxrwx 15 root root 4096 Jul 12 16:09 @appstore
1336336385 4 drwx------ 2 root root 4096 Jul 1 23:59 @autoupdate
846700545 4 drwxrwxrwx 2 root root 4096 Aug 5 22:46 @clamav
1321787393 4 drwxr-xr-x 4 root root 4096 May 13 03:47 @cloudstation
81921 4 drwxr-xr-x 4 admin users 4096 Jan 1 2001 @database
262145 4 drwxr-xr-x 2 admin users 4096 Jul 21 2012 @download
88104961 4 drwxrwxrwx 13 root root 4096 Jul 24 13:33 @eaDir
855998465 4 drwxr-xr-x 2 root root 4096 Sep 9 2013 @maillog
1336172545 4 drwxr-xr-x 16 postfix root 4096 Jun 5 09:07 @postfix
32769 4 drwxrwxrwx 4 root root 4096 Jan 1 2001 @spool
1128185857 4 drwxr-xr-x 2 root root 4096 Jul 12 16:10 @ssbackup
1446543361 4 drwxrwxrwx 6 root root 4096 Aug 5 23:27 @tmp
1092853763 4 d--------- 4 root root 4096 May 13 09:39 DM800se
88096769 4 drwxrwxrwx 5 root root 4096 May 29 09:34 PC-Backup
857776129 4 drwx------ 6 plex users 4096 May 13 09:39 Plex
1072562181 8 d--------- 4 root root 4096 May 13 09:39 SynologyBerichte
12 8 -rw------- 1 root root 7168 Aug 4 07:07 aquota.group
11 12 -rw------- 1 root root 9216 Aug 4 07:07 aquota.user
1052672005 8 d--------- 13 root root 4096 May 13 09:39 hoerbuecher
298696705 4 drwxr-xr-x 7 root root 4096 May 31 12:58 homes
13 4 drwx------ 2 root root 4096 Aug 5 11:26 lost+found
278529 4 drwxrwxrwx 7 root root 4096 May 13 09:39 music
286721 12 drwxrwxrwx 176 root root 12288 Jul 28 14:29 photo
1096040452 4 drwxrwxrwx 5 root root 4096 Aug 4 06:49 surveillance
16 8 -rw------- 1 root root 5120 May 13 09:39 synoquota.db
3186689 4 drwxrwxrwx 12 root root 4096 May 13 09:39 video
17 28 -rw-r--r-- 1 root root 28672 Jul 1 09:23 winbindd_cache.tdb

 

[arcade]

Um den Beitrag sauber abzuschliessen, hier noch ggf. interessante Auszüge aus dem Schriftwechsel mit dem Synology-Spezi:

Synology:
"allgemein kann ein Dateisystemfehler auftreten, wenn es zu einem "unkorreten Aushängen" des Dateisystems kommt. In den meißten Fällen passiert dies durch einen Stromausfall, o.ä. Genau zu ermitteln ist dies in den meißten Fällen nur sehr schwer."

meine Antwort:
"der beschriebene Sachverhalt ist mir bekannt. Tatsächlich hatten wir vor ca. 3 Wochen zu Hause einen Stromausfall, während ich im Büro war. Der NAS war aus, ich konnte Ihn aber problemlos wieder einschalten. Wie geschrieben hatte ich die Synology-DS auch während meiner Abwesenheit vorige Woche sauber „runter“ gefahren und nach Heimkehr problemlos wieder starten können. Der „volume1“-Crash erfolgte erst Tage später und das laut Log-File, unmittelbar nach dem Flashen des aktuellen DSM-Updates. Die „messages“ zeigen vor dem Einspielen des Updates den fehlerfreien Betrieb, ohne einen System-Reset oder eine andere Auffälligkeit, von mindestens 2 Tagen. Aus diesem Grund erscheint mir ein Stromausfall für mein Problem nicht als Ursache in Frage zu kommen.
...
Was ich festgestellt habe ist, dass ein Streaming über NFS an meinem Medien-Server, egal ob Video oder Musik, problemlos funktioniert.
Was nicht mehr läuft ist ein Streaming über die Synology-apps, z.B. DS video oder DS audio. So ganz korrekt hab ich es nicht ausgedrückt. Ich habe vorhin einige video-Files über FTP in die „video“-Ordnerstruktur verschoben. Die neu verschobenen Dateien lassen sich problemlos über die Apps ansprechen, aber alles vor dem „crash“ vorhandene, wird nicht mehr gefunden. Die DS audio App bspw. bittet um das Verschieben von Musikdateien in den Standart-music-Container… Wie kann ich eine Indizierung der aktuell vorhandene Files erreichen, ohne alle Dateien nochmals kopieren zu müssen. Geht so etwas auf Betriebssystemebene, evtl. als Backgroundprozess?"

Synology:
"Fehler auf dem Dateisystem durch einen Stromausfall können auch erst später auftreten. Zusammenhänge mit einem Update gibt es zumeist, weil dabei das Gerät sowie die Platten stark beansprucht werden. Bei einigen Kunden fällt beim Update eine Platte physikalisch aus. Der Fehler war schon vorher da, wurde aber im regulären Betrieb nicht "bemerkt".
Die Indizierung Ihrer Media-Daten können Sie im MedienCenter in der DSM-Systemsteuerung neu anstossen. Damit werden alle aktuellen indizies gelöscht und neu erstellt. Bitte beachten Sie, daß das Gerät dazu länger benötigt, als Ihr PC, da die Indizierung mit geringer Priorität arbeitet. Zudem kann die DS während dieser Berechung nicht in den Ruhezustand wechseln."

schönes WE ohne NAS-Crash
arcade