[Fedora11] RAID5-partitie herstellen?

[xxfile]

Ik zit met het volgende. Ik probeer onze 4.5TB RAID5-partitie te mounten onder Fedora 11 (ons NAS-systeem). Als ik dat probeer krijg ik de volgende melding:

Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Als ik dan

dmesg | tail

intik dan krijg ik de volgende meldingen:

EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 4000 failed (57261!=23419)
EXT4-fs (sdb1): group descriptors corrupted!
EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 4000 failed (57261!=23419)
EXT4-fs (sdb1): group descriptors corrupted!
EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 4000 failed (57261!=23419)
EXT4-fs (sdb1): group descriptors corrupted!
EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 4000 failed (57261!=23419)
EXT4-fs (sdb1): group descriptors corrupted!
EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 4000 failed (57261!=23419)
EXT4-fs (sdb1): group descriptors corrupted!

Vreemde is dat als ik

fdisk -l /dev/sdb1

gebruik ik dit krijg:

Disk /dev/sdb1: 4499.2 GB, 4499244593152 bytes
255 heads, 63 sectors/track, 547001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/sdb1 doesn't contain a valid partition table

Terwijl de Disk Utility en QTParted beide aangeven dat het ext4 is

fdisk -l /dev/sdb

geeft de volgende melding:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


WARNING: The size of this disk is 4.5 TB (4499246678016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).


Disk /dev/sdb: 4499.2 GB, 4499246678016 bytes
255 heads, 63 sectors/track, 547002 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      267350  2147483647+  ee  GPT

ftab geeft het volgende:

code:

#
# /etc/fstab
# Created by anaconda on Mon Apr  5 22:12:35 2010
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_nas-lv_root /                       ext4    defaults        1 1
UUID=79abe6ae-2534-4d71-b5bc-90958f80c4d0 /boot                   ext4    defaults        1 2
/dev/mapper/vg_nas-lv_swap swap                    swap    defaults        0 0
UUID=2c470406-4841-4aa5-89b5-cfffef5581bc swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

fsck.ext4 -n /dev/sdb

levert het volgende op:

e2fsck 1.41.9 (22-Aug-2009)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Maar dat zou ik eigenlijk niet willen doen, omdat het een ext4-partitie is of is dat verkeerd gedacht?

Ook heb ik een site gevonden om de backups terug te plaatsen, maar als ik het opvolg en een heleboel vragen beantwoordt krijg ik het volgende:

Segmentation fault (core dumped)

Het ziet er heel ernstig uit. Kan ik hier nog wat aan doen?

[CAPSLOCK2000]

Gebruik geen fdisk, dat is niet geschikt voor GPT.

code:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


WARNING: The size of this disk is 4.5 TB (4499246678016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).

FSCK op de hele disk loslaten is geen goed idee. Je moet de parititie fsck'en, niet de hele disk.

[xxfile]

Ik heb 2 partities op de disk staan. Namelijk een partitie waar alle data opstaat (4,nogwat TB) en een swap-partitie van een paar honderd MB zo uit mijn hoofd (zit nu bij familie en kan niet bij de NAS). En ik dacht dat /dev/sdb1 (de grote partitie) dezelfde uitkomst heeft, maar zondagavond ben ik weer thuis en zal ik alles wel met /dev/sdb1 posten

Thanks alvast voor je reactie!

[deadinspace]

xxfile schreef op zaterdag 04 december 2010 @ 11:50:
Ik zit met het volgende. Ik probeer onze 4.5TB RAID5-partitie te mounten onder Fedora 11 (ons NAS-systeem).

Hoe ziet je storage er precies uit? Je hebt het over een RAID-array, is dat Linux Software RAID, of een controller (en zo ja, welke)? Heb je ook nog disks buiten je RAID? Gebruik je LVM?

Als ik dat probeer krijg ik de volgende melding: [...]

Sinds wanneer is dat zo? Gebeurde het spontaan, of vond er iets plaats dat er mee te maken zou kunnen hebben? Denk daarbij aan stroomuitval, pogingen het filesystem te resizen, disk errors (kijk daar je logs eens op na), ext4 filesystem gemount vanuit Windows, etc.

Vreemde is dat als ik

fdisk -l /dev/sdb1

gebruik ik dit krijg:

Disk /dev/sdb1: 4499.2 GB, 4499244593152 bytes
255 heads, 63 sectors/track, 547001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/sdb1 doesn't contain a valid partition table

Terwijl de Disk Utility en QTParted beide aangeven dat het ext4 is

Da's niet zo vreemd, want ext4 is geen geldige partitietabel

Maareh, gebruik sowieso maar geen fdisk, want:

fdisk -l /dev/sdb

geeft de volgende melding:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

fsck.ext4 -n /dev/sdb

levert het volgende op:

Je vorige informatie duidt erop dat je filesystem op de eerste partitie staat, /dev/sdb1, niet op /dev/sdb zelf. Als dat zo is, dan is het niet gek dat fsck daar weinig mee kan.

Als je dan dingen gaat forceren, dan is de kans groot dat je de zaak alleen maar erger maakt. Daarom is het verstandig om eerst uit te zoeken wat wat is, en zo mogelijk wat er mis gegaan is voordat je reparatiepogingen onderneemt.

Ook heb ik een site gevonden om de backups terug te plaatsen, maar als ik het opvolg en een heleboel vragen beantwoordt krijg ik het volgende:

Segmentation fault (core dumped)

Welke commando's van die site heb je exact uitgevoerd, en bij welke ging het mis? Ook: welke vragen kreeg je en hoe heb je die beantwoord?

[xxfile]

deadinspace schreef op zondag 05 december 2010 @ 18:08:
Hoe ziet je storage er precies uit? Je hebt het over een RAID-array, is dat Linux Software RAID, of een controller (en zo ja, welke)? Heb je ook nog disks buiten je RAID? Gebruik je LVM?

