Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Raid 5 2de schijf failed tijdens rebuilden. Wat nu?

Pagina: 1
Acties:

Vraag


  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Dag allen,

Ik heb een Ubuntu 18.04 server met daarin 4 3TB schijven (3 WD green en 1 blue) in raid 5. Recent failde er eentje (WD green) welke ik een dag later heb vervangen door een nieuwe 6TB schijf (/dev/sdc) (nieuwe WD Blue). Echter bij het toevoegen van de nieuwe schijf en rebuilden van de raid faalde een andere schijf (sda3, WD Green):

code:
1
2
3
md1 : active raid5 sdc4[6] sdd4[5] sdb4[2] sda4[4](F)
      8755100160 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/2] [U_U_]
      [===================>.]  recovery = 98.9% (2887935892/2918366720) finish=11.5min speed=44009K/sec


de array stoppen en herstarten werkt helaas niet:
code:
1
2
3
4
bart@Nexus:/var/temp$ sudo mdadm --stop /dev/md1
mdadm: stopped /dev/md1
bart@Nexus:/var/temp$ sudo mdadm --assemble /dev/md1 /dev/sd[abcd]4
mdadm: /dev/md1 assembled from 2 drives and 1 spare - not enough to start the array.


Is er iemand die mij kan helpen bij wat ik nu kan doen, want ik ben bang dat ik de situatie heel makkelijk erger maak door een -f te gebruiken bijvoorbeeld Ik wil de kans dat ik een deel van mijn data kan herstellen zo veel mogelijk vergroten. ik heb liever 100% kans op 70% herstel, dan 70% kans op 100% herstel (en 30% op 0% herstel).

Alvast heel hartelijk dank! Hieronder wat aanvullende informatie:

Basis smart info. Ik heb geen self test laten draaien. Als dat nodig is hoor ik het graag.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
bart@Nexus:/$ sudo smartctl -H -i -l scterc /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-99-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD30EZRX-00D8PB0
Serial Number:    WD-WMC4N2530501
LU WWN Device Id: 5 0014ee 003d0f10b
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct  7 08:35:15 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SCT Error Recovery Control command not supported

bart@Nexus:/$ sudo smartctl -H -i -l scterc /dev/sdb
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-99-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD30EZRX-00DC0B0
Serial Number:    WD-WMC1T1438425
LU WWN Device Id: 5 0014ee 0ae2444d5
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct  7 08:37:38 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SCT Error Recovery Control command not supported


bart@Nexus:/$ sudo smartctl -H -i -l scterc /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-99-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD60EZAZ-00SF3B0
Serial Number:    WD-WX72D606KYVE
LU WWN Device Id: 5 0014ee 2bd9ccb80
Firmware Version: 80.00A80
User Capacity:    6,001,175,126,016 bytes [6.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct  7 08:38:06 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SCT Error Recovery Control command not supported

bart@Nexus:/$ sudo smartctl -H -i -l scterc /dev/sdd
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-99-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Blue
Device Model:     WDC WD30EZRZ-22Z5HB0
Serial Number:    WD-WCC4N5CJ41DC
LU WWN Device Id: 5 0014ee 2bb62e4ce
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct  7 08:38:39 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SCT Error Recovery Control command not supported


mdadm --examine. de relevante raid is md1 (md0 ga ik opheffen en hoeft niet hersteld)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
bart@Nexus:/$ sudo mdadm --detail /dev/md[01]
/dev/md0:
           Version : 1.2
        Raid Level : raid0
     Total Devices : 3
       Persistence : Superblock is persistent

             State : inactive
   Working Devices : 3

              Name : Nexus:0  (local to host Nexus)
              UUID : 8510ec8d:fd4553db:9589a0f4:d01c88ef
            Events : 254387

    Number   Major   Minor   RaidDevice

       -       8       51        -        /dev/sdd3
       -       8       19        -        /dev/sdb3
       -       8        3        -        /dev/sda3
/dev/md1:
           Version : 1.2
        Raid Level : raid0
     Total Devices : 4
       Persistence : Superblock is persistent

             State : inactive
   Working Devices : 4

              Name : Nexus:1  (local to host Nexus)
              UUID : 902f6955:5ca219ae:eada110c:87f1bc28
            Events : 238685

    Number   Major   Minor   RaidDevice

       -       8       52        -        /dev/sdd4
       -       8       36        -        /dev/sdc4
       -       8       20        -        /dev/sdb4
       -       8        4        -        /dev/sda4


lsdrv (een script dat op raid.wiki.kernel.org gesuggereerd wordt voor informatie).
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
bart@Nexus:/tmp/lsdrv/lsdrv$ sudo ./lsdrv
**Warning** The following utility(ies) failed to execute:
  pvs
  lvs
Some information may be missing.

PCI [ahci] 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode]
├scsi 0:0:0:0 ATA      WDC WD30EZRX-00D {WD-WMC4N2530501}
│└sda 2.73t [8:0] Partitioned (gpt)
│ ├sda1 47.00m [8:1] Empty/Unknown
│ ├sda2 1.86g [8:2] Empty/Unknown
│ ├sda3 9.31g [8:3] MD  (none/) (w/ sdd3,sdb3) spare 'Nexus:0' {8510ec8d-fd45-53db-9589-a0f4d01c88ef}
│ │└md0 0.00k [9:0] MD v1.2  () inactive, None (None) None {8510ec8d:fd4553db:9589a0f4:d01c88ef}
│ │                 Empty/Unknown
│ └sda4 2.72t [8:4] MD  (none/) (w/ sdb4,sdd4,sdc4) spare 'Nexus:1' {902f6955-5ca2-19ae-eada-110c87f1bc28}
│  └md1 0.00k [9:1] MD v1.2  () inactive, None (None) None {902f6955:5ca219ae:eada110c:87f1bc28}
│                   Empty/Unknown
├scsi 1:0:0:0 ATA      WDC WD30EZRX-00D {WD-WMC1T1438425}
│└sdb 2.73t [8:16] Partitioned (gpt)
│ ├sdb1 47.00m [8:17] Empty/Unknown
│ ├sdb2 1.86g [8:18] swap {18ea54db-0a83-49ac-b358-0c617238b87e}
│ ├sdb3 9.31g [8:19] MD  (none/) (w/ sdd3,sda3) spare 'Nexus:0' {8510ec8d-fd45-53db-9589-a0f4d01c88ef}
│ │└md0 0.00k [9:0] MD v1.2  () inactive, None (None) None {8510ec8d:fd4553db:9589a0f4:d01c88ef}
│ │                 Empty/Unknown
│ └sdb4 2.72t [8:20] MD  (none/) (w/ sda4,sdd4,sdc4) spare 'Nexus:1' {902f6955-5ca2-19ae-eada-110c87f1bc28}
│  └md1 0.00k [9:1] MD v1.2  () inactive, None (None) None {902f6955:5ca219ae:eada110c:87f1bc28}
│                   Empty/Unknown
├scsi 2:0:0:0 ATA      WDC WD60EZAZ-00S {WD-WX72D606KYVE}
│└sdc 5.46t [8:32] Partitioned (gpt)
│ ├sdc1 47.00m [8:33] Empty/Unknown
│ ├sdc2 1.86g [8:34] Empty/Unknown
│ ├sdc3 9.31g [8:35] Empty/Unknown
│ ├sdc4 2.72t [8:36] MD  (none/) (w/ sdb4,sda4,sdd4) spare 'Nexus:1' {902f6955-5ca2-19ae-eada-110c87f1bc28}
│ │└md1 0.00k [9:1] MD v1.2  () inactive, None (None) None {902f6955:5ca219ae:eada110c:87f1bc28}
│ │                 Empty/Unknown
│ └sdc5 2.73t [8:37] ext4 'Backup' {2555f347-1407-464c-9fb0-41dff62b6c75}
│  └Mounted as /dev/sdc5 @ /mnt/backup
├scsi 3:0:0:0 ATA      WDC WD30EZRZ-22Z {WD-WCC4N5CJ41DC}
│└sdd 2.73t [8:48] Partitioned (gpt)
│ ├sdd1 47.00m [8:49] Empty/Unknown
│ ├sdd2 1.86g [8:50] Empty/Unknown
│ ├sdd3 9.31g [8:51] MD  (none/) (w/ sdb3,sda3) spare 'Nexus:0' {8510ec8d-fd45-53db-9589-a0f4d01c88ef}
│ │└md0 0.00k [9:0] MD v1.2  () inactive, None (None) None {8510ec8d:fd4553db:9589a0f4:d01c88ef}
│ │                 Empty/Unknown
│ └sdd4 2.72t [8:52] MD  (none/) (w/ sdb4,sda4,sdc4) spare 'Nexus:1' {902f6955-5ca2-19ae-eada-110c87f1bc28}
│  └md1 0.00k [9:1] MD v1.2  () inactive, None (None) None {902f6955:5ca219ae:eada110c:87f1bc28}
│                   Empty/Unknown
└scsi 4:0:0:0 ATA      KINGSTON SA400S3 {50026B76835C7254}
 └sde 111.79g [8:64] Partitioned (gpt)
  ├sde1 49.00m [8:65] Empty/Unknown
  ├sde2 4.00g [8:66] swap {aa7dfd5d-580e-44b0-86e8-9375c2063e18}
  └sde3 107.74g [8:67] ext4 {14a01a78-91b7-46d4-9a56-5155f669ffac}
   └Mounted as /dev/sde3 @ /
