GParted te lang durende grow dilemma

[Saturnus]

Ik heb/had draaien:
md0 in RAID1 bestaande uit sda1, sdb1 (OS,).
md1 in RAID1 bestaande uit sda2, sdb2 (data).
swap bestaande uit sda3, sdb3.

De swaps stonden op het einde van de disks. Logisch...well...not really, want daar is de snelheid 40MB/s, terwijl het vooraan tegen de 90MB/s is.

Ik heb sda1 en sdb1 daarom geshrinkt. 2GB vd 10GB eraf. Dit kon makkelijk omdat er 5GB in gebruik was.
Van de 2x 2GB die vrij kwam heb ik 2x 1GB swap gemaakt. (Die zit nu dus direct achter sda1, sdb1.)
De overgebleven 2x 1GB heb ik aan sda2, sdb2 (data) gegeven omdat die bijna vol was. Ook de vrijgekomen oud-swaps (2x 1GB) zijn aan data gegeven.

Mijn verwachting was dat dit een klus van 15 uur zou worden.
Het growen+moven duurt echter zo lang...dat hij nu (25 uur later) nog steeds niet op de helft is. Volgens de schatting is hij over een uur of 6 klaar met 1 disk. (Dan te bedenken dat richting het einde de snelheid flink inzakt reken ik meer op 9 uur.) Daarna moet dus nog een disk.

Nu ben ik er eigenlijk al wel ziek genoeg van. En zit ik na te denken...

1. Hoe reageert mdadm die voor de RAID1 zorgt (md0 en md1) hierop?
a. Als ik na 1 disk niet cancel zijn de 2 schijven met de 2 RAID1 configs in theorie gewoon identhiek. Gaan md0 en md1 weer rustig verder werken of gaat dat niet zo makkelijk?
b. Als ik wel cancel is mdadm waarschijnlijk de weg kwijt aangezien behalve dat de data out-of-sync is, de partities ook niet meer gelijk zijn.
Dan moet ik dus sowieso rebuilden nadat de partities gelijk zijn gemaakt...maar kan ik tenminste wel (helaas onveilig omdat RAID1 'uitstaat') bij mijn data.

Stel dat bij a md0 en md1 ook niet meer healthy zijn...en dus moet rebuilden (ookal zijn ze gelijk)...kan ik dan niet beter na disk 1 cancellen en booten naar de schijf die af is, vervolgens terwijl ik bij mijn data kan de boel weer gelijk trekken en rebuilden?

(Ja ik ben echt even de weg en had beter LVM kunnen gebruiken maar kende dat een jaar terug nog niet.)

[Saturnus]

Sorry om nu al te kicken maar het gaat wel erg raar.

Voor de 2 disks die gelijk zijn kiest hij bij de ene voor een blocksize van 128 sectors, bij de andere voor 256 sectors.
Volgens GParted is hier 128 sectors gelijk aan 64.00 KiB en dus 256 sectors = 128.00KB.

Via Google vertellen sites over een soort blocksize die bijna altijd 4096 is en anders (1-4k). File System's block size blijkbaar. Met sudo /sbin/dumpe2fs /dev/sd** | grep "Block size" heb ik die gecheckt, allemaal 4096.

Blijkbaar heeft GParted het dus over iets anders. Sommige sites hebben het over cluster size dat weer gelijk zou zijn aan block size? Ik zit al bijna een uur te googlen nu maar snap er helemaal niets meer van...

[gertvdijk]

Volgens mij vergeet jij helemaal dat je te maken hebt met twee lagen: DM voor RAID met daarbovenop een filesystem laag. Ext3 en vele andere hebben vaak een blocksize van 4k idd, maar de DM laag heeft dat meestal niet.
Je sd* devices zijn dus in jouw setup *niet* je filesystems en kan je dan ook *niet* checken met dumpe2fs! Wat je daar doet is een RAID volume (met superblocks, metadata ervan) met een filesystem tool behandelen. Op je md* devices staat een filesystem.

Met andere woorden: wat ben je aan het doen en weet je dat zelf wel?

Software RAID onder linux kan je growen/shrinken met mdadm (lees manpage), en shrinken kan als je eerst je filesystem erbovenop hebt geshrinkt (anders is de boel corrupt natuurlijk).

En voortaan LVM gebruiken idd. Maar let erop dat je dan wel met twee DM lagen werkt, plus een filesystem laag.

[ Voor 25% gewijzigd door gertvdijk op 08-12-2009 12:04 ]

[Saturnus]

Van lagen weet ik inderdaad niets.

Ok op MD* staan een fs's...maar volgens mij heb ik aan md* toch niets meer omdat sda en sdb nu verschillen?
Wat stel je voor om te doen?