4 disks van Samsung HD154UI van elk 1,5TB. Dit is samen met de Dell PERC5/i kaart de RAID-5 Array. De systeemschijf waar Fedora op draait is 250GB (geen dual-boot, puur Fedora). Deze is op het Mobo aangesloten. Wel 2x 1TB en 1,5TB als losse schijven die er zo bijgeplaatst kunnen worden, mocht het tot recovery komen.

Sinds wanneer is dat zo? Gebeurde het spontaan, of vond er iets plaats dat er mee te maken zou kunnen hebben? Denk daarbij aan stroomuitval, pogingen het filesystem te resizen, disk errors (kijk daar je logs eens op na), ext4 filesystem gemount vanuit Windows, etc.

Het gebeurde in principe spontaan. We hebben wel eens vaker last gehad van het feit dat disk 3 van de array "moeilijk" deed en dan konden we de array ook niet meer mounten. We dachten eerst dat het aan een temperatuursprobleem van de kaart lag. Daar hebben we ook een nieuwe fan opgezet (de oude maakte lawaai en liep soms vast). Sinsdien ging het lange tijd goed, dus we dachten het probleem opgelost te hebben, maar blijkbaar niet (en gezien het feit dat het nota bene in de winter mis gaat op een onverwarmde kamer, dicht bij een raam op de ventilatiestand, was koeling wellicht niet het (enige?) probleem).

Welke commando's van die site heb je exact uitgevoerd, en bij welke ging het mis? Ook: welke vragen kreeg je en hoe heb je die beantwoord?

Ik heb alles uitgevoerd. De superblocks gevonden en ff in een tekstbestandje gezet. Toen 2 geprobeerd en bij elke krijg ik het volgende:

e2fsck 1.41.9 (22-Aug-2009)
Superblock has an invalid journal (inode 8).
Clear<y>? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

One or more block group descriptor checksums are invalid.  Fix<y>y 
Hele lijst van:
Group descriptor xxxxxx checksum is invalid.  FIXED.
Data1 contains a file system with errors, check forced.
Resize inode not valid.  Recreate<y>? yes

Pass 1: Checking inodes, blocks, and sizes
Inode 456, i_blocks is 3926976, should be 5416352.  Fix<y>y 
Inode 457 has an invalid extent node (blk 127, lblk 0)
Clear<y>..........etc.

Als ik op alle vragen yes antwoord dan krijg ik de

Segmentation fault (core dumped)

[xxfile]

Niemand?

[deadinspace]

xxfile schreef op maandag 06 december 2010 @ 18:33:
4 disks van Samsung HD154UI van elk 1,5TB. Dit is samen met de Dell PERC5/i kaart de RAID-5 Array. De systeemschijf waar Fedora op draait is 250GB (geen dual-boot, puur Fedora). Deze is op het Mobo aangesloten. Wel 2x 1TB en 1,5TB als losse schijven die er zo bijgeplaatst kunnen worden, mocht het tot recovery komen.

Ok. Je RAID array is /dev/sdb neem ik aan? En je had daar zowel data als swap op?

Kun je eens de output van

cat /proc/partitions

geven?

Het gebeurde in principe spontaan. We hebben wel eens vaker last gehad van het feit dat disk 3 van de array "moeilijk" deed en dan konden we de array ook niet meer mounten. We dachten eerst dat het aan een temperatuursprobleem van de kaart lag. Daar hebben we ook een nieuwe fan opgezet (de oude maakte lawaai en liep soms vast). Sinsdien ging het lange tijd goed, dus we dachten het probleem opgelost te hebben, maar blijkbaar niet (en gezien het feit dat het nota bene in de winter mis gaat op een onverwarmde kamer, dicht bij een raam op de ventilatiestand, was koeling wellicht niet het (enige?) probleem).

Hmm, dat betekent dat we eventuele data-corruptie vanuit de controller (of een van de disks) niet uit kunnen sluiten. Vindt je controller nu dat je array in orde is? Heeft je controller een event log oid? Zo ja, staat daar iets interessants in van omstreeks of voordat dit probleem optrad?

Ik heb alles uitgevoerd. De superblocks gevonden en ff in een tekstbestandje gezet. Toen 2 geprobeerd en bij elke krijg ik het volgende:

e2fsck 1.41.9 (22-Aug-2009)
Superblock has an invalid journal (inode 8).
Clear<y>? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

One or more block group descriptor checksums are invalid.  Fix<y>y 
Hele lijst van:
Group descriptor xxxxxx checksum is invalid.  FIXED.
Data1 contains a file system with errors, check forced.
Resize inode not valid.  Recreate<y>? yes

Pass 1: Checking inodes, blocks, and sizes
Inode 456, i_blocks is 3926976, should be 5416352.  Fix<y>y 
Inode 457 has an invalid extent node (blk 127, lblk 0)
Clear<y>..........etc.

Als ik op alle vragen yes antwoord dan krijg ik de

Segmentation fault (core dumped)

Waarop riep je fsck aan? Op /dev/sdb of /dev/sdb1?
Die inode nummers richting het eind van je paste, liepen die telkens met 1 op, of zaten daar ook grotere sprongen tussen?

[xxfile]

deadinspace schreef op dinsdag 07 december 2010 @ 22:13:
Ok. Je RAID array is /dev/sdb neem ik aan? En je had daar zowel data als swap op?

Yup, /dev/sdb1 is de data-partitie en /dev/sdb2 is de swap.

Kun je eens de output van

cat /proc/partitions

geven?

major minor  #blocks  name

   8        0  244198584 sda
   8        1     204800 sda1
   8        2  243991201 sda2
   8       16 4393795584 sdb
   8       17 4393793548 sdb1
 253        0  239861760 dm-0
 253        1    4128768 dm-1

Hmm, dat betekent dat we eventuele data-corruptie vanuit de controller (of een van de disks) niet uit kunnen sluiten. Vindt je controller nu dat je array in orde is? Heeft je controller een event log oid? Zo ja, staat daar iets interessants in van omstreeks of voordat dit probleem optrad?