Other Block Devices
├loop0 0.00k [7:0] Empty/Unknown
├loop1 0.00k [7:1] Empty/Unknown
├loop2 0.00k [7:2] Empty/Unknown
├loop3 0.00k [7:3] Empty/Unknown
├loop4 0.00k [7:4] Empty/Unknown
├loop5 0.00k [7:5] Empty/Unknown
├loop6 0.00k [7:6] Empty/Unknown
└loop7 0.00k [7:7] Empty/Unknown


/proc/mdstat
code:
1
2
3
4
5
6
7
bart@Nexus:/var/temp$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdd4[5](S) sdc4[6](S) sda4[4](S) sdb4[2](S)
      11673468928 blocks super 1.2

md0 : inactive sdb3[2](S) sdd3[3](S) sda3[4](S)
      29277696 blocks super 1.2



En tenslotten mdadm --examine
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
bart@Nexus:/var/temp$ sudo mdadm --examine /dev/sd[a-d]4
/dev/sda4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 902f6955:5ca219ae:eada110c:87f1bc28
           Name : Nexus:1  (local to host Nexus)
  Creation Time : Sat Dec  8 01:58:59 2012
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836734464 (2783.17 GiB 2988.41 GB)
     Array Size : 8755100160 (8349.51 GiB 8965.22 GB)
  Used Dev Size : 5836733440 (2783.17 GiB 2988.41 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=1024 sectors
          State : clean
    Device UUID : 6ba5730e:5227ebc1:477140ab:b0811434

    Update Time : Wed Oct  7 07:41:24 2020
       Checksum : 8291aa19 - correct
         Events : 236217

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 902f6955:5ca219ae:eada110c:87f1bc28
           Name : Nexus:1  (local to host Nexus)
  Creation Time : Sat Dec  8 01:58:59 2012
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836734464 (2783.17 GiB 2988.41 GB)
     Array Size : 8755100160 (8349.51 GiB 8965.22 GB)
  Used Dev Size : 5836733440 (2783.17 GiB 2988.41 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=1024 sectors
          State : clean
    Device UUID : 07b232c4:f36c10f2:81210d6e:eb9304b0

    Update Time : Wed Oct  7 08:18:42 2020
       Checksum : a734d11d - correct
         Events : 238685

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : A.A. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x8
     Array UUID : 902f6955:5ca219ae:eada110c:87f1bc28
           Name : Nexus:1  (local to host Nexus)
  Creation Time : Sat Dec  8 01:58:59 2012
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836734464 (2783.17 GiB 2988.41 GB)
     Array Size : 8755100160 (8349.51 GiB 8965.22 GB)
  Used Dev Size : 5836733440 (2783.17 GiB 2988.41 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=261864 sectors, after=1024 sectors
          State : clean
    Device UUID : 79fda34b:cd81e150:f1c36f8f:a3182c64

    Update Time : Wed Oct  7 08:18:42 2020
  Bad Block Log : 512 entries available at offset 264 sectors - bad blocks present.
       Checksum : 630959a4 - correct
         Events : 238685

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : spare
   Array State : A.A. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 902f6955:5ca219ae:eada110c:87f1bc28
           Name : Nexus:1  (local to host Nexus)
  Creation Time : Sat Dec  8 01:58:59 2012
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836734464 (2783.17 GiB 2988.41 GB)
     Array Size : 8755100160 (8349.51 GiB 8965.22 GB)
  Used Dev Size : 5836733440 (2783.17 GiB 2988.41 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=261864 sectors, after=1024 sectors
          State : clean
    Device UUID : 30cc6949:f6de1fe6:e2547077:279dd5bb

    Update Time : Wed Oct  7 08:18:42 2020
  Bad Block Log : 512 entries available at offset 264 sectors
       Checksum : 35b79af1 - correct
         Events : 238685

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : A.A. ('A' == active, '.' == missing, 'R' == replacing)

[ Voor 29% gewijzigd door Berrick op 07-10-2020 15:26 ]

When someone beats you with a flaslight, you make light shine in all directions.

Beste antwoord (via Berrick op 11-10-2020 15:34)


  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Dit werkt prima hier - met -o voor read only en gewoon met bitmap:

# mdadm --create /dev/md0 -n 3 -l 5 -o --data-offset 131072 /dev/loop{3,4,5}

# mdadm --examine /dev/loop4
/dev/loop4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 2d4a053a:463897a9:eca176a8:64d2c233
           Name : localhost:0  (local to host localhost)
  Creation Time : Sun Oct 11 12:37:07 2020
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 6442188800 (3071.88 GiB 3298.40 GB)
     Array Size : 6442188800 (6143.75 GiB 6596.80 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=0 sectors
          State : clean
    Device UUID : fde53dbf:ae44a857:e82c4d06:b4b7ddb7

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Oct 11 12:37:07 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 93062df - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AA. ('A' == active, '.' == missing, 'R' == replacing)


Ander goed nieuws: de bitmap is eigenlijk ook helemaal niet zo groot, die 65535K slaat op de ruimte van een chunk in de bitmap, niet de bitmap zelf. Wellicht is de data daarmee nog gewoon intact.

Alle reacties


  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

In hoeverre is die 2e drive echt stuk?
Kun je de smart data posten van de overgebleven 3 schijven met smartctl -a <schijf>? De huidige info zegt niets.

Overigens is de vraag of je beter - als de data echt belangrijk is - naar een recovery bedrijf kunt gaan en de kosten accepteert.

  • Mijzelf
  • Registratie: September 2004
  • Niet online
Volgens jouw 'mdadm --detail /dev/md1' is de array raid0. Dat klopt niet met de andere listings, dus de output van
mdadm --examine /dev/sd[abcd]4
is boeiender.

Overigens zal de rebuild gestopt zijn omdat er een I/O error optrad in sda4. Je hebt nu 2 members die in hun header de vlag 'failed' hebben staan, je oorspronkelijke sdc4, en sda4. Of die schijven echt onbetrouwbaar zijn zou smart kunnen vertellen.

Je kunt de array opnieuw creëren met de oorspronkelijke settings (die mdadm --examine moet geven) waarbij je natuurlijk goed op de volgorde van de schijven moet letten. Daarbij kun je 1 member als 'missing' opgeven, die kun je dan later toevoegen. Zodra er weer een I/O error optreed wordt er een disk uit de array gewipt, en is hij weer down. Die I/O error kun je voorkomen door de slechte disk eerst te klonen met ddrescue naar een nieuwe disk. Dan kan er op de nieuwe disk een foutje staan, maar op die plek treed geen I/O error meer op.

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Dank voor de reacties, ik heb de --examine toegevoegd aan de startpost. Hier de smartctl -a output:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
bart@Nexus:/var/temp$ sudo smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-99-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD30EZRX-00D8PB0
Serial Number:    WD-WMC4N2530501
LU WWN Device Id: 5 0014ee 003d0f10b
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct  7 15:35:26 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (40020) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 401) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x7035) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       1052
  3 Spin_Up_Time            0x0027   180   178   021    Pre-fail  Always       -       5991
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       48
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   027   027   000    Old_age   Always       -       53897
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       47
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       15
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       2807075
194 Temperature_Celsius     0x0022   114   100   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       7
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       4
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   199   199   000    Old_age   Offline      -       407

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      3584         -
# 2  Short offline       Completed without error       00%      3577         -
# 3  Extended offline    Aborted by host               90%      3577         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Ik zal even een smartctl selftest op sda draaien. Die oude sdc was overigens wel echt kapot een failde ook de selftest. :crossing_fingers:
Zodra er weer een I/O error optreed wordt er een disk uit de array gewipt, en is hij weer down. Die I/O error kun je voorkomen door de slechte disk eerst te klonen met ddrescue naar een nieuwe disk. Dan kan er op de nieuwe disk een foutje staan, maar op die plek treed geen I/O error meer
Ja dit is een goed idee. Ik heb nog een schijf besteld dus dit kan ik morgen proberen.

[ Voor 82% gewijzigd door Berrick op 07-10-2020 15:36 ]

When someone beats you with a flaslight, you make light shine in all directions.


  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Self test is al gestopt, helaas (zie hieronder). Volgende stap dus rescue dd naar de nieuwe schijf? Wat is de kans van slagen hierop?

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
bart@Nexus:/var/temp$ sudo smartctl -a /dev/sda
[sudo] password for bart:
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-99-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Green
Device Model:     WDC WD30EZRX-00D8PB0
Serial Number:    WD-WMC4N2530501
LU WWN Device Id: 5 0014ee 003d0f10b
Firmware Version: 80.00A80
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Oct  7 15:59:07 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      ( 121) The previous self-test completed having
                                        the read element of the test failed.
Total time to complete Offline
data collection:                (40020) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 401) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x7035) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       1052
  3 Spin_Up_Time            0x0027   180   178   021    Pre-fail  Always       -       5991
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       48
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   027   027   000    Old_age   Always       -       53897
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       47
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       15
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       2807077
194 Temperature_Celsius     0x0022   114   100   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       7
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       4
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   199   199   000    Old_age   Offline      -       407

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     53897         1504505888
# 2  Extended offline    Completed without error       00%      3584         -
# 3  Short offline       Completed without error       00%      3577         -
# 4  Extended offline    Aborted by host               90%      3577         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

When someone beats you with a flaslight, you make light shine in all directions.


  • Mijzelf
  • Registratie: September 2004
  • Niet online
Berrick schreef op woensdag 7 oktober 2020 @ 16:05:
Volgende stap dus rescue dd naar de nieuwe schijf? Wat is de kans van slagen hierop?
Tamelijk groot. En je hebt 2 kansen. De laatste disk die doodging, en de oorspronkelijke. Met ieder van hen zou je de array moeten kunnen herstellen. Vooropgesteld dat je geen grote schrijfacties hebt gedaan nadat de array degradeerde. Anders blijft alleen de laatste over.

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Dank!

Wat zijn precies de vervolgstappen?
- Partitietabel kopiëren naar nieuwe schijf (/dev/sdf)
- ddrescue /dev/sda4 /dev/sdf4 (of beter stap 1 over slaan en ddrescue doen op schijf niveau? Merk op dat de nieuwe schijf 2x zo groot is)
- mdadm - - assemble /dev/md1 /dev/sd[bcdf]4 -f?

Of moet ik het eerst met 3 schijven doen en (dus die sdc nog even er uit laten)? Zo ja hoe doe ik dat?En maakt de volgorde van de letters nog uit in de assemble opdracht?

When someone beats you with a flaslight, you make light shine in all directions.


  • Mijzelf
  • Registratie: September 2004
  • Niet online
Ik zou ddrescue op schijfniveau draaien. Je kunt de array niet meer assembleren, omdat de headers niet meer overeenkomen. Daarom moet hij opnieuw gecreëerd worden.
mdadm --create /dev/md1 --metadata=1.2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric --data-offset=262144 /dev/sdd4 missing /dev/sdb4 /dev/sda4
gebaseerd op jouw mdadm --examine.

Wanneer je de schijf gekopieerd hebt, en de schijven weer allemaal aan je PC hangen, zou ik nog eens mdadm --examine runnen, en goed naar de 'Device Role' kijken om de volgorde van de schijven goed te hebben.

  • Renault
  • Registratie: Januari 2014
  • Laatst online: 30-11 16:07
Interessant leesvoer! _/-\o_

Ik hoop dat het uiteindelijk lukt!

[ Voor 39% gewijzigd door Renault op 07-10-2020 23:17 ]


  • nelizmastr
  • Registratie: Maart 2010
  • Laatst online: 21:40

nelizmastr

Goed wies kapot

Het is dus geen optie om een backup terug te zetten? Lijkt me dat dat de snelste oplossing is wanneer herstel van de array niet meer wil.

Is die niet aanwezig, dan na de rescue een backup oplossing voor de array gaan regelen, dan heb je altijd een kopie achter de hand.

I reject your reality and substitute my own - R7 5800X3D - B550M PG Riptide - 32GB Ballistix DDR4-3600 @ C15 - RX7800XT - V750 Gold


  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Berrick schreef op woensdag 7 oktober 2020 @ 20:55:
Dank!

Wat zijn precies de vervolgstappen?
- Partitietabel kopiëren naar nieuwe schijf (/dev/sdf)
- ddrescue /dev/sda4 /dev/sdf4 (of beter stap 1 over slaan en ddrescue doen op schijf niveau? Merk op dat de nieuwe schijf 2x zo groot is)
- mdadm - - assemble /dev/md1 /dev/sd[bcdf]4 -f?

Of moet ik het eerst met 3 schijven doen en (dus die sdc nog even er uit laten)? Zo ja hoe doe ik dat?En maakt de volgorde van de letters nog uit in de assemble opdracht?
Het is denk ik handiger om te ddrescuen naar een extra partitie/filesystem op de resterende ruimte van een 6 TB disk.

Na de ddrescue zou ik even kritisch kijken naar de puzzelstukjes dat je hebt: het aantal bad sectors op de disk, maar ook de huidige sdc in combinatie met de failed sdc. Aangezien je rebuild tot 98,9% is gekomen: als de failed-sdc niet helemaal stuk is, dan kun je die wellicht nog gebruiken om de bad sectors van sda te berekenen.

Vereist handwerk/scripting, maar dat is iets waar de suggestie van @Mijzelf nog niet in voorziet: nadeel daarvan is dat alle bad sectors op sda resulteren in misgecalculeerde sectors op de array, en dus alsnog corruptie op de uiteindelijke array oplevert. Of dat het waard is hangt helemaal af van het aantal bad sectors en/of je kunt bepalen waar ze zitten in het filesystem op je array.

En z'n oplossing lijkt wat spannend in de zin dat je je array vernietigt als je de drivevolgorde fout opgeeft. Ik vraag me af of er geen betere manier is (RAID metadata updaten op sda bijvoorbeeld). Zou in ieder geval de originele RAID metadata backuppen voor je zoiets doet.

Wat overigens ook opvalt uit je mdadm dumps: je hagelnieuwe sdc lijkt een bad blocks list te hebben. Zie ook: Debian-installer, mdadm configuration and the Bad Blocks Controversy (daar beschrijven ze een bug bij het rebuilden die wel eens van toepassing zou kunnen zijn - namelijk dat de bbl ten onrechte wordt overgenomen)
nelizmastr schreef op donderdag 8 oktober 2020 @ 07:29:
Het is dus geen optie om een backup terug te zetten? Lijkt me dat dat de snelste oplossing is wanneer herstel van de array niet meer wil.

Is die niet aanwezig, dan na de rescue een backup oplossing voor de array gaan regelen, dan heb je altijd een kopie achter de hand.
Geinige open deur, maar ik vraag me af hoeveel thuisgebruikers met RAID arrays ook een backup van hun gehele array hebben. Ik vermoed niet veel - ook al is de array hier zo oud dat 3x3 TB inmiddels op één enkele disk past.

Wellicht logischer om de écht belangrijke data te backuppen, en dan is het natuurlijk altijd aardig als je je Linux isos nog terug weet te toveren.

[ Voor 14% gewijzigd door Thralas op 08-10-2020 08:28 ]


  • nelizmastr
  • Registratie: Maart 2010
  • Laatst online: 21:40

nelizmastr

Goed wies kapot

Thralas schreef op donderdag 8 oktober 2020 @ 08:25:
[...]

[...]


Geinige open deur, maar ik vraag me af hoeveel thuisgebruikers met RAID arrays ook een backup van hun gehele array hebben. Ik vermoed niet veel - ook al is de array hier zo oud dat 3x3 TB inmiddels op één enkele disk past.

Wellicht logischer om de écht belangrijke data te backuppen, en dan is het natuurlijk altijd aardig als je je Linux isos nog terug weet te toveren.
Allicht een open deur inderdaad, maar mijns inziens kan de data geen waarde hebben als er geen back-up aanwezig is. Een back-up is immers bedoeld om een kopie van de data veilig te kunnen stellen in geval van hardwarefalen of een andere catastrofe.

Er zijn een paar takeaways:

- Consumentenschijven koop je vrijwel altijd uit dezelfde batch - schijf 1 kapot, dan gaat meestal schijf 2 ook op korte termijn.
- Rebuilden van RAID5 arrays wordt risicovoller naar mate de grootte van de schijven toeneemt, omdat de rest langer zwaarder belast wordt tijdens deze operatie.

Dit zijn mijns inziens valide redenen om aan te nemen dat iemand een back-up achter de hand heeft van alles of in ieder geval de belangrijkste data.

I reject your reality and substitute my own - R7 5800X3D - B550M PG Riptide - 32GB Ballistix DDR4-3600 @ C15 - RX7800XT - V750 Gold


  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Thralas schreef op donderdag 8 oktober 2020 @ 08:25:
Het is denk ik handiger om te ddrescuen naar een extra partitie/filesystem op de resterende ruimte van een 6 TB disk.
Ja dat kan ik wel doen, de resterende schijfruimte is groot genoeg. Ik heb daar ook al eerder naar gekeken, maar ik kwam er niet uit hoe ik de partitie identiek maak aan de bestaande sdX4 partities. Of maakt het niet uit als de sdc5 groter is dan die sda4 die ik ddrescue?
Thralas schreef op donderdag 8 oktober 2020 @ 08:25:
Na de ddrescue zou ik even kritisch kijken naar de puzzelstukjes dat je hebt: het aantal bad sectors op de disk, maar ook de huidige sdc in combinatie met de failed sdc. Aangezien je rebuild tot 98,9% is gekomen: als de failed-sdc niet helemaal stuk is, dan kun je die wellicht nog gebruiken om de bad sectors van sda te berekenen.

Vereist handwerk/scripting, maar dat is iets waar de suggestie van @Mijzelf nog niet in voorziet: nadeel daarvan is dat alle bad sectors op sda resulteren in misgecalculeerde sectors op de array, en dus alsnog corruptie op de uiteindelijke array oplevert. Of dat het waard is hangt helemaal af van het aantal bad sectors en/of je kunt bepalen waar ze zitten in het filesystem op je array.
Kan je wat tips /referenties geven hoe ik daarmee aan de slag kan gaan, want ik heb geen ervaring met bitwise manipulatie van data. Is de voorgestelde oplossing van @Mijzelf een "no-regret" oplossing (mits ik de volgorde van de schrijven goed krijg) of kan ik het daarmee verergeren? De volgorde staat inmiddels weergegeven in de --examine. En ik vertrouw mdadm meer dan mezelf (niet te verwarren met de user Mijzelf :P), hoewel handwerk / scripting natuurlijk wel een stuk bevredigender is als het lukt :).