Mijn idee was om te cancellen, te booten naar de disk die af is, dan alles van de verkeerde verwijderen, nieuwe partities maken (hopelijk wel met goede block size) en dan weer samenvoegen als RAID1.
Alhoewel het maar de vraag is of hij erheen kan booten...

[ Voor 7% gewijzigd door Saturnus op 08-12-2009 12:27 ]

[hostname]

Bovendien zou ik je swap ook niet in raid1 zetten.

[gertvdijk]

hostname schreef op dinsdag 08 december 2009 @ 15:51:
Bovendien zou ik je swap ook niet in raid1 zetten.

Dat doe je juist wel, omdat je bij het uitvallen of hotswappen van een harddisk (waar RAID1 voor is) je systeem nog doordraait of evt netjes kan afsluiten.

[gertvdijk]

Saturnus schreef op dinsdag 08 december 2009 @ 12:09:
Van lagen weet ik inderdaad niets.

Dat is toch logisch? RAID1 draait op een heel ander niveau dan je filesystem. Om even een vergelijking te maken: je gaat toch ook geen filesystem gooien op je harddisk zonder partities/partitietabel?

Saturnus schreef op dinsdag 08 december 2009 @ 12:09:
Ok op MD* staan een fs's...maar volgens mij heb ik aan md* toch niets meer omdat sda en sdb nu verschillen?

Tuurlijk wel. Je kan beide volumes mogelijk nog in degraded mode draaien en je data kopiëren, voor zover dat nog mogelijk is.

Saturnus schreef op dinsdag 08 december 2009 @ 12:09:
Wat stel je voor om te doen?

Datarecovery, lezen/leren hoe het moet en hoe dingen werken en vervolgens opnieuw beginnen.

Saturnus schreef op dinsdag 08 december 2009 @ 12:09:
Mijn idee was om te cancellen, te booten naar de disk die af is, dan alles van de verkeerde verwijderen

Dat zou ik ook nu proberen, maar ik vraag me af in hoeverre je RAID1 partitie nog valid RAID is en wordt herkend door de kernel als zijnde RAID1...

[Saturnus]

De swap is geen RAID1. Die 2 staan gewoon in de fstab op gelijke prio dus wordt een soort RAID0 heb ik ooit gelezen. Valt er 1 HDD weg dan is dat stukje swap weg en blijft er 1GB van de andere over. Een tijdje terug had ik het nog wel als RAID1. Zal eens overwegen dat weer te doen (tegen dataverlies).

Dat van lagen is opzich logisch ja maar omdat het allemaal nieuw is niet 123 te snappen.

De disk die af is kan ik zelfs booten, ik edit dan wel een GRUB command waarin nog '/dev/md0' staat naar '/dev/sda1.' Maar hierna werkt alles gewoon perfect alsof het een single disk config is. In mdadm is (gek genoeg?) geen spoor meer te vinden van een degraded RAID1.


Wat ik nu dus heb gedaan is die grow/move van de 2e disk gecancelled en alle partities van die HDD geknikkerd. Hierna dacht ik even "sfdisk -d /dev/sda | sfdisk /dev/sdb" te kunnen doen maar ik kreeg een 'sfdisk: can't open' error. (Nog gegoogled maar geen oplossing.)
Opeens zag ik een copy/paste optie in GParted. Dit werkte raar genoeg wel en daar is hij rond middernacht mee klaar.
Waar ik dan op hoop is dat ik simpel de boel weer kan samenvoegen tot RAID1. In theorie (ja weer in theorie...) hoeft er dan niets meer gedaan te worden omdat onder andere GRUB dus al een md0 verwacht.
Enkel sporen van de oude RAID1 setup zouden nog voor problemen kunnen zorgen.


Edit:
Ik zie wel dat de blocksize weer verschilt.


Ik bedenk opeens: Aangezien ik een 1 op 1 kopie van de layout en inhoud van de goede disk maak...kan dit dus geen beinvloedende factor zijn. Het zal dus wel een kopieer instelling van GParted zijn. Weer een mysterie opgelost.

[ Voor 12% gewijzigd door Saturnus op 08-12-2009 17:09 ]

[Saturnus]

En dan is het kopieren klaar en zijn ze opeens nog steeds niet gelijk...
sda, de goede disk is zoals het was/hoort.
sdb, waar alles van sda heen gekopieerd is zoals ik hierboven zei...is gewoon zo goed als leeg...WTF

[gertvdijk]

Saturnus schreef op dinsdag 08 december 2009 @ 23:17:
En dan is het kopieren klaar en zijn ze opeens nog steeds niet gelijk...
sda, de goede disk is zoals het was/hoort.
sdb, waar alles van sda heen gekopieerd is zoals ik hierboven zei...is gewoon zo goed als leeg...WTF