Hij vindt nu dat de array in orde is. Helaas heeft ie geen event log Die optie hebben we niet kunnen vinden

Waarop riep je fsck aan? Op /dev/sdb of /dev/sdb1?
Die inode nummers richting het eind van je paste, liepen die telkens met 1 op, of zaten daar ook grotere sprongen tussen?

Op /dev/sdb1. Ik heb nu zoveel mogelijk no op geantwoord en het volgende is te zien (pas op dit wordt een lange lijst):

Inode 456, i_blocks is 3926976, should be 5416352.  Fix<y>? yes

Inode 457 has an invalid extent node (blk 127, lblk 0)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 127, invalid physical block 545460846597, len 5)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 132, invalid physical block 566935683167, len 95)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 227, invalid physical block 974957576195, len 3)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 230, invalid physical block 987842478597, len 517)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 747, invalid physical block 3208340570119, len 7)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 754, invalid physical block 3238405341261, len 77)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 831, invalid physical block 3569117822987, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 842, invalid physical block 3616362463241, len 9)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 851, invalid physical block 3655017168907, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 862, invalid physical block 3702261809165, len 13)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 875, invalid physical block 3758096384007, len 7)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 882, invalid physical block 3788161156238, len 1166)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 2048, invalid physical block 61572651166047, len 10591)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 12639, invalid physical block 107060649787395, len 3)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 12642, invalid physical block 107073534689837, len 557)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13199, invalid physical block 109465831473163, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13210, invalid physical block 109513076113641, len 233)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13443, invalid physical block 110513803493383, len 7)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13450, invalid physical block 110543868264457, len 9)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13459, invalid physical block 110582522970123, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13470, invalid physical block 110629767610401, len 33)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13503, invalid physical block 110771501531143, len 7)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13510, invalid physical block 110801566302241, len 33)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13543, invalid physical block 110943300222979, len 3)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 13546, invalid physical block 110956185129025, len 4161)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 17707, invalid physical block 128827544043531, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 17718, invalid physical block 128874788683785, len 9)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 17727, invalid physical block 128913443389451, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 17738, invalid physical block 128960688030073, len 377)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 18115, invalid physical block 130579890700291, len 3)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 18118, invalid physical block 130592775602681, len 505)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 18623, invalid physical block 132761734086667, len 11)
Clear<y>? no

Inode 457 has an invalid extent
	(logical block 18634, invalid physical block 132808978732693, len 518478)
Clear<y>? no

Inode 459 has an invalid extent node (blk 919484416, lblk 0)
Clear<y>? no

Inode 459 has an invalid extent node (blk 919484417, lblk 61860)
Clear<y>? no

Inode 459 has an invalid extent node (blk 919484418, lblk 74031)
Clear<y>? no

Inode 459, i_blocks is 5030032, should be 3424376.  Fix<y>? no

Inode 460 has an invalid extent node (blk 920252416, lblk 0)
Clear<y>? no

Inode 460 has an invalid extent node (blk 920252417, lblk 62040)
Clear<y>? no

Inode 460 has an invalid extent node (blk 920875092, lblk 450136)
Clear<y>? no

Inode 460 has an invalid extent node (blk 920875090, lblk 492120)
Clear<y>? no

Inode 460 has an invalid extent node (blk 920875089, lblk 519608)
Clear<y>? no

Inode 460 has an invalid extent node (blk 920875091, lblk 613293)
Clear<y>? no

Inode 460, i_blocks is 5030648, should be 2621504.  Fix<y>? no

Inode 461 has an invalid extent node (blk 921610076, lblk 0)
Clear<y>? no

Inode 462 has an invalid extent node (blk 922335294, lblk 588860)
Clear<y>? no

Inode 462, i_blocks is 5030520, should be 4711008.  Fix<y>? no

Inode 463 has an invalid extent node (blk 923103177, lblk 0)
Clear<y>? no

Inode 463, i_blocks is 3496208, should be 0.  Fix<y>? no

Inode 464 has an invalid extent node (blk 923168768, lblk 0)
Clear<y>? no

Inode 464 has an invalid extent node (blk 923168769, lblk 18432)
Clear<y>? no

Inode 464 has an invalid extent node (blk 923168770, lblk 51936)
Clear<y>? no

Inode 464 has an invalid extent node (blk 924053509, lblk 708020)
Clear<y>? no

Inode 464 has an invalid extent node (blk 924053511, lblk 787792)
Clear<y>? no

Inode 464 has an invalid extent node (blk 924053510, lblk 822272)
Clear<y>? no

Inode 464, i_blocks is 6815920, should be 5008888.  Fix<y>? no

Inode 465 has an invalid extent node (blk 924700562, lblk 0)
Clear<y>? no

Inode 466 has an invalid extent node (blk 924825600, lblk 0)
Clear<y>? no

Inode 466 has an invalid extent node (blk 924825601, lblk 33544)
Clear<y>? no

Inode 466 has an invalid extent node (blk 924825602, lblk 72916)
Clear<y>? no

Inode 466 has an invalid extent node (blk 924825603, lblk 141063)
Clear<y>? no

Inode 466, i_blocks is 5029120, should be 3629888.  Fix<y>? no

Inode 467 has an invalid extent node (blk 929103872, lblk 0)
Clear<y>? no

Inode 467 has an invalid extent node (blk 929103873, lblk 96256)
Clear<y>? no

Inode 467 has an invalid extent node (blk 929671189, lblk 561567)
Clear<y>? no

Inode 467 has an invalid extent node (blk 929671188, lblk 596400)
Clear<y>? no

Inode 467, i_blocks is 4492664, should be 4050048.  Fix<y>? no

Inode 468 has an invalid extent node (blk 930336707, lblk 0)
Clear<y>? no

Inode 468, i_blocks is 5029520, should be 0.  Fix<y>? no