Hoe kan ik bepalen hoeveel bad sectors er per partitie zijn, en waar ze op de schijf zitten? Overigens, als ik handmatig / met script de nieuwe sdc ga gebruiken om de badblocks van de sda in te vullen, moet ik dan alsnog weten wat de volgorde van de schijven is (en de correcte logica handmatig toepassen)? Heeft het niet meer kans van slagen om te proberen om op basis van de 98.9% nieuwe sdc en de oude sdc een 3e sdc te maken, indien de laatste 1.1% op de oude sdc nog ok is? dan is het een kwestie van de bits 1 op 1 doorzetten (hoewel ik dus nog steeds geen idee heb hoe dat zou moeten).
nelizmastr schreef op donderdag 8 oktober 2020 @ 08:52:
[...]


Allicht een open deur inderdaad, maar mijns inziens kan de data geen waarde hebben als er geen back-up aanwezig is. Een back-up is immers bedoeld om een kopie van de data veilig te kunnen stellen in geval van hardwarefalen of een andere catastrofe.

Er zijn een paar takeaways:

- Consumentenschijven koop je vrijwel altijd uit dezelfde batch - schijf 1 kapot, dan gaat meestal schijf 2 ook op korte termijn.
- Rebuilden van RAID5 arrays wordt risicovoller naar mate de grootte van de schijven toeneemt, omdat de rest langer zwaarder belast wordt tijdens deze operatie.