Is het al in je gedachte opgekomen om je werkende degraded array gewoon te laten rebuilden op je tweede schijf in plaats van helemaal buiten je RAID manager (mdadm) om alles zelf te lopen verkutten?
Nogmaals: lees je eens in hoe dingen werken. Je theorieën kloppen namelijk niet echt.

[ Voor 3% gewijzigd door gertvdijk op 08-12-2009 23:23 ]

[Saturnus]

Volgens mij is het te laat. Alles is opeens weg. Ik krijg nu echt een hartaanval hierzo. What the hell. 700GB data weg...

Als er nog iedeen zijn om het terug te halen...het zal mijn grootste dank ooit zijn...

Volgens mij is de fout het maken van een degraded met de goeie disk ofzo.

[ Voor 42% gewijzigd door Saturnus op 09-12-2009 00:14 ]

[gertvdijk]

Saturnus schreef op dinsdag 08 december 2009 @ 23:54:
Volgens mij is het te laat. Alles is opeens weg. Ik krijg nu echt een hartaanval hierzo. What the hell. 700GB data weg...

Dat heb je echt zelf gedaan dan. Je bent alles behalve zorgvuldig te werk gegaan.

Saturnus schreef op dinsdag 08 december 2009 @ 23:54:
Als er nog iedeen zijn om het terug te halen...het zal mijn grootste dank ooit zijn...

Dat is gewoon datarecovery, waarvoor zat tooltjes zijn, genoeg topics lopen enzo.

Saturnus schreef op dinsdag 08 december 2009 @ 23:54:
Volgens mij is de fout het maken van een degraded met de goeie disk ofzo.

Hier kan ik geen kaas van maken wat je bedoelt. Volgens mij is je fout het proberen te shrinken van een array op je eigen(wijze) manier door maar gewoon direct naar de schijven te gaan resizen in plaats van binnen de array (md*) te werken. Maar nog algemener: je weet niet wat je aan het doen bent.

[BCC]

Mogelijk nog erger: je hebt geen idee wat je aan het doen bent, zonder backup

[gertvdijk]

BCC schreef op woensdag 09 december 2009 @ 00:29:
Mogelijk nog erger: je hebt geen idee wat je aan het doen bent, zonder backup

Precies.
Gelijk ook een leermoment voor diegene die zich dat nog niet hebben gerealiseerd: RAID1 is geen backup, maar replicatie. User error wordt daarmee niet ondervangen en hardware falen maar gedeeltelijk.

[Saturnus]

Vorige was even een iets te emotionele reactie, ik probeer PhotoRec nu, maar dit ziet er echt niet goed uit.
Ja zonder backup, ik zat er laatst nog aan te denken...hardleers...

Dat ik het zelf gedaan heb, natuurlijk waar.
Ik probeer dingen met kennis die ik heb plus aanvulling van internet. Dat dat vaak niet de beste weg is tjah...en in dit geval totaal falen. Commands geven die je half snapt...

Als ik geweten had dat het binnen mdadm kon, had ik dat natuurlijk gedaan.


Wat ik denk dat er fout is gegaan:
Ik startte een degraded RAID1 met de goede hardeschijf. Vervolgens deed ik iets als mkfs ext3. Dat had niet gemoeten, en verklaard ook direct waarom die andere hdd opeens leeg was.
Het maakt blijkbaar een nieuwe ext op de array. Ik dacht dat deze command enkel mdadm vertelde dat het om een ext3 setup ging.

[gertvdijk]

Saturnus schreef op woensdag 09 december 2009 @ 00:42:
Ik startte een degraded RAID1 met de goede hardeschijf. Vervolgens deed ik iets als mkfs ext3. Dat had niet gemoeten [..]

Met alle respect, maar het probleem hier zit duidelijk voor het beeldscherm.
Als je al bang bent voor je data in deze problemen en je gaat niet eerst je data veiligstellen met een read only mount naar een veilig extern medium ben je gewoon erg dom bezig imo. Als je dan ook nog je filesystem opnieuw gaat aanmaken (quick format in Windows-termen) ...
Voordat je commando's runt kan je toch gewoon kijken wat het doet als je het niet snapt?

man <commando>

als je dat had gedaan voor mdadm was je allang opties tegengekomen die je wilde gebruiken.
Bovendien: snap het principe waar je mee bezig bent. Als je iets niet snapt: afblijven als het gaat om waardevolle data. En vraag je altijd af of het een 'nette' manier is wat je aan het doen bent ("Zou de rest van de wereld het ook zo aanpakken of ben ik verkeerd bezig of vind ik het wiel opnieuw uit?").

[Saturnus]