Inode 510 has an invalid extent node (blk 935798719, lblk 0)
Clear<y>? no

Inode 510, i_blocks is 5029512, should be 0.  Fix<y>? no

Inode 512 has an invalid extent node (blk 935950336, lblk 0)
Clear<y>? no

Inode 512 has an invalid extent node (blk 935950338, lblk 61305)
Clear<y>? no

Inode 512 has an invalid extent node (blk 935950337, lblk 83646)
Clear<y>? no

Inode 512 has an invalid extent node (blk 936494964, lblk 550985)
Clear<y>? no

Inode 512 has an invalid extent node (blk 936494963, lblk 600794)
Clear<y>? no

Inode 512, i_blocks is 4408032, should be 3417856.  Fix<y>? no

Inode 514 has an invalid extent node (blk 936710144, lblk 0)
Clear<y>? no

Inode 514 has an invalid extent node (blk 936710145, lblk 68825)
Clear<y>? no

Inode 514 has an invalid extent node (blk 936710146, lblk 85568)
Clear<y>? no

Inode 514 has an invalid extent node (blk 937248684, lblk 324412)
Clear<y>? no

Inode 514 has an invalid extent node (blk 937248689, lblk 360457)
Clear<y>? no

Inode 514 has an invalid extent node (blk 937248688, lblk 391429)
Clear<y>? no

Inode 514 has an invalid extent node (blk 937248686, lblk 427584)
Clear<y>? .......etc.

Als ik no blijf antwoorden kom ik geen segmentation faults meer tegen.

Edit:

Inode 1023 has an invalid extent node (blk 902727600, lblk 0)
Clear<y>? no

Inode 131082 has an invalid extent
	(logical block 0, invalid physical block 62586277500957, len 941030)
Clear<y>? no

Dit is best een grote sprong.

[deadinspace]

xxfile schreef op dinsdag 07 december 2010 @ 23:06:
Yup, /dev/sdb1 is de data-partitie en /dev/sdb2 is de swap.

Ok. Voor de zekerheid zou ik graag ook nog even weten wat file er van vindt:

dd if=/dev/sdb1 bs=4K count=1024 | file -

Overigens zie ik geen sdb2 in je /proc/partitions, en het grootte-verschil tussen sdb en sdb1 laat ook niet veel ruimte over voor nog een partitie.

Op /dev/sdb1. Ik heb nu zoveel mogelijk no op geantwoord en het volgende is te zien (pas op dit wordt een lange lijst):
[...]

Hmm, ik probeer te begrijpen wat er beschadigd is, onder andere door te zoeken naar patronen in de inodes waar hij over klaagt. Ik zou graag nog meer van de fsck output zien eigenlijk.

Ik neem aan dat je fsck zo aanriep:

fsck.ext4 /dev/sdb1

Zou je dan eens
[cmd]fsck.ext4 -n /dev/sdb1[cmd]
willen doen? -n zorgt ervoor dat fsck het filesystem read-only opent en 'no' op alle vragen aanneemt. Ik zou graag de hele output zien, en die zou wel eens heel erg lang kunnen zijn, dus je wil waarschijnlijk redirecten:

fsck.ext4 -n /dev/sdb1 > fsck.txt

en output.txt ergens online zetten. gzippen zal waarschijnlijk flink helpen voor de grootte.

Ook zou ik graag de output van

debugfs -R stats /dev/sdb1 > debugfs.txt

zien. De output hiervan zou eventueel kort genoeg kunnen zijn om rechtstreeks op het forum te plaatsen (zeker het begin, voor de group list).

Ook zei je in je startpost dat fsck klaagde over "Superblock invalid, trying backup blocks", maar dat was - volgensmij - voor een aantal reparatiepogingen. Krijg je die melding nu nog?

[xxfile]

deadinspace schreef op woensdag 08 december 2010 @ 15:08:
Ok. Voor de zekerheid zou ik graag ook nog even weten wat file er van vindt:

dd if=/dev/sdb1 bs=4K count=1024 | file -

Output van dit was:

[root@NAS NAS_User]# dd if=/dev/sdb1 bs=4k count=1024 | file -
/dev/stdin: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (large files) (huge files)

Overigens zie ik geen sdb2 in je /proc/partitions, en het grootte-verschil tussen sdb en sdb1 laat ook niet veel ruimte over voor nog een partitie.

Ik zie nu waar ik in de fout ben geweest, het is een /dev/sdb-1 hidden partitie van 2MB wat nog vrij is.

Hmm, ik probeer te begrijpen wat er beschadigd is, onder andere door te zoeken naar patronen in de inodes waar hij over klaagt. Ik zou graag nog meer van de fsck output zien eigenlijk.

Ik neem aan dat je fsck zo aanriep:

fsck.ext4 /dev/sdb1

Ik probeerde de superblock te vervangen en dan krijg je die vragen.

fsck.ext4 -b superblock_nummer /dev/sdb1

Maar ik krijg ze ook als ik

fsck.ext4 /dev/sdb1

gebruik.

Zou je dan eens
[cmd]fsck.ext4 -n /dev/sdb1[cmd]
willen doen? -n zorgt ervoor dat fsck het filesystem read-only opent en 'no' op alle vragen aanneemt. Ik zou graag de hele output zien, en die zou wel eens heel erg lang kunnen zijn, dus je wil waarschijnlijk redirecten:

fsck.ext4 -n /dev/sdb1 > fsck.txt

en output.txt ergens online zetten. gzippen zal waarschijnlijk flink helpen voor de grootte.

Die is heel kort, namelijk:

[root@NAS NAS_User]# fsck.ext4 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
Superblock has an invalid journal (inode 8).
Clear<y>? no

fsck.ext4: Illegal inode number while checking ext3 journal for Data1
[root@NAS NAS_User]# fsck.ext4 -n /dev/sdb1 > fsck.txt
e2fsck 1.41.9 (22-Aug-2009)
fsck.ext4: Illegal inode number while checking ext3 journal for Data1