Dit zijn mijns inziens valide redenen om aan te nemen dat iemand een back-up achter de hand heeft van alles of in ieder geval de belangrijkste data.
Dat data waarvan geen back-up is geen waarde kan hebben vind ik te kort door de bocht. Wel minder waarde, en gelukkig heb ik mijn echt waardevolle data dan ook geback-upped, en heb ik mijn OS recentelijk overgezet naar een SSD (welke ik dan ook weer back-up). Dat gezegd hebbende wil ik toch heel graag deze data weer zo veel mogelijk herstellen. wat betreft je takeaways: helemaal mee eens en ik wou dat ik dat 9 jaar geleden wist.. Ik heb nu de nieuwe schijven opzettelijk bij verschillende winkels besteld.

When someone beats you with a flaslight, you make light shine in all directions.


  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

nelizmastr schreef op donderdag 8 oktober 2020 @ 08:52:
[...]


Allicht een open deur inderdaad, maar mijns inziens kan de data geen waarde hebben als er geen back-up aanwezig is. Een back-up is immers bedoeld om een kopie van de data veilig te kunnen stellen in geval van hardwarefalen of een andere catastrofe.

Er zijn een paar takeaways:

- Consumentenschijven koop je vrijwel altijd uit dezelfde batch - schijf 1 kapot, dan gaat meestal schijf 2 ook op korte termijn.
Ik vraag me eigenlijk af of dit waar is. Het is een volkswijsheid maar ik ben niet bekend met bronnen. Ik zal zelf ook eens zoeken.

Ik denk dat het eerder het aantal bedrijfsuren uitmaakt.
- Rebuilden van RAID5 arrays wordt risicovoller naar mate de grootte van de schijven toeneemt, omdat de rest langer zwaarder belast wordt tijdens deze operatie.
Ik denk dat met name het aantal schijven in een array het primaire risico bepaald. Wat heb je liever: 3 x 12 TB of 6 x 6TB ?

De rebuild met 6TB schijven gaat sneller, maar de kans op 2e uitval is veel groter. Ik zou voor de 3 x 12 schijven gaan (niet voor performance natuurlijk).

Ook hier geldt: hoe groot is ieder risico nu werkelijk?
Dit zijn mijns inziens valide redenen om aan te nemen dat iemand een back-up achter de hand heeft van alles of in ieder geval de belangrijkste data.
De definitie van belangrijke data is data waarvan een recente backup is gemaakt. Het is heel zwart-wit. :D

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
@Q In mijn n=1 steekproef gaat die volkswijsheid wel op, want dit is precies wat er bij mij gebeurd is.

