Hallo zusammen,
Ich bin bei RAID Fragen ziemlich unerfahren, daher ist diese Frage vielleicht etwas dumm, aber bevor ich mir unnötig Arbeit mache oder etwas zerstöre, wollte ich nachfragen, wie ich bei meinem Problem am Besten vorgehe.
Ich habe seit 2009 eine Synology DS209+ mit 2*1.5TB Platten im RAID-1 Verbund drin. DSM Version war 2.2.0942. Ich wollte diese jetzt durch 2 3TB Platten ersetzen (Hitachi Deskstar 7K3000, HDs723030ALA640) - ich weiss, dass sie nicht auf der Liste der empfohlenen Disks stehen, aber ich dachte, ich probiere es trotzdem mal. Mein erster Fehler war, dass ich kein Firmware Upgrade vornahm, sondern die alte Disk #2 durch eine der 3TB Disks ersetzte, um danach zu syncen. Nach dem Reboot wurde die vom alten DSM nicht erkannt, und natürlich war damit das RAID-1 auch nicht mehr konsistent, nachdem ich wieder die alte 1.5TB Disk als Disk #2 einsetzte. Also habe ich dann ein Upgrade auf DSM 3.0-1354 vorgenommen und hoffte, dass dies trotz dem nicht mehr konsistenten RAID-1 klappe, was es auch tat. Danach probierte ich erneut die 3TB Deskstar, und diesmal wurde sie erkannt. Ueber Nacht konnte ich dann mit eine der alten 1.5 und der neuen 3TB Platte neu syncen (über Repair), was einwandfrei klappte, und tags darauf dann auch die andere 1.5 TB Disk durch die zweite 3TB ersetzt und nochmals über Repair gesynced. Das klappte auch alles, das Volume wurde ebenfalls automatisch auf 3TB erhöht. Ich erkläre das so detailliert, weil ich dabei eventuell doch etwas falsch gemacht habe, aber soweit ich sagen kann, klappte das alles gut.
Gestern als ich die Synology neu startete, piepte er leider mit der Meldung, "Volume 1 crashed" und "Beause data consistency on this volume is not complete..." etc (leider nicht copy&pastebar). Das Filesystem wurde offenbar nur read-only gemountet. Als Erstes habe ich alle Daten gebackupped (es war ja alles noch da), ich habe ja auch noch die alten 1.5TB Disks als Zusatz Backup. Von daher also kein Verlust. Aber wo liegt der Fehler? der SMART Status beider Disks ist einwandfrei.
Ich bin bei der Suche auf http://www.synology-forum.de/showthread.html?t=510 gestossen und habe da mal ein paar Tests gemacht. Hier die Ergebnisse:
Was mir als Laie dabei auffällt (ausser den inode Error) ist, dass md2 ja 3TB gross ist (2881191064 blocks in df), mdadm aber "779639552 (743.52 GiB 798.35 GB)" als Array size ausgibt. Kann das der Grund sein, dass inodes ausserhalb dieses Ranges nicht zugreifbar sind? Der kleinste geloggte nicht zugreifbare Block findet sich aber schon bei etwa 200GB... Das System beinhaltete nicht viele Daten (nur etwa 400GB), das würde auch erklären, dass diese alle noch lesbar waren, da unter 743GB. Woher die Zahl 743GB aber herkommt, ist mir schleierhaft - ok, vielleicht war das die Hälfte der vorherigen Array size von ungefähr 1.5TB.
Was meint ihr, dollte ich mal das im obigen Thread beschrieben Verfahren ausprobiere, also etwas in der Art
Oder gibt es was Besseres (OK, ausser Volume neu machen und von Backup zurückspielen)? Sollte ich fsck.ext3 drüber laufen lassen? Oder gibt es beim Grundsetup ein Problem wegen den 3TB Platten?
Danke für Tips,
klaymen
Ich bin bei RAID Fragen ziemlich unerfahren, daher ist diese Frage vielleicht etwas dumm, aber bevor ich mir unnötig Arbeit mache oder etwas zerstöre, wollte ich nachfragen, wie ich bei meinem Problem am Besten vorgehe.
Ich habe seit 2009 eine Synology DS209+ mit 2*1.5TB Platten im RAID-1 Verbund drin. DSM Version war 2.2.0942. Ich wollte diese jetzt durch 2 3TB Platten ersetzen (Hitachi Deskstar 7K3000, HDs723030ALA640) - ich weiss, dass sie nicht auf der Liste der empfohlenen Disks stehen, aber ich dachte, ich probiere es trotzdem mal. Mein erster Fehler war, dass ich kein Firmware Upgrade vornahm, sondern die alte Disk #2 durch eine der 3TB Disks ersetzte, um danach zu syncen. Nach dem Reboot wurde die vom alten DSM nicht erkannt, und natürlich war damit das RAID-1 auch nicht mehr konsistent, nachdem ich wieder die alte 1.5TB Disk als Disk #2 einsetzte. Also habe ich dann ein Upgrade auf DSM 3.0-1354 vorgenommen und hoffte, dass dies trotz dem nicht mehr konsistenten RAID-1 klappe, was es auch tat. Danach probierte ich erneut die 3TB Deskstar, und diesmal wurde sie erkannt. Ueber Nacht konnte ich dann mit eine der alten 1.5 und der neuen 3TB Platte neu syncen (über Repair), was einwandfrei klappte, und tags darauf dann auch die andere 1.5 TB Disk durch die zweite 3TB ersetzt und nochmals über Repair gesynced. Das klappte auch alles, das Volume wurde ebenfalls automatisch auf 3TB erhöht. Ich erkläre das so detailliert, weil ich dabei eventuell doch etwas falsch gemacht habe, aber soweit ich sagen kann, klappte das alles gut.
Gestern als ich die Synology neu startete, piepte er leider mit der Meldung, "Volume 1 crashed" und "Beause data consistency on this volume is not complete..." etc (leider nicht copy&pastebar). Das Filesystem wurde offenbar nur read-only gemountet. Als Erstes habe ich alle Daten gebackupped (es war ja alles noch da), ich habe ja auch noch die alten 1.5TB Disks als Zusatz Backup. Von daher also kein Verlust. Aber wo liegt der Fehler? der SMART Status beider Disks ist einwandfrei.
Ich bin bei der Suche auf http://www.synology-forum.de/showthread.html?t=510 gestossen und habe da mal ein paar Tests gemacht. Hier die Ergebnisse:
Rich (BBCode):
SERVER> grep kernel: /var/log/messages | tail
Feb 10 22:20:22 kernel: [ 3904.485545] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=174964737, block=349929474
Feb 10 22:20:22 kernel: [ 3904.508550] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=174866433, block=349732866
Feb 10 22:20:22 kernel: [ 3904.531112] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=175095809, block=350191618
Feb 10 22:20:22 kernel: [ 3904.553668] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=174964738, block=349929474
Feb 10 22:20:22 kernel: [ 3904.576454] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=174964737, block=349929474
Feb 11 00:45:49 kernel: [12633.488494] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=139247617, block=278495234
Feb 11 00:55:00 kernel: [13184.645814] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=145358849, block=290717698
Feb 11 00:56:09 kernel: [13253.952694] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=146898945, block=293797890
Feb 11 00:56:13 kernel: [13258.022371] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=127565825, block=255131650
Feb 11 05:52:49 kernel: [31052.963064] EXT3-fs error (device md2): ext3_get_inode_loc: unable to read inode block - inode=174850049, block=349700098
SERVER> grep 'inode=' /var/log/messages | cut -f3 -d= | sort | head
202407938
202407938
202407938
SERVER> df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 2450808 449140 1976772 19% /
/tmp 257832 3044 254788 1% /tmp
/dev/md2 2881191064 225627148 2655372100 8% /volume1
SERVER> mdadm --query --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Tue May 5 13:12:02 2009
Raid Level : raid1
Array Size : 779639552 (743.52 GiB 798.35 GB)
Used Dev Size : 779639552 (743.52 GiB 798.35 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Fri Feb 11 06:05:33 2011
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : 5272041d:6919fe9e:8ed7f21e:fe4b0a5d
Events : 0.5120
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/hda3
1 8 19 1 active sync /dev/sdb3
SERVER> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid1 sda3[0] sdb3[1]
779639552 blocks [2/2] [UU]
md1 : active raid1 sda2[0] sdb2[1]
522048 blocks [2/2] [UU]
md0 : active raid1 sda1[0] sdb1[1]
2489920 blocks [2/2] [UU]
unused devices: <none>Was mir als Laie dabei auffällt (ausser den inode Error) ist, dass md2 ja 3TB gross ist (2881191064 blocks in df), mdadm aber "779639552 (743.52 GiB 798.35 GB)" als Array size ausgibt. Kann das der Grund sein, dass inodes ausserhalb dieses Ranges nicht zugreifbar sind? Der kleinste geloggte nicht zugreifbare Block findet sich aber schon bei etwa 200GB... Das System beinhaltete nicht viele Daten (nur etwa 400GB), das würde auch erklären, dass diese alle noch lesbar waren, da unter 743GB. Woher die Zahl 743GB aber herkommt, ist mir schleierhaft - ok, vielleicht war das die Hälfte der vorherigen Array size von ungefähr 1.5TB.
Was meint ihr, dollte ich mal das im obigen Thread beschrieben Verfahren ausprobiere, also etwas in der Art
Rich (BBCode):
mdadm --stop /dev/md2
mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3Oder gibt es was Besseres (OK, ausser Volume neu machen und von Backup zurückspielen)? Sollte ich fsck.ext3 drüber laufen lassen? Oder gibt es beim Grundsetup ein Problem wegen den 3TB Platten?
Danke für Tips,
klaymen
Interessant ist, dass die Filesysteme mit ext3 formatiert sind - geht das bei 3TB überhaupt? Könnte es eventuell sein, dass Partitionen dieser Grösse normalerweise mit ext4 formatiert werden, aber beim Vergrössern von ext3 Partitionen dann ein Problem entsteht, welches nicht abgefangen wird? An den Support habe ich mich noch nicht gewendet, werde ich demnächst tun, muss aber noch schauen, wie genau das geht 