De output van het tekstbestand is:

Superblock has an invalid journal (inode 8)
Clear<y>? no

Ook zou ik graag de output van

debugfs -R stats /dev/sdb1 > debugfs.txt

zien. De output hiervan zou eventueel kort genoeg kunnen zijn om rechtstreeks op het forum te plaatsen (zeker het begin, voor de group list).

Filesystem volume name:   Data1
Last mounted on:          /media/Data1
Filesystem UUID:          fc61cc00-0f4c-41d6-99b9-ceb108139104
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg
 sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              274612224
Block count:              1098448387
Reserved block count:     54922419
Free blocks:              86894467
Free inodes:              274504854
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      762
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed May  5 14:05:48 2010
Last mount time:          Mon Oct 18 13:02:50 2010
Last write time:          Mon Oct 18 13:02:50 2010
Mount count:              12
Maximum mount count:      20
Last checked:             Wed May  5 14:05:48 2010
Check interval:           15552000 (6 months)
Next check after:         Mon Nov  1 13:05:48 2010
Lifetime writes:          1803 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      6808cc25-05c1-4cb5-abc4-999501899495
Journal backup:           inode blocks
Directories:              8408
 Group  0: block bitmap at 1025, inode bitmap at 1041, inode table at 1057
           23457 free blocks, 7648 free inodes, 1 used directory, 7241 unused inodes
           [Checksum 0xfcb4]
 Group  1: block bitmap at 1026, inode bitmap at 1042, inode table at 1569
           422 free blocks, 8190 free inodes, 2 used directories, 8190 unused inodes
           [Checksum 0xde0a]
 Group  2: block bitmap at 1027, inode bitmap at 1043, inode table at 2081
           180 free blocks, 8190 free inodes, 2 used directories, 8190 unused inodes
           [Checksum 0xc5e8]
 Group  3: block bitmap at 1028, inode bitmap at 1044, inode table at 2593
           301 free blocks, 8190 free inodes, 2 used directories, 8190 unused inodes
           [Checksum 0x668f]
 Group  4: block bitmap at 1029, inode bitmap at 1045, inode table at 3105
           226 free blocks, 8190 free inodes, 2 used directories, 8190 unused inodes
           [Checksum 0x174f]
 Group  5: block bitmap at 1030, inode bitmap at 1046, inode table at 3617
           355 free blocks, 8189 free inodes, 3 used directories, 8187 unused inodes
           [Checksum 0x4c0f]
 Group  6: block bitmap at 1031, inode bitmap at 1047, inode table at 4129
           877 free blocks, 8187 free inodes, 5 used directories, 8187 unused inodes
           [Checksum 0x044d]
 Group  7: block bitmap at 1032, inode bitmap at 1048, inode table at 4641

Ik maak de lijst niet groter dan dat het al is, het is een tekstbestand van 7,1MB

Ook zei je in je startpost dat fsck klaagde over "Superblock invalid, trying backup blocks", maar dat was - volgensmij - voor een aantal reparatiepogingen. Krijg je die melding nu nog?

Nee, als ik /dev/sdb vervang door /dev/sdb1 niet meer nee Maar als ik /dev/sdb gebruik dan nog steeds.

En ik wil nog zeggen dat ik het heel erg waardeer dat je me wil helpen, want ik zit met mijn handen in het haar hoe ik dit kan oplossen. In deze partitie zit toch 8 maanden werk wat ik niet graag verloren zie gaan

[deadinspace]

xxfile schreef op woensdag 08 december 2010 @ 16:06:
Output van dit was:

[root@NAS NAS_User]# dd if=/dev/sdb1 bs=4k count=1024 | file -
/dev/stdin: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (large files) (huge files)

Ok, dat ziet er iig normaal uit.

Ik probeerde de superblock te vervangen en dan krijg je die vragen.

fsck.ext4 -b superblock_nummer /dev/sdb1

Maar ik krijg ze ook als ik

fsck.ext4 /dev/sdb1

gebruik.

Hmm, boven zeg je dat als je die vragen krijgt als je fsck.ext4 /dev/sdb1 doet, maar in de paste hieronder zie ik die niet terug?

Die is heel kort, namelijk:

[root@NAS NAS_User]# fsck.ext4 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
Superblock has an invalid journal (inode 8).
Clear<y>? no

fsck.ext4: Illegal inode number while checking ext3 journal for Data1
[root@NAS NAS_User]# fsck.ext4 -n /dev/sdb1 > fsck.txt
e2fsck 1.41.9 (22-Aug-2009)
fsck.ext4: Illegal inode number while checking ext3 journal for Data1

In ieder geval, ik zou graag de output zien van de fsck-opdracht waarvan je in deze post een stuk van de ellenlange output gaf. Daarbij zou ik graag zien dat je de -n flag toevoegt (read-only en 'no' voor alle vragen), en redirection gebruikt om die output in een file te vangen.

[...]
Filesystem state:         clean
[...]

Euh, hmm.

Ik maak de lijst niet groter dan dat het al is, het is een tekstbestand van 7,1MB

Prima. Ik heb nu weinig tijd, maar ik zal die output later in wat meer detail doornemen.

Nee, als ik /dev/sdb vervang door /dev/sdb1 niet meer nee Maar als ik /dev/sdb gebruik dan nog steeds.

Maar /dev/sdb is de hele schijf, met als inhoud een partitietabel plus je filesystem. /dev/sdb1 is de eerste partitie, met als inhoud je filesystem. Je moet dus /dev/sdb1 gebruiken, niet /dev/sdb.

En ik wil nog zeggen dat ik het heel erg waardeer dat je me wil helpen, want ik zit met mijn handen in het haar hoe ik dit kan oplossen.

Fijn dat het gewaardeerd wordt

In deze partitie zit toch 8 maanden werk wat ik niet graag verloren zie gaan