Mijn idee om sdc te gaan herbouwen werkt natuurlijk niet omdat dat de eeste failed disk is geweest en het array daarna nog een tijdje heeft doorgedraaid, dus die gaat sowieso niet meer in sync zijn.

Ik ga dus toch aan de slag met het plan van @Mijzelf door om te beginnen een ddrescue op schijfniveau van /sda naar mijn nieuwe schijf te maken, tenzij @Thralas met wat meer duiding komt, want ik weet niet hoe ik zijn voorgestelde oplossing in de praktijk moet uitvoeren.

Het zal wel even duren, ik zet vannacht eerst de ddrescue aan, en heb pas morgenavond weer tijd, dus mochten er nog ideeen of aanvullingen zijn hoor ik het graag!

When someone beats you with a flaslight, you make light shine in all directions.


  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

Berrick schreef op donderdag 8 oktober 2020 @ 23:29:
@Q In mijn n=1 steekproef gaat die volkswijsheid wel op, want dit is precies wat er bij mij gebeurd is.
Ik heb zo mijn twijfels of je die conclusie zo snel kunt trekken.

Het valt mij op dat de smart data zoveel bad sectors al bevat, die mogelijk in een eerder stadium al opgemerkt hadden kunnen worden, waardoor er mogelijk niets aan de hand zou zijn geweest.

Het is misschien niet altijd een leuke discussie, maar soms moet helaas de oorzaak meer bij de setup gezocht worden en niet bij factoren als 'schijven uit dezelfde batch'.

Natuurlijk is dat gelul achteraf waar jij niets mee kunt en ik bedoel het niet beschuldigend of negatief. En misschien is dit topic ook niet de juiste plek voor deze 'terzijde' discussie.




Ik ben geen expert met het oplossen van gefaalde RAID arrays. Als het mij zou overkomen zou ik de initieel gefaalde drive laten voor wat het is. Die is niet meer in sync.

Van de overgebleven drie drives zou ik allemaal een DDrescue kopie maken naar een image op andere storage.

Dus nooit met de originele schijven oplossingen uitproberen. Alleen met de images van de schijven werken.

Helaas heb je daar aardig storage voor nodig (tijdelijk). Maar dat is dan de prijs voor een kans op veilige recovery. Of je moet iemand anders weten met voldoende space...

  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Berrick schreef op donderdag 8 oktober 2020 @ 19:51:
Ja dat kan ik wel doen, de resterende schijfruimte is groot genoeg. Ik heb daar ook al eerder naar gekeken, maar ik kwam er niet uit hoe ik de partitie identiek maak aan de bestaande sdX4 partities. Of maakt het niet uit als de sdc5 groter is dan die sda4 die ik ddrescue?
Je kunt het beste een filesystem op de partitie zetten en naar een file ddrescue'en. Dan is de exacte grootte van de partitie ook niet relevant, als hij maar groot genoeg is om de hele image te kunnen bevatten.

Dat vind ik in ieder geval een stuk handiger werken dan partities met exact de juiste grootte.
Kan je wat tips /referenties geven hoe ik daarmee aan de slag kan gaan, want ik heb geen ervaring met bitwise manipulatie van data. Is de voorgestelde oplossing van @Mijzelf een "no-regret" oplossing (mits ik de volgorde van de schrijven goed krijg) of kan ik het daarmee verergeren?
Die oplossing is prima. Het haalt alleen niet het onderste uit de kan vanwege de bad sectors op sda. Hoe erg dat is is helemaal afhankelijk van het aantal bad sectors.

Eerst imagen met ddrescue dus. Dat is altijd het belangrijkste bij bad sectors.
Hoe kan ik bepalen hoeveel bad sectors er per partitie zijn, en waar ze op de schijf zitten?
Dat gaat ddrescue je vertellen; de logfile bevat een overzicht van areas en/of sectors die hij niet kon lezen. In principe machineleesbaar, maar je kunt hem vast een lijst van sectoren laten uitspugen.
Heeft het niet meer kans van slagen om te proberen om op basis van de 98.9% nieuwe sdc en de oude sdc een 3e sdc te maken, indien de laatste 1.1% op de oude sdc nog ok is?
Dat is inderdaad waar nog wat te halen valt. De 1.1% is echter mogelijk verouderd ten opzichte van de 'huidge' data. Voor alle bad sectors op sda binnen 98,9% van de schijf heb je als het goed is gewoon parity in de vorm van sdc.

Om zelf de missende sectoren te reconstrueren zijn weinig voorbeelden beschikbaar, vrees ik. De layout is echter niet zo complex. Left symmetric, met een chunk size van 512k. Parityberekening is simpelweg een xor van alle chunks in een row.

Je zou het RAID reconstrueren deels kunnen omzeilen door de array ook eens te createn met sda missing en dan specifiek de sectoren van de resulterende array kopiëren daar waar hij anders een bad sector van sda zou gebruiken. Maar ook dat vereist flink wat uitzoekwerk.

En @Q's opmerking is zeer terecht, eigenlijk wil je dit alles sowieso op basis van images doen. Ook daar kun je omheen werken: Fun with device mapper snapshots (writes naar een CoW device dmv. device mapper snapshots), maar dat vereist ook wat handwerk. Stelt je evt. wel in staat om te experimenteren met mdadm zonder het risico de originele schijven (of images) om zeep te helpen.

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Dank voor de reacties. ddrescue sda->sdf gaf wonderbaarlijk genoeg 0 bad sectors aan. Ik durfde daarom wel aan (met de nieuwe schijf sdf ipv sda):

bart@Nexus:/mnt$ sudo mdadm --create /dev/md2 --metadata=1.2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric --data-offset=262144 /dev/sdd4 missing /dev/sdb4 /dev/sdf4
mdadm: /dev/sdd4 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Dec  8 01:58:59 2012
mdadm: /dev/sdb4 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Dec  8 01:58:59 2012
mdadm: /dev/sdf4 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Dec  8 01:58:59 2012
Continue creating array? y
mdadm: array /dev/md2 started.
bart@Nexus:/mnt$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid5 sdf4[3] sdb4[2] sdd4[0]
      8754708480 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [U_UU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

unused devices: <none>
bart@Nexus:/mnt$ sudo mount /dev/md2 /mnt/temp2
mount: /mnt/temp2: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error.
bart@Nexus:/mnt$ sudo mount -t ext4 /dev/md2 /mnt/temp2/
mount: /mnt/temp2: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error.


Helaas, er gaat iets mis. Ik heb de md2 snel weer gestopt. Maar wat gaat hier mis? ik ben er zeker van dat dit de goede volgorde van schijven is. Wat kan er aan de hand zijn?

When someone beats you with a flaslight, you make light shine in all directions.


Verwijderd

Q schreef op donderdag 8 oktober 2020 @ 23:00:
[...]


Ik vraag me eigenlijk af of dit waar is. Het is een volkswijsheid maar ik ben niet bekend met bronnen. Ik zal zelf ook eens zoeken.

Ik denk dat het eerder het aantal bedrijfsuren uitmaakt.


[...]


Ik denk dat met name het aantal schijven in een array het primaire risico bepaald. Wat heb je liever: 3 x 12 TB of 6 x 6TB ?

De rebuild met 6TB schijven gaat sneller, maar de kans op 2e uitval is veel groter. Ik zou voor de 3 x 12 schijven gaan (niet voor performance natuurlijk).

Ook hier geldt: hoe groot is ieder risico nu werkelijk?


[...]


De definitie van belangrijke data is data waarvan een recente backup is gemaakt. Het is heel zwart-wit. :D
Doe mij maar de 6x6TB dan maak ik er een RAID6 array van zonder dat ik er 12TB schijf bij moet kopen :)

