SHR volume uitbreiding vs gebruikte ruimte

[Chatslet]

Ik heb een hele simpele vraag. Is er bij het gebruik van SHR een verband tussen de hoeveelheid data die je op een volume hebt staan en de tijd die nodig is om het volume uit te breiden naar andere schijven? Of gebeurt dit op stripe niveau?
Het zit namelijk zo, ik heb er nu een enkele 8TB schijf in en wil er 3 bij plaatsen. Op de schijf die er nu in zit heb ik een disk group met 1 btrfs volume. Daar heb ik nu ongeveer 900GB aan data op staan. Ik wil daar nog zo'n 7TB data bij zetten maar ik vraag me af dat als ik dat doe voordat ik de 3 extra schijven aan het volume toe voeg dit het proces niet veel langer laat duren.

[Pippin]

Dan beter eerst uitbreiden. Als er bij het uitbreiden iets fout gaat staat er je data op, dat wil je liever niet.

[Chatslet]

Die data staat nu veilig op een USB disk dus dat is het probleem niet.

[Pippin]

Das mooi.
Meer data betekent meer calculeren voor uitbreiding/rebuild.

[Chatslet]

Dus als ik het goed begrijp is SHR "filesystem aware" en gaat hij dus niet doodleuk ongebruikte ruimte kopiëren en daar parity voor berekenen?

[Pippin]

Dat is een goede vraag waar ik het antwoord niet 1-2-3 op weet.

[Hofstede]

Naar mijn ervaring heeft de hoeveelheid aanwezige data niet zo heel veel invloed op de tijd. Het hele uitbreidingsproces duurt echter wel lang, vooral bij meer schijven. Kan zelfs meer dan een dag zijn.

Wat in jouw geval veel sneller werkt:
- Maak een backup van de al aanwezige data.
- Verwijder het bestaande volume.
- Maak een nieuw volume aan met vier schijven.
- Zet de data terug.

[Ben(V)]

Ik kan je vertellen dat het uitbreiden wel degelijk afhankelijk is van de hoeveelheid data die op de schijf staat.
Ik heb dat regelmatig gedaan met mijn test Ds409 waar alleen DSMop stond.

Ligt ook voor de hand, de data moet in stukjes gehakt worden en over de schijenverdeelt worden.
Als er geen data op staat hoeft er alleeneen nieuwe structuur oogebouwd te worden.

[Chatslet]

Ik denk dat ik hem toch maar opnieuw ga opbouwen. Seagate Archive schijven lijken aanzienlijk trager te zijn met btrfs en aangezien dat nou juist is wat ik heb gekozen... Sequenciele schrijfsnelheid zakt constant in. Ben met een losse disk op een Linux machine wezen testen en zelfde verhaal. Zet ik er vervolgens een ext4 partitie op dan haal ik een constante schrijfsnelheid van 165 mb/s. Reden genoeg dus.

[Ben(V)]

Tja btfrs is gewoon een extra laag boven op het fiesystem (EXT4) en geeft dus extra overhead.
Heeft denk ik weinig met het type schijf te maken.
Dat de sequentiele schijfsnelheid afneemt heeft met de uitputting van de cache te maken op verschillende lagen(btrfs cache, ext4 cache en  de schijfcache).