Als de data belangrijk is, dan wil ik je met klem aanraden om alleen nog maar read-only diagnostiek te doen tot we een beter idee hebben van wat er mis is. Anders is de kans gewoon te groot dat je het erger maakt (zeker omdat de kans bestaat dat het array in de war is).

[xxfile]

deadinspace schreef op woensdag 08 december 2010 @ 16:48:
Ok, dat ziet er iig normaal uit.

Gelukkig maar

Hmm, boven zeg je dat als je die vragen krijgt als je fsck.ext4 /dev/sdb1 doet, maar in de paste hieronder zie ik die niet terug?

[...]

In ieder geval, ik zou graag de output zien van de fsck-opdracht waarvan je in deze post een stuk van de ellenlange output gaf. Daarbij zou ik graag zien dat je de -n flag toevoegt (read-only en 'no' voor alle vragen), en redirection gebruikt om die output in een file te vangen.

[root@NAS NAS_User]# fsck.ext4 -n /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
Superblock has an invalid journal (inode 8).
Clear? no

fsck.ext4: Illegal inode number while checking ext3 journal for Data1

^^ dit is wat ik krijg als ik op alles "no" antwoord.
Alleen als ik op de eerste vraag "yes" antwoord (en dus niet op read-only, maar op write zet) dan krijg ik al die vragen, maar als ik dan verder ga delete hij de journal en maakt er een ext2-systeem van. Ik dacht niet dat ik daar blij mee moet worden als ik een partitie heb van 4,5TB, terwijl ext2 maar tot 2TB gaat

Prima. Ik heb nu weinig tijd, maar ik zal die output later in wat meer detail doornemen.

Om 4,5TB te behouden heb ik daar heel veel geduld en heel veel tijd voor over, dus is helemaal prima

Maar /dev/sdb is de hele schijf, met als inhoud een partitietabel plus je filesystem. /dev/sdb1 is de eerste partitie, met als inhoud je filesystem. Je moet dus /dev/sdb1 gebruiken, niet /dev/sdb.

Ik heb 3 partities:
/dev sda1 als ext4 filesystem bootable en 210MB (linux 0x83)
/dev/sda2 als LVM2 Physical Volume en 250GB (linux LVM 0x8e)
Dit staat beide op 1 HDD van 250GB wat op het primaire SATA-slot op het mobo aangesloten is. Hier staat het filesystem op.
/dev/sdb1 en de hidden /dev/sdb-1 is de RAID-partitie, wat aangestuurd wordt door de Dell Perc 5/i-kaart waar 4x1,5TB schijven onder hangen in RAID-5.

Als de data belangrijk is, dan wil ik je met klem aanraden om alleen nog maar read-only diagnostiek te doen tot we een beter idee hebben van wat er mis is. Anders is de kans gewoon te groot dat je het erger maakt (zeker omdat de kans bestaat dat het array in de war is).

Ik doe niks totdat je weer tijd hebt

[deadinspace]

xxfile schreef op maandag 06 december 2010 @ 18:33:
Ik heb alles uitgevoerd. De superblocks gevonden en ff in een tekstbestandje gezet. Toen 2 geprobeerd en bij elke krijg ik het volgende:

Dat was de output van mkfs.ext4 -n, nietwaar? Zou je die willen posten?

Zou je verder eens testdisk willen installeren en de volgende opties willen kiezen:

• Create new log file
• /dev/sdb1 selecteren, Proceed
• Non-partitioned media
• Advanced
• Superblock

En de output daarvan hier willen posten? Hij maakt ook een testdisk.log aan in de huidige directory, met onderaan diezelfde informatie.

xxfile schreef op woensdag 08 december 2010 @ 17:57:
Alleen als ik op de eerste vraag "yes" antwoord (en dus niet op read-only, maar op write zet) dan krijg ik al die vragen, maar als ik dan verder ga delete hij de journal en maakt er een ext2-systeem van. Ik dacht niet dat ik daar blij mee moet worden als ik een partitie heb van 4,5TB, terwijl ext2 maar tot 2TB gaat

Hmm, ik denk dat dat een beetje een ongelukkige woordkeuze is; waarschijnlijk maakt hij er dan ext4 zonder journal van (terwijl een journal nou net de belangrijkste feature was van ext3 tov ext2).

Overigens gaat ext2 volgensmij tot 16TiB onder de meeste omstandigheden.

Ik doe niks totdat je weer tijd hebt

Je mag best wat doen, maar alleen read-only dingen tenzij je heel erg zeker van je zaak bent

[xxfile]

deadinspace schreef op vrijdag 10 december 2010 @ 15:53:
Dat was de output van mkfs.ext4 -n, nietwaar? Zou je die willen posten?

Sorry dat ik zo laat reageer, maar dacht dat we in het andere topic verder gingen
Maar hier is de output:

[root@NAS NAS_User]# mke2fs -n /dev/sdb1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
274612224 inodes, 1098448387 blocks
54922419 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
33522 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848, 512000000, 550731776, 644972544

Zou je verder eens testdisk willen installeren en de volgende opties willen kiezen:

• Create new log file
• /dev/sdb1 selecteren, Proceed
• Non-partitioned media
• Advanced
• Superblock

En de output daarvan hier willen posten? Hij maakt ook een testdisk.log aan in de huidige directory, met onderaan diezelfde informatie.

Ik kan /dev/sdb1 niet selecteren, alleen /dev/sdb en daar herkent ie dan logischerwijs de partitie dan weer niet van. Maar ik heb ff op "analyse" gedrukt en dan vindt ie de partitie /dev/sdb1 en daar zie ik iig dat de structuur er nog goed uitziet \o/ Er zijn wel veel HD-films als deleted gemarkeerd (wordt toch met rode letters en cijfers aangegevens?), maar dit kunnen we wel weer terugvinden ergens Zit nog verder te rommelen in de files en het zijn alleen de mapjes die deleted zijn, de files zijn in orde \o/