RAID5 is voor grote arrays eigenlijk al niet genoeg meer om de continuiteit te garanderen, simpelweg omdat de rebuilds te lang duren en er dus toch lange onderbrekingen zijn. En dat is toch echt de primaire functie van een raid array, zorgen dat je snel weer up and running bvent zonder de (langzame) backup terug te hoeven zetten.

  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

Verwijderd schreef op vrijdag 9 oktober 2020 @ 18:23:
[...]

Doe mij maar de 6x6TB dan maak ik er een RAID6 array van zonder dat ik er 12TB schijf bij moet kopen :)
Grappig, maar het gaat wel voorbij aan mijn punt: waar is het onderzoek dat ons getallen geeft over de daadwerkelijke risico’s?
RAID5 is voor grote arrays eigenlijk al niet genoeg meer om de continuiteit te garanderen, simpelweg omdat de rebuilds te lang duren en er dus toch lange onderbrekingen zijn. En dat is toch echt de primaire functie van een raid array, zorgen dat je snel weer up and running bvent zonder de (langzame) backup terug te hoeven zetten.
Maar RAID5 was al nooit een goed idee voor grote arrays. Maar alles is een trade-off.

  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

Berrick schreef op vrijdag 9 oktober 2020 @ 18:13:
Dank voor de reacties. ddrescue sda->sdf gaf wonderbaarlijk genoeg 0 bad sectors aan. Ik durfde daarom wel aan (met de nieuwe schijf sdf ipv sda):

Helaas, er gaat iets mis. Ik heb de md2 snel weer gestopt. Maar wat gaat hier mis? ik ben er zeker van dat dit de goede volgorde van schijven is. Wat kan er aan de hand zijn?
Dat je data nu echt unrecoverable is.

  • Mijzelf
  • Registratie: September 2004
  • Niet online
Berrick schreef op vrijdag 9 oktober 2020 @ 18:13:
Maar wat gaat hier mis? ik ben er zeker van dat dit de goede volgorde van schijven is. Wat kan er aan de hand zijn?
Hoe ziet de 'mdadm --examine' van de nieuwe members eruit?

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Zie hieronder. sdc4 zit er voor de vorm ook bij maar maakt dus nog geen onderdeel van md2.