Natuurlijk heb je gelijk maar probeer je ook even te verplaatsen. Ik heb relatief weinig linux ervaring en al helemaal in dit soort situaties. Het komt vaker voor dat ik commands of een iets aangepaste vorm ervan invoer aan de hand van tutorials en dergelijke online, zonder volledig te snappen wat het doet. Het is dus een middel naar een doel. Dat ging meestal prima, maar in dit geval ging ik te recht op mijn doel af, namelijk de swap naar voren halen. Ging goed, daarna ontstonden de problemen.
Alles willen snappen neemt gigantisch veel tijd. In dit geval was het het wel waard geweest, maar het zei zo...

Ik denk dat als ik "man mkfs.ext3" had gedaan, het nog steeds fout zou zijn gegaan. md0 (die ik gister als degraded gemaakt had) stond namelijk in GParted zonder filesystem format. (Eerdere md's waren ext3.) Dus ik dacht, ok ik moet dat ding kenmerken als ext3 voordat het bruikbaar is.
Wanneer je op deze uitleg van mij kant reageert, onthoud dan wel dat dat voor jou een stukje makkelijker praten is. Zeker niet negatief bedoelt, ik zou wensen dat ik net zoveel ervaring met linux als jou had.

Wat je mij aan kan rekenen is het niet backuppen. Gigantische misser.

---

Update vd situatie:
Vannacht PhotoRec erover heen gehaald. 10-duizenden txt en dll bestanden heeft hij boven gehaald, rommel.
Tot mijn verbazing geen JPG waar ik iets mee kan. MP3 bestanden lijken 99% corrupt. Verder allemaal png's en andere meuk die blijkbaar in installers/iso's zaten. Helaas.
Zometeen ga ik eens een ander programma proberen.

[gertvdijk]

Saturnus schreef op woensdag 09 december 2009 @ 18:48:
Natuurlijk heb je gelijk maar probeer je ook even te verplaatsen. Ik heb relatief weinig linux ervaring en al helemaal in dit soort situaties. Het komt vaker voor dat ik commands of een iets aangepaste vorm ervan invoer aan de hand van tutorials en dergelijke online, zonder volledig te snappen wat het doet. Het is dus een middel naar een doel. Dat ging meestal prima, maar in dit geval ging ik te recht op mijn doel af, namelijk de swap naar voren halen. Ging goed, daarna ontstonden de problemen.
Alles willen snappen neemt gigantisch veel tijd. In dit geval was het het wel waard geweest, maar het zij zo...

Tja, als je de tijd niet wil nemen om dingen te snappen zal je jezelf nog wel vaker tegenkomen.

Saturnus schreef op woensdag 09 december 2009 @ 18:48:
Ik denk dat als ik "man mkfs.ext3" had gedaan, het nog steeds fout zou zijn gegaan. md0 (die ik gister als degraded gemaakt had) stond namelijk in GParted zonder filesystem format. (Eerdere md's waren ext3.) Dus ik dacht, ok ik moet dat ding kenmerken als ext3 voordat het bruikbaar is.

Sinds wanneer is "create filesystem" gelijk aan het kenmerken ervan?
Maar wat wel vaag is, is dat GParted het filesystem op md# niet herkende. Mogelijk was het al vernaggeld toen je je swap partitie naar voren haalde, omdat GParted volgens mij geen rekening houdt met de dubbele laag (RAID én filesystem) bij het moven van data, wat wel van groot belang is. Moven van RAID partities op zichzelf is al heel spannend trouwens en nou zit er ook nog een filesystem overheen...

Saturnus schreef op woensdag 09 december 2009 @ 18:48:
Wanneer je op deze uitleg van mij kant reageert, onthoud dan wel dat dat voor jou een stukje makkelijker praten is. Zeker niet negatief bedoelt, ik zou wensen dat ik net zoveel ervaring met linux als jou had.

True, zal ik wat meer proberen dan. Die ervaring heb ik overigens opgedaan door manpages te lezen en proberen te begrijpen wat ik doe. Dat is het startpunt van zelfeducatie namelijk.

Saturnus schreef op woensdag 09 december 2009 @ 18:48:Update vd situatie:
Vannacht PhotoRec erover heen gehaald. 10-duizenden txt en dll bestanden heeft hij boven gehaald, rommel.
Tot mijn verbazing geen JPG waar ik iets mee kan. MP3 bestanden lijken 99% corrupt. Verder allemaal png's en andere meuk die blijkbaar in installers/iso's zaten. Helaas.
Zometeen ga ik eens een ander programma proberen.

Ik zou eens een tooltje proberen die aware is van de RAID laag (met superblocks) i.c.m. ext3. Die zullen er vast wel zijn, maar mogelijk moet je gaan zoeken richting de forensische tools, omdat de commerciële applicaties meestal gericht zijn op consumentenartikelen en -configuraties (USB stick met FAT32, memory card, NTFS).