Hmm, ik denk dat dat een beetje een ongelukkige woordkeuze is; waarschijnlijk maakt hij er dan ext4 zonder journal van (terwijl een journal nou net de belangrijkste feature was van ext3 tov ext2).

Overigens gaat ext2 volgensmij tot 16TiB onder de meeste omstandigheden.

Nou, ik gok er iig niet op. Zeker niet nu ik gewoon onze data weer zie met testdisk.
Op wikipedia staat iig dat het tot 2TiB gaat, maar ik weet dat wikipedia niet de betrouwbaarste site is qua info

Je mag best wat doen, maar alleen read-only dingen tenzij je heel erg zeker van je zaak bent

Nou, ik ben een redelijke linux-noob (na dit probleem een stukje minder noob ) en ben dus niet zeker van mijn zaak. Ergo: ik doe niks

[deadinspace]

xxfile schreef op zaterdag 11 december 2010 @ 14:09:
Sorry dat ik zo laat reageer, maar dacht dat we in het andere topic verder gingen

Er zijn hier meer mensen die er later ook nog wat aan zouden kunnen hebben

Maar hier is de output: [...]

Ik kan /dev/sdb1 niet selecteren, alleen /dev/sdb en daar herkent ie dan logischerwijs de partitie dan weer niet van. Maar ik heb ff op "analyse" gedrukt en dan vindt ie de partitie /dev/sdb1 en daar zie ik iig dat de structuur er nog goed uitziet \o/ Er zijn wel veel HD-films als deleted gemarkeerd (wordt toch met rode letters en cijfers aangegevens?), maar dit kunnen we wel weer terugvinden ergens Zit nog verder te rommelen in de files en het zijn alleen de mapjes die deleted zijn, de files zijn in orde \o/[/q]
Ok, zou mooi zijn als je met testdisk alles terug kon halen, maar ga natuurlijk wel voorzichtig te werk

Heb je nog naar superblocks gezocht met testdisk?

Nou, ik gok er iig niet op. Zeker niet nu ik gewoon onze data weer zie met testdisk.
Op wikipedia staat iig dat het tot 2TiB gaat, maar ik weet dat wikipedia niet de betrouwbaarste site is qua info

Ik zie op Wikipedia staan dat ext2 tot 2TiB - 32TiB gaat, afhankelijk van de omstandigheden. Onder jouw omstandigheden 16TiB

Maar goed, dat stukje verhaal is niet iets waar je je druk over hoeft te maken. (de vragen zijn vooral: wat is er precies mis, waarom is dat gebeurd, en hoe krijg je je data terug)

Nou, ik ben een redelijke linux-noob (na dit probleem een stukje minder noob ) en ben dus niet zeker van mijn zaak. Ergo: ik doe niks

Ja, maar het kan natuurlijk dat je advies van iemand anders krijgt dat je besluit op te volgen.

[xxfile]

Kee, een kleine test gedaan met testdisk en ik kon een serie kopieren \o/

Alleen wil testdisk de data naar de home-folder kopieren en dat wil ik niet natuurlijk. Niks is makkelijker om gelijk naar een groter volume te kopieren. Kun je de copy-directory in testdisk aanpassen?

deadinspace schreef op maandag 13 december 2010 @ 13:36:
Er zijn hier meer mensen die er later ook nog wat aan zouden kunnen hebben

True

Ik kan /dev/sdb1 niet selecteren, alleen /dev/sdb en daar herkent ie dan logischerwijs de partitie dan weer niet van. Maar ik heb ff op "analyse" gedrukt en dan vindt ie de partitie /dev/sdb1 en daar zie ik iig dat de structuur er nog goed uitziet \o/ Er zijn wel veel HD-films als deleted gemarkeerd (wordt toch met rode letters en cijfers aangegevens?), maar dit kunnen we wel weer terugvinden ergens Zit nog verder te rommelen in de files en het zijn alleen de mapjes die deleted zijn, de files zijn in orde \o/[/q]
Ok, zou mooi zijn als je met testdisk alles terug kon halen, maar ga natuurlijk wel voorzichtig te werk

Heb je nog naar superblocks gezocht met testdisk?

Dat probeerde ik uit te leggen dat ik /dev/sdb1 niet kon selecteren en alleen de RAID-array. En daarvan zegt testdisk dat hij de partitie als "unknown" ziet. En daardoor kan ik niet zoeken naar superblocks (die optie geeft ie niet weer).

Ik zie op Wikipedia staan dat ext2 tot 2TiB - 32TiB gaat, afhankelijk van de omstandigheden. Onder jouw omstandigheden 16TiB

Maar goed, dat stukje verhaal is niet iets waar je je druk over hoeft te maken. (de vragen zijn vooral: wat is er precies mis, waarom is dat gebeurd, en hoe krijg je je data terug)

Precies, andere tijden zijn dat

Ja, maar het kan natuurlijk dat je advies van iemand anders krijgt dat je besluit op te volgen.

Ik heb nu een optie om de data weer terug te krijgen en die volg ik nu. Als het niet mogelijk is om de copy-dir te veranderen naar een andere dir, dan duurt het wel lang voordat ik die data weer heb. Want ik kopieer dan eerst van testdisk naar home/NAS_User/recovey om vervolgens van home/NAS_User/recovery naar /dev/sdc1 te kopieren.

[ Voor 77% gewijzigd door xxfile op 13-12-2010 14:03 ]

[deadinspace]

xxfile schreef op maandag 13 december 2010 @ 13:54:
Kee, een kleine test gedaan met testdisk en ik kon een serie kopieren \o/

Mooi

Alleen wil testdisk de data naar de home-folder kopieren en dat wil ik niet natuurlijk. Niks is makkelijker om gelijk naar een groter volume te kopieren. Kun je de copy-directory in testdisk aanpassen?

Ik heb niet veel ervaring met testdisk, maar probeert hij misschien niet op te slaan naar het pad van waaruit je testdisk gestart hebt?