bart@Nexus:/$ sudo mdadm --examine /dev/sd[bcdf]4
[sudo] password for bart:
/dev/sdb4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 40740f08:0fe9b96d:46a02dd5:14e5a955
           Name : Nexus:2  (local to host Nexus)
  Creation Time : Fri Oct  9 17:46:47 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524208 sectors, after=0 sectors
          State : clean
    Device UUID : 810379b5:159b855e:8e5341f1:9ee5d5f9

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Oct  9 17:46:47 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 3562b9b9 - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x8
     Array UUID : 902f6955:5ca219ae:eada110c:87f1bc28
           Name : Nexus:1  (local to host Nexus)
  Creation Time : Sat Dec  8 01:58:59 2012
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836734464 (2783.17 GiB 2988.41 GB)
     Array Size : 8755100160 (8349.51 GiB 8965.22 GB)
  Used Dev Size : 5836733440 (2783.17 GiB 2988.41 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=261864 sectors, after=1024 sectors
          State : clean
    Device UUID : 79fda34b:cd81e150:f1c36f8f:a3182c64

    Update Time : Wed Oct  7 08:18:42 2020
  Bad Block Log : 512 entries available at offset 264 sectors - bad blocks present.
       Checksum : 630959a4 - correct
         Events : 238685

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : spare
   Array State : A.A. ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 40740f08:0fe9b96d:46a02dd5:14e5a955
           Name : Nexus:2  (local to host Nexus)
  Creation Time : Fri Oct  9 17:46:47 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524208 sectors, after=0 sectors
          State : clean
    Device UUID : ebdf3b9e:57e22cb2:2686dea7:d904e269

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Oct  9 17:46:47 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 98762f35 - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 40740f08:0fe9b96d:46a02dd5:14e5a955
           Name : Nexus:2  (local to host Nexus)
  Creation Time : Fri Oct  9 17:46:47 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524208 sectors, after=0 sectors
          State : clean
    Device UUID : 36694dfd:82829e36:44291661:37e2d8ae

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Oct  9 17:46:47 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 7a27d92a - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

When someone beats you with a flaslight, you make light shine in all directions.


  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

Ik heb er zoals eerder aangegeven geen verstand van maar, via deze link kwam ik op deze tip die in jouw situatie misschien de ruimte biedt om dingen te proberen zonder permanente schade, als het niet te laat is.

  • Mijzelf
  • Registratie: September 2004
  • Niet online
Berrick schreef op vrijdag 9 oktober 2020 @ 22:15:
Zie hieronder. sdc4 zit er voor de vorm ook bij maar maakt dus nog geen onderdeel van md2.
De nieuwe array heeft een bitmap. Die heeft de data offset verschoven van 262144 naar 524288. Je kunt de array nogmaals creëren met --bitmap=none erbij.

Een andere mogelijkheid is de array 'tijdelijk' bouwen, en kijken of hij mountbaar is.
Je maakt eerst 3 loopdevices aan die naar de payload wijzen:
losetup -f -r -o 134217728 /dev/sda4

Dit maakt een (readonly) blockdevice aan die de inhoud van sda4 bevat, met een offset van 262144 sectors.
Herhaal voor de drie partities.
Met 'losetup -l' kun je opvragen welke loopdevices er zijn.

Vervolgens kun je de array assembleren met
mdadm --build  /dev/md2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric /dev/loop0  missing /dev/loop1 /dev/loop2

Dit werkt helemaal op de readonly loopdevices, en zou dus niets mogen veranderen. Sorry dat ik niet eerste aan deze mogelijkheid dacht.

  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Mijzelf schreef op zaterdag 10 oktober 2020 @ 09:32:
De nieuwe array heeft een bitmap. Die heeft de data offset verschoven van 262144 naar 524288. Je kunt de array nogmaals creëren met --bitmap=none erbij.
Uhh, 262144 sectors. Dat is nogal wat. 128 MB om precies te zijn. En de bitmap is 65536KB. Zeroed, neem ik aan. Op een plek waar het filesystem stond.

EDIT: de bitmap chunk size (ie. de bits in de map) beslaat 65536KB, de bitmap zelf is helemaal niet zo groot.
Dit werkt helemaal op de readonly loopdevices, en zou dus niets mogen veranderen. Sorry dat ik niet eerste aan deze mogelijkheid dacht.
Dat werkt niet, denk ik.
When used with --build, only linear, stripe, raid0, 0, raid1, multipath, mp, and faulty are valid
Ik vrees dat TS nu een heel stuk verder van huis is dan origineel het geval was.

Als ik m'n eigen posts teruglees zie ik dat ik suggereerde COW snapshots te gebruiken. Achteraf gezien is er eigenlijk helemaal geen excuus voor: het is even wat uitzoekwerk, maar blijkbaar liggen er ook nog genoeg addertjes onder het gras bij een create. Tja, achteraf.

@Berrick ik zou niets meer proberen zonder eerst een COW-oplossing (zie de 2 links van mij en @Q) te realiseren. Daarna kun je de array proberen te createn zonder bitmap. Als dat niet de juiste offset oplevert: --data-offset=131072k

Eenmaal assembled met de juiste data offset is de kans alsnog aanwezig dat het filesystem (welk?) niet mountable is; dan is de primary superblock waarschijnlijk overschreven door de bitmap...

[ Voor 3% gewijzigd door Thralas op 11-10-2020 12:35 ]


  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Mijzelf schreef op zaterdag 10 oktober 2020 @ 09:32:
Een andere mogelijkheid is de array 'tijdelijk' bouwen, en kijken of hij mountbaar is.
Je maakt eerst 3 loopdevices aan die naar de payload wijzen:
losetup -f -r -o 134217728 /dev/sda4

Dit maakt een (readonly) blockdevice aan die de inhoud van sda4 bevat, met een offset van 262144 sectors.
Herhaal voor de drie partities.
Met 'losetup -l' kun je opvragen welke loopdevices er zijn.

Vervolgens kun je de array assembleren met
mdadm --build  /dev/md2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric /dev/loop0  missing /dev/loop1 /dev/loop2

Dit werkt helemaal op de readonly loopdevices, en zou dus niets mogen veranderen. Sorry dat ik niet eerste aan deze mogelijkheid dacht.
Helaas, lijkt --build niet bedoeld voor Raid5
bart@Nexus:/$ sudo mdadm --build /dev/md3 --raid-devices=4 --chunk=512 --level=5                                                                              --layout=left-symmetric /dev/loop0  missing /dev/loop1 /dev/loop2
mdadm: Raid level 5 not permitted with --build.
Thralas schreef op zaterdag 10 oktober 2020 @ 11:27:
@Berrick ik zou niets meer proberen zonder eerst een COW-oplossing (zie de 2 links van mij en @Q) te realiseren. Daarna kun je de array proberen te createn zonder bitmap. Als dat niet de juiste offset oplevert: --data-offset=131072k

Eenmaal assembled met de juiste data offset is de kans alsnog aanwezig dat het filesystem (welk?) niet mountable is; dan is de primary superblock waarschijnlijk overschreven door de bitmap...
Geprobeerd (wel gaaf om hier mee te knutselen):
bart@Nexus:/$ sudo losetup --find --read-only /dev/sdb4
bart@Nexus:/$ sudo losetup --find --read-only /dev/sdd4
bart@Nexus:/$ sudo losetup --find --read-only /dev/sdf4
bart@Nexus:/$ sudo losetup -l
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop1         0      0         0  1 /dev/sdd4   0     512
/dev/loop2         0      0         0  1 /dev/sdf4   0     512
/dev/loop0         0      0         0  1 /dev/sdb4   0     512

bart@Nexus:/mnt/temp$ sudo dmsetup create cow1 <<EOF
0 1961317  linear /dev/sdf 5860532224
EOF

bart@Nexus:/mnt/temp$ sudo dmsetup create cow2 <<EOF
0 1961317  linear /dev/sdf 5862493541
EOF

bart@Nexus:/mnt/temp$ sudo dmsetup create cow3 <<EOF
0 1961317  linear /dev/sdf 5864454858
EOF

bart@Nexus:/mnt/temp$ sudo sfdisk -l /dev/loop0
Disk /dev/loop0: 2.7 TiB, 2988542263296 bytes, 5836996608 sectors

bart@Nexus:/mnt/temp$ sudo dmsetup create snap1 <<EOF
0 5836996608 snapshot /dev/loop0 /dev/mapper/cow1 N 512
EOF

bart@Nexus:/mnt/temp$ sudo dmsetup create snap2 <<EOF
0 5836996608 snapshot /dev/loop1 /dev/mapper/cow2 N 512
EOF

bart@Nexus:/mnt/temp$ sudo dmsetup create snap3 <<EOF
0 5836996608 snapshot /dev/loop2 /dev/mapper/cow3 N 512
EOF


bart@Nexus:/mnt/temp$ sudo mdadm --examine /dev/mapper/snap*
/dev/mapper/snap1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 40740f08:0fe9b96d:46a02dd5:14e5a955
           Name : Nexus:2  (local to host Nexus)
  Creation Time : Fri Oct  9 17:46:47 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524208 sectors, after=0 sectors
          State : clean
    Device UUID : 810379b5:159b855e:8e5341f1:9ee5d5f9

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Oct  9 17:46:47 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 3562b9b9 - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/mapper/snap2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 40740f08:0fe9b96d:46a02dd5:14e5a955
           Name : Nexus:2  (local to host Nexus)
  Creation Time : Fri Oct  9 17:46:47 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524208 sectors, after=0 sectors
          State : clean
    Device UUID : ebdf3b9e:57e22cb2:2686dea7:d904e269

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Oct  9 17:46:47 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 98762f35 - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/mapper/snap3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 40740f08:0fe9b96d:46a02dd5:14e5a955
           Name : Nexus:2  (local to host Nexus)
  Creation Time : Fri Oct  9 17:46:47 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524208 sectors, after=0 sectors
          State : clean
    Device UUID : 36694dfd:82829e36:44291661:37e2d8ae

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Oct  9 17:46:47 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 7a27d92a - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

bart@Nexus:/mnt/temp$ sudo mdadm --create /dev/md2 --metadata=1.2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric --data-offset=26214 --bitmap=none /dev/mapper/snap1 missing /dev/mapper/snap2 /dev/mapper/snap3
mdadm: /dev/mapper/snap1 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Fri Oct  9 17:46:47 2020
mdadm: /dev/mapper/snap2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Fri Oct  9 17:46:47 2020
mdadm: /dev/mapper/snap3 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Fri Oct  9 17:46:47 2020
Continue creating array? y
mdadm: array /dev/md2 started.
bart@Nexus:/mnt/temp$ sudo cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid5 dm-5[3] dm-4[2] dm-3[0]
      8755415040 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [U_UU]

unused devices: <none>
bart@Nexus:/mnt/temp$ sudo mount /dev/md2 /mnt/temp
mount: /mnt/temp: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error.
bart@Nexus:/mnt/temp$ sudo mdadm --stop /dev/md2
mdadm: stopped /dev/md2
bart@Nexus:/mnt/temp$ sudo mdadm --create /dev/md2 --metadata=1.2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric --data-offset=131072k /dev/mapper/snap1 missing /dev/mapper/snap2 /dev/mapper/snap3
mdadm: invalid data-offset: 131072k
bart@Nexus:/mnt/temp$ sudo mdadm --create /dev/md2 --metadata=1.2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric --data-offset=131072 /dev/mapper/snap1 missing /dev/mapper/snap2 /dev/mapper/snap3
mdadm: /dev/mapper/snap1 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Oct 10 13:58:47 2020
mdadm: /dev/mapper/snap2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Oct 10 13:58:47 2020
mdadm: /dev/mapper/snap3 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Oct 10 13:58:47 2020
Continue creating array? y
mdadm: array /dev/md2 started.
bart@Nexus:/mnt/temp$ sudo mount /dev/md2 /mnt/temp
mount: /mnt/temp: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error.


Helaas. Lijkt er dus inderdaad op dat de bitmap iets overschreven heeft.. Nog ideeen?

[ Voor 6% gewijzigd door Berrick op 10-10-2020 14:14 ]

When someone beats you with a flaslight, you make light shine in all directions.


  • jvanderneut
  • Registratie: Augustus 2017
  • Laatst online: 28-11 21:08
Berrick schreef op zaterdag 10 oktober 2020 @ 14:12:
Helaas. Lijkt er dus inderdaad op dat de bitmap iets overschreven heeft.. Nog ideeen?
Wat vindt fsck van het filesysteem? Gebruik je ext4? Dan:

fsck.ext4 -n -v /dev/md2


Bij ext4 staan er backup superblocks verspreid over het filesysteem. Waar ze staan kan je uitvinden met de '-n' optie van mkfs:

mkfs.ext4 -n /dev/md2


Het programma geeft dan aan op welke plekken de backup superblocks staan. Daarna:

fsck.ext4 -n -v -b <backupblock> /dev/md2


Als het er op lijkt dat iets te redden valt kan je de '-n' optie van fsck weghalen.

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
@jvanderneut goed te weten dat er mogelijk backup superblocks beschikbaar zijn. Voor nu zit het probleem nog in de juiste hercreate van de raid. Ik zie namelijk dat de wanneer ik mdadm --create met een data-offset=262144 doe er in de mdadm --examine een Data Offset van 524288 sectors laat zien (=2x262144).
bart@Nexus:/mnt$ sudo mdadm --examine /dev/mapper/snap1
/dev/mapper/snap1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 6e65911b:4df09d12:4874504d:b26d6b38
           Name : Nexus:3  (local to host Nexus)
  Creation Time : Sun Oct 11 09:17:09 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836472320 (2783.05 GiB 2988.27 GB)
     Array Size : 8754708480 (8349.14 GiB 8964.82 GB)
    Data Offset : 524288 sectors
   Super Offset : 8 sectors
   Unused Space : before=524008 sectors, after=0 sectors
          State : clean
    Device UUID : 0332b1f9:521594dc:6622487f:d32f1fee

    Update Time : Sun Oct 11 09:17:09 2020
  Bad Block Log : 512 entries available at offset 264 sectors
       Checksum : 8d492891 - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)


