freebsd gmirror. Отключить питание, когда оба винта в dirty.
Попрошу без матов в разделе! 
> Что будет?
AFAIK после подъёма более поздний будет считаться актуальным, станет clean, второй с ним синхронизируется. Само собой fsck отработает.
AFAIK после подъёма более поздний будет считаться актуальным, станет clean, второй с ним синхронизируется. Само собой fsck отработает.
И ещё как увидеть увеличение производительности.
Меряю так
первое испытание - это gmirror на 2 винтах
второе - это тоже самое, что первое, но в 2 потока
третье - тоже самео, что второе, но второй винт отключил.
gstat, когда 1 винт в рейде
когда 2 винта в рейде.
Т.е. нагрузка падает на каждый винт, но скорость не увеличивается.
Меряю так
первое испытание - это gmirror на 2 винтах
второе - это тоже самое, что первое, но в 2 потока
третье - тоже самео, что второе, но второй винт отключил.
41 steel ...igor/test(0/1)# dd of=/dev/null if=./out count=1000 bs=8M
1000+0 records in
1000+0 records out
8388608000 bytes transferred in 108.485965 secs (77324362 bytes/sec)
43 steel ...igor/test(0/1)# dd of=/dev/null if=./out count=1000 bs=8M
1000+0 records in
1000+0 records out
8388608000 bytes transferred in 115.193298 secs (72822014 bytes/sec)
45 steel ...igor/test(0/1)# dd of=/dev/null if=./out count=1000 bs=8M
1000+0 records in
1000+0 records out
8388608000 bytes transferred in 100.125510 secs (83780927 bytes/sec)
gstat, когда 1 винт в рейде
dT: 1.002s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
1 695 695 88508 1.2 0 0 0.0 80.2| ad4
0 0 0 0 0.0 0 0 0.0 0.0| cd0
1 695 695 88508 1.2 0 0 0.0 81.4| mirror/gm0
1 695 695 88508 1.2 0 0 0.0 82.0| mirror/gm0s1
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1a
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1b
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1d
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1e
1 695 695 88508 1.2 0 0 0.0 83.1| mirror/gm0s1f
когда 2 винта в рейде.
dT: 1.002s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
1 318 318 40639 1.3 0 0 0.0 40.4| ad4
0 0 0 0 0.0 0 0 0.0 0.0| cd0
1 638 638 81405 1.3 0 0 0.0 83.0| mirror/gm0
1 638 638 81405 1.3 0 0 0.0 83.6| mirror/gm0s1
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1a
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1b
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1d
0 0 0 0 0.0 0 0 0.0 0.0| mirror/gm0s1e
1 638 638 81405 1.3 0 0 0.0 84.6| mirror/gm0s1f
0 319 319 40767 1.3 0 0 0.0 41.6| ad6
Т.е. нагрузка падает на каждый винт, но скорость не увеличивается.
А каков balance и размер slice?
round-roubin
slice по-дефолту 4к. Но он только в split вроде.
сейчас split попробую.
Тоже не особо шустро.
slice по-дефолту 4к. Но он только в split вроде.
сейчас split попробую.
44 steel ...igor/test(0/1)# dd of=/dev/null if=./out count=1000 bs=8M
1000+0 records in
1000+0 records out
8388608000 bytes transferred in 98.996041 secs (84736803 bytes/sec)
Тоже не особо шустро.
59 ...igor/test(0/1)# gmirror list
Geom name: gm0
State: COMPLETE
Components: 2
Balance: split
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 3
ID: 4153345479
Providers:
1. Name: mirror/gm0
Mediasize: 250059349504 (233G)
Sectorsize: 512
Mode: r5w5e14
Consumers:
1. Name: ad4
Mediasize: 250059350016 (233G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 3
ID: 1242006122
2. Name: ad6
Mediasize: 250059350016 (233G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: NONE
GenID: 0
SyncID: 3
ID: 3654959128
вот ещё такую тулзу нашёл.
57 ...igor/test(0/1)# diskinfo -ctv /dev/mirror/gm0
/dev/mirror/gm0
512 # sectorsize
250059349504 # mediasize in bytes (233G)
488397167 # mediasize in sectors
I/O command overhead:
time to read 10MB block 0.152932 sec = 0.007 msec/sector
time to read 20480 sectors 1.482258 sec = 0.072 msec/sector
calculated command overhead = 0.065 msec/sector
Seek times:
Full stroke: 250 iter in 1.429145 sec = 5.717 msec
Half stroke: 250 iter in 1.438386 sec = 5.754 msec
Quarter stroke: 500 iter in 1.857158 sec = 3.714 msec
Short forward: 400 iter in 2.264431 sec = 5.661 msec
Short backward: 400 iter in 2.253672 sec = 5.634 msec
Seq outer: 2048 iter in 0.192459 sec = 0.094 msec
Seq inner: 2048 iter in 0.267604 sec = 0.131 msec
Transfer rates:
outside: 102400 kbytes in 1.037267 sec = 98721 kbytes/sec
middle: 102400 kbytes in 1.000639 sec = 102335 kbytes/sec
inside: 102400 kbytes in 1.397260 sec = 73286 kbytes/sec
58 ...igor/test(0/1)# diskinfo -ctv /dev/ad4
/dev/ad4
512 # sectorsize
250059350016 # mediasize in bytes (233G)
488397168 # mediasize in sectors
484521 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
6VY3MN9Y # Disk ident.
I/O command overhead:
time to read 10MB block 0.104304 sec = 0.005 msec/sector
time to read 20480 sectors 1.114105 sec = 0.054 msec/sector
calculated command overhead = 0.049 msec/sector
Seek times:
Full stroke: 250 iter in 6.570538 sec = 26.282 msec
Half stroke: 250 iter in 4.599710 sec = 18.399 msec
Quarter stroke: 500 iter in 7.266400 sec = 14.533 msec
Short forward: 400 iter in 3.313792 sec = 8.284 msec
Short backward: 400 iter in 2.699532 sec = 6.749 msec
Seq outer: 2048 iter in 0.137093 sec = 0.067 msec
Seq inner: 2048 iter in 0.213219 sec = 0.104 msec
Transfer rates:
outside: 102400 kbytes in 0.942182 sec = 108684 kbytes/sec
middle: 102400 kbytes in 0.858570 sec = 119268 kbytes/sec
inside: 102400 kbytes in 1.380443 sec = 74179 kbytes/sec
Прикольно. Сейчас затестю.
Неа. Это подразумевает обновлённый алгоритм load, который пока только в head.
"split" is very ineffective for devices with rotating media as HDDs.типа такая фигня, несмотря на неэффективность (хотя у 3ware получалось) была по умолчанию?
To be effective, it needs that transfer time reduction due to block
splitting was bigger then access time increase due to non-sequential
access.
Да. я так и подумал. Просто этот алгоритм не пробовал. РЕшил затестить.
в gstat видно, что чтение происходит по очереди с обоих винтов, но скороть увеличилась
в gstat видно, что чтение происходит по очереди с обоих винтов, но скороть увеличилась
25 steel ...igor/test(0/1)# dd of=/dev/null if=./out3 count=1000 bs=8M
1000+0 records in
1000+0 records out
8388608000 bytes transferred in 94.431350 secs (88832872 bytes/sec)
Оставить комментарий
Phoenix
Что будет?является ли gjournal просто заменой для s-u, чтобы async использовать и время на fsck не тратить или без него данные можно потерять?