Mocht dat niet zo zijn en je geen opties kunnen vinden in testdisk, dan kun je waarschijnlijk wel een symlink aanleggen voor die recovery dir (of desnoods je hele homedir).

Dat probeerde ik uit te leggen dat ik /dev/sdb1 niet kon selecteren en alleen de RAID-array. En daarvan zegt testdisk dat hij de partitie als "unknown" ziet. En daardoor kan ik niet zoeken naar superblocks (die optie geeft ie niet weer).

Ahzo, ik had de indruk/hoop dat die optie er wel was na de "analyze" stap die je zelf gedaan had.

[xxfile]

Ik meld me hier weer als ik klaar ben met recoveren. Ik heb nu onze persoonlijke data en de series gerecovered. De films zijn nu aan de beurt en daar ben ik nog wel ff mee bezig

Als ik met de volgende schijf bezig ben zal ik eens in de home-dir een link plaatsen naar de plaats waar ik de data wil hebben. Misschien werkt dat idd

Nog 213GB te beschrijven op de recoverschijf en dan gaat de 1,5TB erin. Dan testen of het werkt en dan wachten op de 2TB die dan, hopelijk tegen de tijd dat de 1,5TB beschreven is, klaarligt bij de schijvenboer

[deadinspace]

Ok, succes

[xxfile]

Thanks, de 1,5TB zit er nu in en via een link in de home-dir werkt het om daar gelijk naar te kopieren \o/

[xxfile]

*schopje*

Klaar met recoveren en op ongeveer 20 films, een paar series, wat muziek-albums en wat persoonlijke data (wat niet zo belangrijk was, gelukkig ) na hebben we alles weer terug en voor zover ik kan zien gaat dat ook allemaal wel werken/afspelen etc.

Na wikken en wegen hebben we besloten om niet met herstellen door te zetten, want we vertrouwen die kaart voor geen meter meer. Hij mag nu zijn dagen slijten als controller (mocht hij nog fouten veroorzaken dan wordt hij alsnog vervangen) en we gaan softwarematige RAID draaien. Heel erg bedankt voor je hulp! Het wordt nog steeds zwaar gewaardeerd!

[deadinspace]

xxfile schreef op maandag 27 december 2010 @ 22:03:
Klaar met recoveren en op ongeveer 20 films, een paar series, wat muziek-albums en wat persoonlijke data (wat niet zo belangrijk was, gelukkig ) na hebben we alles weer terug en voor zover ik kan zien gaat dat ook allemaal wel werken/afspelen etc.

Jammer dat er wat dingen kwijt zijn, maar fijn om te horen dat de belangrijkste dingen gered zijn

Na wikken en wegen hebben we besloten om niet met herstellen door te zetten, want we vertrouwen die kaart voor geen meter meer. Hij mag nu zijn dagen slijten als controller (mocht hij nog fouten veroorzaken dan wordt hij alsnog vervangen) en we gaan softwarematige RAID draaien.

Als je die controller niet meer vertrouwt dan zou ik overwegen hem er helemaal uit te mikken. Het zou vervelend zijn als hij bijvoorbeeld datacorruptie veroorzaakt... Merk op dat RAID daar niet tegen beschermt (en dat backups van sommige dingen dus altijd belangrijk blijven).

Heel erg bedankt voor je hulp! Het wordt nog steeds zwaar gewaardeerd!

Graag gedaan, ik hoop dat jullie er iets aan gehad hebben

[xxfile]

&*"^£&*^&%"^%^%(*£%&£*) Wat een k*tkaart is het ook, tijdens het terugzetten van de data kon ik niks meer in Fedora en ja hoor, weer een schijf kwijt

We gaan maar voor een andere controller, misschien een RAID-controller, maar daar kijken we dan wel naar.

[jrs77]

He misschien heb je een goede reden, maar waarom gebruik je eigenlijk een RAID controller in linux?

Linux heeft namelijk erg goede software RAID. Dat scheelt je weer de aanschaf van een controller + je zit niet vast aan een specifieke hardware controller van een bepaald bedrijf.

Software RAID is ook simpel op te zetten. Ik vond dit een erg duidelijke howto die ik met succes heb gevolgd.

http://www.jamierf.co.uk/...ing-mdadm-in-ubuntu-9-10/

[xxfile]

We hadden ook, nadat ik had gerecovered, softwareRAID draaien via webmin. De RAID controller heeft, nadat ik de RAID-array had gemaakt en bezig was om de data weer terug te zetten (was voor de helft klaar ), er weer een schijf uit gekicked. Daardoor liep fedora helemaal vast en kon ik haast niks meer. Na een reboot gaf de BIOS van de controller al aan dat schijf 2 missing was. Sindsdien staat de NAS uit en willen we de controller vervangen en hopen dat ik niet meer vooraan hoeft te beginnen met kopiëren met de softwareRAID die we nu hebben We zijn al overgestapt op softwareRAID

De reden dat we een RAID controller gebruikten was dat we die als eerste in huis hadden, voordat we een NAS op hadden gezet. We wisten toen ook nog niet welke software we wilden gaan gebruiken voor de NAS. We zijn eerst van de hardware uitgegaan

[Onno]

xxfile schreef op donderdag 06 januari 2011 @ 21:34:
&*"^£&*^&%"^%^%(*£%&£*) Wat een k*tkaart is het ook, tijdens het terugzetten van de data kon ik niks meer in Fedora en ja hoor, weer een schijf kwijt

Zoiets gebeurt niet zomaar, ik zou dus eens gaan kijken wat die controller ervan vindt.

(want uiteraard heeft ie wel degelijk een eventlog)

[deadinspace]

Ook zoiets, is de schijf die er telkens uit gekickt wordt misschien niet toch gaar?

Je geeft de hele tijd de schuld daarvoor aan de controller, en ik heb dat maar klakkeloos aangenomen, maar misschien is het stiekem niet zo