Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: TonVH op 14 september 2014, 20:51:42
-
Wat ik mij afvraag (kader: weten om te willen weten) is hoe de groei van een Raid Volume verloopt. Voor het gemak is elke HD 3TB.
Ik begin met 1 HD in een DS4xx dan heb ik alle data 1 maal voorhanden. Zeg maar Raid-nix.
Vervolgens zet ik er een 2e in. Nu zal alle data gespiegeld worden Oftewel Raid-1.
Nu wordt het interessant. Ik zet er een HD bij en heb dus 3 HD's. Er zou dus nu (ruimte voor) 6TB moeten zijn en daarnaast 3TB parity iv.m. beveiliging. Oftewel Raid-5.
Maar is dat zo?
Wordt dus alle gespiegelde data vervangen door parity-data of wordt die parity data alleen voor nieuwe files opgebouwd? Of, of, of? Ik kan mij een scala van mogelijkheden bedenken.
Nuttig effect van is dat je daarmee ondermeer kunt bepalen of het efficiënter is om tenminste 3 HD's tegelijk te installeren (dan being hij gelijk met SHR=Raid-5) of dat het niets uitmaakt.
Iemand die dit weet?
-
Als ik de synoogy website mag geloven word het een situatie vergelihkbaar raid 5, dus met 3tb in totaal 6 tb met 1 schijfbescherming. Ikzelf heb nu 2x 6tb in shr, dus effectief 6 tb met 1 schijfbescherming, dinsdag ontvang ik een nieuwe 6tb schijf dus kan ik het je de praktijk vertellen
-
https://www.synology.com/nl-nl/support/RAID_calculator (https://www.synology.com/nl-nl/support/RAID_calculator)
Hiermee kan je je SHR berekenen.
En ja het werkt wat je beschijft:
- 3TB + 3TB = 3TB
- 3TB + 3TB + 3TB = 6Tb
- mhhhh laat mijn rekenjuf dit niet zien ::)
Tijdens het uitbreiden van het volume wordt alle data via RAID5 weggeschreven.
Dus na afloop van het proces kan je er een schijf uit kunnen trekken en alle data is beschikbaar.
Enige uitzondering over de beschikbare ruimte als je een bestaand volume uitbreid t.o.v. een nieuw volume is met verschillende grootte van de schijven. Daar zit een verschil in. Ik weet niet waarom, wel dat het zo is.
-
Daarom duurt dat uitbreiden ook zo lang.
Systeem is enorm druk bezig om alle data over de schijven te verdelen.
-
Vandaag een 6tb schijf er bij gestoken bij mijn 2x6tb opstelling. En inderdaad krijg ik nu 1 schijf fouttollerantie en in totaal bijna 11tb ruimte.
Het uitbreiden duurt inderdaad verschrikkelijk lang, na 6 uur staat deze nog maar op 5,6%. Dus met dit tempo pas na 4dgn klaar.
-
Dat zal je leren. ;D
Moet je een 4bay NAS ook maar meteen vol stoppen.
-
Ha, daar heb je helemaal gelijk in! Helaas dacht de directrice hier thuis anders over :o
-
Die had je ook niks moeten vragen ;)
-
Vandaag een 6tb schijf er bij gestoken bij mijn 2x6tb opstelling. En inderdaad krijg ik nu 1 schijf fouttollerantie en in totaal bijna 11tb ruimte.
Het uitbreiden duurt inderdaad verschrikkelijk lang, na 6 uur staat deze nog maar op 5,6%. Dus met dit tempo pas na 4dgn klaar.
Kijk eens op de commandline met:
cat /proc/mdstat
Deze geeft aan de voortgang van het proces, in mijn geval:
md2 : active raid5 sda5[0] sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[=>...................] check = 5.0% (148345984/2925531648) finish=1464.8min speed=31597K/sec
Kun je volgens mij precies uitrekenen hoelang het gaat duren :P
-
Je kunt het ook versnellen echter, er is 1 commando die je eerst moet doen voordat je gaat herstellen.
(meestal leg ik dit niet meer voor omdat de meesten hier niet aan willen). ;)
VOOR HET STARTEN VAN HERSTEL > DIT IS EENMALIG (Dus, als je bv. 4 HD's gaat vervangen voor grotere):
mdadm --grow --bitmap=internal /dev/md2
Controle min/max:
sysctl dev.raid.speed_limit_min sysctl dev.raid.speed_limit_max
Eventueel wijzigen to speed up DIT KAN ON THE FLY*):
sysctl -w dev.raid.speed_limit_min=50000 sysctl -w dev.raid.speed_limit_max=200000
*)Je moet wel, als je b.v. die 4HD's aan het vervangen bent, je hebt je DS stop gezet om de volgende te vervangen en weer herstel hebt gestart, diw waarden weer instellen.
Als herstel is gestart kijken:
cat /proc/mdstat
Als alles klaar is dan:
mdadm --grow --bitmap=none /dev/md2
-
Als ik er over een tijdje weer een 6tb bij stop ga ik je tip uit voeren Birdy!
Maar even in de cmd line gekeken, nog 139uur :O
DS415play> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdc5[2] sda5[1] sdb5[0]
5855787648 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[=>...................] reshape = 8.8% (521052160/5855787648) finish=829 5.9min speed=10717K/sec
md1 : active raid1 sda2[0] sdb2[1] sdc2[2]
2097088 blocks [4/3] [UUU_]
md0 : active raid1 sda1[0] sdb1[1] sdc1[2]
2490176 blocks [4/3] [UUU_]
unused devices: <none>
-
Gezien TonVH andwoord heeft gekregen kaap ik dit topic even. Maar wat duurt dit langzaam zeg. De snelheid is de laatste 16uur enorm achteruit gegaan en staat nu nog maar op 13,12%. Het aanpassen van de minimale snelheden zet ook niet echt zoden aan de dijk. De minimale waarde staat op 5000 terwijl hij steeds tussen de 3000-4000 K/sec aan het werk is. Het gegeven dat mijn schijven voor 98% vol staan zal ook niet erg mee werken
-
Nee, dat zal de beperkende factor zijn. Juist voor dit soort klussen kan de NAS wat vrije schijfruimte op het bestaande volume goed gebruiken.
Misschien een optie om tijdelijk wat data van de NAS ergens anders weg te zetten?
-
Het aanpassen van de minimale snelheden zet ook niet echt zoden aan de dijk. De minimale waarde staat op 5000 terwijl hij steeds tussen de 3000-4000 K/sec aan het werk is. Het gegeven dat mijn schijven voor 98% vol staan zal ook niet erg mee werken
Maar ben je dan overnieuw begonnen ?
Omdat je n.l. ook eerst mdadm --grow --bitmap=internal /dev/md2
moet uitvoeren VOORDAT je het herstellen opstart.
-
Ah vandaar, ik dacht te begrijpen uit jou reactie (on the fly) en uit de reacties van een andere website na wat googlen het ook tijdens rebuilden werkt.
-
[attachimg=1]
;)
-
Begrijpend lezen is niet mijn sterkste punt ::)
Misschien een optie om tijdelijk wat data van de NAS ergens anders weg te zetten?
Heb een USB2.0 externe hdd als backup, dat zet geen zoden aan de dijk. Voor de rest alleen wat SSD in de PC's
Neen, denk dat ik maar geduld moet hebben
-
Woensdag was de snelheid terug gezakt tot 2000K/sec en zou het ruim een maand duren voordat deze klaar was. Blijkbaar was de rede hiervoor een uitgebreide smart-test welke ingesteld stond in de cronjob. De test zelf was ook enorm vertraagd want duurde al ruim 24u. Test geannulleerd, cronjobs tijdelijk uitgesteld en de snelheid steeg weer naar 10000-13000K/sec. Belangrijk dus om geplande test uit te zetten tijdens het uitbreiden ::)
-
Ben nu zelf 4x 2TB HD's aan het vervangen voor 4x 4TB HD's.
Met die eerder genoemde aanpassingen haal ik de volgende snelheid met rebuilden:
[attachimg=1]
Dat schiet lekker op, ligt er natuurlijk ook aan hoe snel de schijven zijn en de DS en ook nog wat zitten spelen met de dev.raid.speed_limit_min instelling.
-
Ik lees dit alles te laat. Ik heb net 30 uur geleden een 3e 3TB schijf toegevoegd. De nas is nu halverwege de uitbreiding.
GedeeldeData> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdc5[2] sda5[1] sdb5[0]
2925531648 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[=========>...........] reshape = 47.8% (1398613368/2925531648) finish=2696.7min speed=9436K/sec
md1 : active raid1 sdc2[2] sda2[0] sdb2[1]
2097088 blocks [4/3] [UUU_]
md0 : active raid1 sdc1[2] sda1[0] sdb1[1]
2490176 blocks [4/3] [UUU_]
unused devices: <none>
Anderzijds lag die schijf al 1 maand ongebruikt naast de nas, dus de meeste vertraging is mijn schuld. Schijfgebruik staat al 30 uur op 40%, dus het systeem houd nog 60% achter de hand om gewoon door te kunnen werken.
-
Ondanks dat
mdadm --grow --bitmap=internal
niet is uitgevoerd (kan niet on the fly), kun je toch proberen of sysctl -w dev.raid.speed_limit_min=50000
(kan on the fly) nog een beetje kan helpen in het versnellen.
Of "speel" even met de waarde, baat het niet schaad het niet. ;)
-
Ik wil wel begrijpen wat zo'n commando doet.
De mac (FreeBSD) geeft als manual voor sysctl:
SYSCTL(8) BSD System Manager's Manual SYSCTL(8)
NAME
sysctl -- get or set kernel state
SYNOPSIS
sysctl [-bdehiNnoqx] name[=value] ...
sysctl [-bdehNnoqx] -a
DESCRIPTION
The sysctl utility retrieves kernel state and allows processes with appropriate privilege to set kernel state. The state to be
retrieved or set is described using a ``Management Information Base'' (``MIB'') style name, described as a dotted set of compo-
nents.
The following options are available:
-A Equivalent to -o -a (for compatibility).
-a List all the currently available non-opaque values. This option is ignored if one or more variable names are specified on
the command line.
-b Force the value of the variable(s) to be output in raw, binary format. No names are printed and no terminating newlines
are output. This is mostly useful with a single variable.
-d Print the description of the variable instead of its value.
-e Separate the name and the value of the variable(s) with `='. This is useful for producing output which can be fed back to
the sysctl utility. This option is ignored if either -N or -n is specified, or a variable is being set.
-h Format output for human, rather than machine, readability.
-i Ignore unknown OIDs. The purpose is to make use of sysctl for collecting data from a variety of machines (not all of which
are necessarily running exactly the same software) easier.
-N Show only variable names, not their values. This is particularly useful with shells that offer programmable completion.
To enable completion of variable names in zsh(1) (ports/shells/zsh), use the following code:
listsysctls () { set -A reply $(sysctl -AN ${1%.*}) }
compctl -K listsysctls sysctl
To enable completion of variable names in tcsh(1), use:
complete sysctl 'n/*/`sysctl -Na`/'
-n Show only variable values, not their names. This option is useful for setting shell variables. For instance, to save the
pagesize in variable psize, use:
set psize=`sysctl -n hw.pagesize`
-o Show opaque variables (which are normally suppressed). The format and length are printed, as well as a hex dump of the
first sixteen bytes of the value.
-q Suppress some warnings generated by sysctl to standard error.
-X Equivalent to -x -a (for compatibility).
-x As -o, but prints a hex dump of the entire value instead of just the first few bytes.
The information available from sysctl consists of integers, strings, and opaque types. The sysctl utility only knows about a cou-
ple of opaque types, and will resort to hexdumps for the rest. The opaque information is much more useful if retrieved by special
purpose programs such as ps(1), systat(1), and netstat(1).
The string and integer information is summarized below. For a detailed description of these variable see sysctl(3).
The changeable column indicates whether a process with appropriate privilege can change the value. String and integer values can
be set using sysctl.
Name Type Changeable
hw.activecpu integer no
hw.busfrequency integer no
hw.busfrequency_max integer no
hw.busfrequency_min integer no
hw.byteorder integer no
hw.cacheconfig struct no
hw.cachelinesize integer no
hw.cachesize struct no
hw.cpu64bit_capable integer no
hw.cpufamily integer no
hw.cpufrequency integer no
hw.cpufrequency_max integer no
hw.cpufrequency_min integer no
hw.cpusubtype integer no
hw.cputhreadtype integer no
hw.cputype integer no
hw.l1dcachesize integer no
hw.l1icachesize integer no
hw.l2cachesize integer no
hw.l3cachesize integer no
hw.logicalcpu integer no
hw.logicalcpu_max integer no
hw.memsize integer no
hw.ncpu integer no
hw.packages integer no
hw.pagesize integer no
hw.physicalcpu integer no
hw.physicalcpu_max integer no
hw.tbfrequency integer no
kern.argmax integer no
kern.bootargs string no
kern.boottime struct no
kern.clockrate struct no
kern.coredump integer yes
kern.corefile string yes
kern.flush_cache_on_write integer yes
kern.hostid integer yes
kern.hostname string yes
kern.job_control integer no
kern.maxfiles integer yes
kern.maxfilesperproc integer yes
kern.maxnbuf integer yes
kern.maxproc integer yes
kern.maxprocperuid integer yes
kern.maxvnodes integer yes
kern.msgbuf integer yes
kern.nbuf integer no
kern.netboot integer no
kern.ngroups integer no
kern.nisdomainname string yes
kern.num_files integer no
kern.num_tasks integer no
kern.num_taskthreads integer no
kern.num_threads integer no
kern.num_vnodes integer no
kern.nx integer yes
kern.osrelease string no
kern.osrevision integer no
kern.ostype string no
kern.osversion string yes
kern.posix1version integer no
kern.procname string yes
kern.safeboot integer no
kern.saved_ids integer no
kern.secure_kernel integer no
kern.securelevel integer yes
kern.singleuser integer no
kern.sleeptime struct no
kern.slide integer no
kern.stack_depth_max integer no
kern.stack_size integer no
kern.sugid_coredump integer yes
kern.sugid_scripts integer yes
kern.symfile string no
kern.usrstack integer no
kern.usrstack64 integer no
kern.uuid string no
kern.version string no
kern.waketime struct no
machdep.cpu.address_bits.physical integer no
machdep.cpu.address_bits.virtual integer no
machdep.cpu.brand integer no
machdep.cpu.brand_string string no
machdep.cpu.cache.L2_associativity integer no
machdep.cpu.cache.linesize integer no
machdep.cpu.cache.size integer no
machdep.cpu.core_count integer no
machdep.cpu.cores_per_package integer no
machdep.cpu.extfamily integer no
machdep.cpu.extfeature_bits integer no
machdep.cpu.extfeatures string no
machdep.cpu.extmodel integer no
machdep.cpu.family integer no
machdep.cpu.feature_bits integer no
machdep.cpu.features string no
machdep.cpu.leaf7_feature_bits integer no
machdep.cpu.leaf7_features string no
machdep.cpu.logical_per_package integer no
machdep.cpu.max_basic integer no
machdep.cpu.max_ext integer no
machdep.cpu.microcode_version integer no
machdep.cpu.model integer no
machdep.cpu.processor_flag integer no
machdep.cpu.signature integer no
machdep.cpu.stepping integer no
machdep.cpu.thread_count integer no
machdep.cpu.tlb.data.large integer no
machdep.cpu.tlb.data.large_level1 integer no
machdep.cpu.tlb.data.small integer no
machdep.cpu.tlb.data.small_level1 integer no
machdep.cpu.tlb.inst.large integer no
machdep.cpu.tlb.inst.small integer no
machdep.cpu.tlb.shared integer no
machdep.cpu.ucupdate integer yes
machdep.cpu.vendor string no
machdep.cpu.xsave.extended_state integer no
machdep.tsc.deep_idle_rebase integer yes
machdep.tsc.frequency integer no
machdep.tsc.nanotime.generation integer no
machdep.tsc.nanotime.shift integer no
net.inet.ip.forwarding integer yes
net.inet.ip.portrange.first integer yes
net.inet.ip.portrange.hifirst integer yes
net.inet.ip.portrange.hilast integer yes
net.inet.ip.portrange.last integer yes
net.inet.ip.portrange.lowfirst integer yes
net.inet.ip.portrange.lowlast integer yes
net.inet.ip.redirect integer yes
net.inet.ip.ttl integer yes
net.inet.udp.checksum integer yes
net.inet.udp.maxdgram integer yes
vm.loadavg struct no
vm.swapusage struct no
user.bc_base_max integer no
user.bc_dim_max integer no
user.bc_scale_max integer no
user.bc_string_max integer no
user.coll_weights_max integer no
user.cs_path string no
user.expr_nest_max integer no
user.line_max integer no
user.posix2_c_bind integer no
user.posix2_c_dev integer no
user.posix2_char_term integer no
user.posix2_fort_dev integer no
user.posix2_fort_run integer no
user.posix2_localedef integer no
user.posix2_sw_dev integer no
user.posix2_upe integer no
user.posix2_version integer no
user.re_dup_max integer no
user.stream_max integer no
user.tzname_max integer no
FILES
<sys/sysctl.h> definitions for top level identifiers, second level kernel and hardware identifiers, and user level identi-
fiers
<sys/socket.h> definitions for second level network identifiers
<sys/gmon.h> definitions for third level profiling identifiers
<vm/vm_param.h> definitions for second level virtual memory identifiers
<netinet/in.h> definitions for third level Internet identifiers and fourth level IP identifiers
<netinet/icmp_var.h> definitions for fourth level ICMP identifiers
<netinet/udp_var.h> definitions for fourth level UDP identifiers
EXAMPLES
For example, to retrieve the maximum number of processes allowed in the system, one would use the following request:
sysctl kern.maxproc
To set the maximum number of processes allowed per uid to 1000, one would use the following request:
sysctl kern.maxprocperuid=1000
Information about the system clock rate may be obtained with:
sysctl kern.clockrate
Information about the load average history may be obtained with:
sysctl vm.loadavg
More variables than these exist, and the best and likely only place to search for their deeper meaning is undoubtedly the source
where they are defined.
COMPATIBILITY
The -w option has been deprecated and is silently ignored.
SEE ALSO
sysctl(3), sysctl.conf(5)
HISTORY
A sysctl utility first appeared in 4.4BSD.
In FreeBSD 2.2, sysctl was significantly remodeled.
BSD January 17, 2011 BSD
Daar staat bij de -w parameter dat hij deprecated is en geïngnoreerd wordt. Maar dus niet waar hij ooit voor bedoeld was, of op de nas nog voor gebruikt wordt.
Maar ik zie dat in BusyBox een veel uitgekledere versie van dit commando zit. :|
-
[attachimg=1]
En kijk hier. (http://linux.about.com/library/cmd/blcmdl8_sysctl.htm)
-
Als je data je dierbaar is zou ik nu niet gaan "rommelen" maar gewoon geduld hebben en afwachten. Als die commando's het proces vernaggelen dan heb je een probleem.
-
Dat was precies mijn insteek: Ik wil eerst weten wat de default waarde van de parameter is, voordat ik hem tijdelijk op 50000 zou zetten. Commandos die zo diep in de kernel ingrijpen moet je echt snappen voordat je ze gebruikt.
-
Met dat commando vernaggel je helemaal niets, spreek uit ervaring(en), maar goed.....afwachten dus maar ;)
-
Ik zag dat de default op 10000 staat. Maar ook zonder iets aan te passen zie ik plots dat de snelheid 10x zo groot geworden en en de berekende eindtijd nu over 4 uur is i.p.v. de eerder aangegeven 45 uur. Waarschijnlijk zit hij nu op het deel van de disk waar toch al geen data op stond. (was ca 50% vol)
GedeeldeData> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdc5[2] sda5[1] sdb5[0]
2925531648 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[===========>.........] reshape = 59.4% (1739746688/2925531648) finish=218.8min speed=90320K/sec
md1 : active raid1 sdc2[2] sda2[0] sdb2[1]
2097088 blocks [4/3] [UUU_]
md0 : active raid1 sdc1[2] sda1[0] sdb1[1]
2490176 blocks [4/3] [UUU_]