Als ik hem toch zonder data-offset (maar wel met --bitmap=none komt het in de buurt, maar net niet hetzelfde:
bart@Nexus:/mnt$ sudo mdadm --create /dev/md3 --metadata=1.2 --raid-devices=4 --chunk=512 --level=5 --layout=left-symmetric --bitmap=none /dev/mapper/snap1 missing /dev/mapper/snap2 /dev/mapper/snap3
mdadm: /dev/mapper/snap1 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Oct 11 09:17:09 2020
mdadm: /dev/mapper/snap2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Oct 11 09:17:09 2020
mdadm: /dev/mapper/snap3 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sun Oct 11 09:17:09 2020
Continue creating array? y
mdadm: array /dev/md3 started.
bart@Nexus:/mnt$ sudo mdadm --examine /dev/mapper/snap1
/dev/mapper/snap1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 6529879f:11be4338:b565c680:964d52e7
           Name : Nexus:3  (local to host Nexus)
  Creation Time : Sun Oct 11 09:21:12 2020
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836732416 (2783.17 GiB 2988.41 GB)
     Array Size : 8755098624 (8349.51 GiB 8965.22 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=263912 sectors, after=0 sectors
          State : clean
    Device UUID : b9649854:cbad0233:1124cdeb:b5b18606

    Update Time : Sun Oct 11 09:21:12 2020
  Bad Block Log : 512 entries available at offset 264 sectors
       Checksum : 4f87d43f - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

Als ik deze --examine vergelijk met de originele (gekopi:

bart@Nexus:/mnt$ sudo mdadm --examine /dev/sda[4]
/dev/sda4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 902f6955:5ca219ae:eada110c:87f1bc28
           Name : Nexus:1  (local to host Nexus)
  Creation Time : Sat Dec  8 01:58:59 2012
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 5836734464 (2783.17 GiB 2988.41 GB)
     Array Size : 8755100160 (8349.51 GiB 8965.22 GB)
  Used Dev Size : 5836733440 (2783.17 GiB 2988.41 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=1024 sectors
          State : clean
    Device UUID : 6ba5730e:5227ebc1:477140ab:b0811434

    Update Time : Wed Oct  7 07:41:24 2020
       Checksum : 8291aa19 - correct
         Events : 236217

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
  • Valt me op dat de data offset nu 264192 sectors is; de oude 262144 sectors + 2048.
  • Available Dev Size is voor snap1 2048 kleiner dan sda4
  • Array size is voor snap1 1536 kleiner dan sda4
  • Unused space before is 1848 groter voor snap 1 dan voor sda4, maar unused space after is 1024 kleiner (namelijk 0 vs 1024) voor snap1 dan voor sda4
Waar komt die data offset, en al die andere verschillen, vandaan?

When someone beats you with a flaslight, you make light shine in all directions.


  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Je originele array was uit 2012, sindsdien is er genoeg gesleuteld aan md of mdadm. Zo zal de bbl default zijn aangezet, terwijl dat eerst niet zo was. Plus wellicht wat extra alignment (die 2048).

Probeer het eens mét offset en no-bbl.

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Thralas schreef op zondag 11 oktober 2020 @ 10:25:
Je originele array was uit 2012, sindsdien is er genoeg gesleuteld aan md of mdadm. Zo zal de bbl default zijn aangezet, terwijl dat eerst niet zo was. Plus wellicht wat extra alignment (die 2048).

Probeer het eens mét offset en no-bbl.
Ik geloof niet dat er een optie is die bbl uitzet. Ik kan er iig geen een vinden :?

When someone beats you with a flaslight, you make light shine in all directions.


  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Sorry, ik verwar de bitmap en bbl. Ik bedoelde offset en no-bitmap.

bbl kun je achteraf uitzetten met --update, maar dat zal dan niets meer uitmaken voor de data offset

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Bitmap had ik al uit gezet op advies van @Mijzelf.

When someone beats you with a flaslight, you make light shine in all directions.


Acties:
  • Beste antwoord

  • Thralas
  • Registratie: December 2002
  • Laatst online: 23:39
Dit werkt prima hier - met -o voor read only en gewoon met bitmap:

# mdadm --create /dev/md0 -n 3 -l 5 -o --data-offset 131072 /dev/loop{3,4,5}

# mdadm --examine /dev/loop4
/dev/loop4:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 2d4a053a:463897a9:eca176a8:64d2c233
           Name : localhost:0  (local to host localhost)
  Creation Time : Sun Oct 11 12:37:07 2020
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 6442188800 (3071.88 GiB 3298.40 GB)
     Array Size : 6442188800 (6143.75 GiB 6596.80 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262064 sectors, after=0 sectors
          State : clean
    Device UUID : fde53dbf:ae44a857:e82c4d06:b4b7ddb7

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Oct 11 12:37:07 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 93062df - correct
         Events : 0

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AA. ('A' == active, '.' == missing, 'R' == replacing)


Ander goed nieuws: de bitmap is eigenlijk ook helemaal niet zo groot, die 65535K slaat op de ruimte van een chunk in de bitmap, niet de bitmap zelf. Wellicht is de data daarmee nog gewoon intact.

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
YES, met deze instellingen lukt het mounten raid array op basis van de COWs. Ik snap nu dat de -data_offset in Kb moest en niet in #sectors (ie. veelvouden van 512b), vandaar de factor 2 die ik er naast zat, maar dit had jij allang door :)

heel erg bedankt voor jullie hulp. Ik moet nu weer weg maar vanavond ga ik alles in het echt doen (dus niet met COW). Daarna 4e schijf er bij en syncen. Zodra het allemaal weer stabiel is laat ik het nog even weten!

When someone beats you with a flaslight, you make light shine in all directions.


  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

Gefeliciteerd, dat valt gelukkig erg mee :)

  • Berrick
  • Registratie: September 2003
  • Laatst online: 03-07 09:11
Het loopt allemaal weer als een zonnetje, met een uitzondering. Om de een of andere reden assembled Ubuntu hem bij het booten als md127:
bart@Nexus:~$ sudo cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md1 : inactive sda4[4](S)
      2918367232 blocks super 1.2

md0 : inactive sdd3[3](S) sdb3[2](S) sdf3[4](S)
      29277696 blocks super 1.2

md127 : active raid5 sdd4[0] sdb4[2] sdf4[3] sdc4[4]
      8755101696 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      bitmap: 4/22 pages [16KB], 65536KB chunk

unused devices: <none>

Terwijl ik hem als md3 heb gedefinieerd. Als ik md127 stop en --assemble --scan doe (of --assemble /dev/md3) dan staat staat er wel md3 in /proc/mdstat

mijn mdadm.conf ziet er zo uit:

code:
1
2
3
4
5
6
7
8
9
10
11
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR xxxxx@xx.xx

# definitions of existing MD arrays
ARRAY /dev/md/3 metadata=1.2 name=Nexus:3 UUID=16bc0d05:4249f624:d1f6ada0:38411$


Ik kan de md127 wel gewoon mounten, dus op zich niets aan de hand, maar ik vind het wel raar. Het lijkt vaak voorkomend fenomeen te zijn maar de oplossing
update-initramfs -u
helpt bij mij niet...

[ Voor 0% gewijzigd door Berrick op 12-10-2020 22:11 . Reden: privacy ]

When someone beats you with a flaslight, you make light shine in all directions.


  • Q
  • Registratie: November 1999
  • Laatst online: 01:05

Q

Au Contraire Mon Capitan!

Bij mij helpt het soms om de array /dev/md3 te nomen, de name= sectie weg te laten (UUID wel laten staan) en dan een update-initramfs doen.
Pagina: 1