LVM - 5TB en "physical extent size"

[BSeB]

Ik heb zojuist zoals in een ander topic al geschreven een raid gecreerd. Nu ga ik hier 1 grote partitie opzetten op basis van LVM2.

LVM2 vraagt om "physical extent size".

In verschillende artikelen staat geschreven hoe deze berekend moet worden:

5TB = 5000000 / 64000 = afronden levert 64MB

Is dit de juiste manier, aangezien ik mijn raid op 256KB stripe heb ingesteld.
De vraag is dus is mijn instelling goed of fout en zo ja waarom.

From man vgcreate:

If the volume group metadata uses lvm1 format, extents can vary
in size from 8KB to 16GB and there is a limit of 65534 extents
in each logical volume. The default of 4 MB leads to a maximum
logical volume size of around 256GB.

If the volume group metadata uses lvm2 format those restrictions
do not apply, but having a large number of extents will slow
down the tools but have no impact on I/O performance to the log‐
ical volume. The smallest PE is 1KB.

It's a tradeoff. If you use smaller extents you may not be able
to grow beyond a certain size in LVM1 and even if you convert to
LVM2 some tools (but not normal usage) may be slow. OTOH, if you
use larger extents you waste some space if you have lots of small
logical volumes.

Dit betekent doordat ik maar 1 grote partitie heb, dat ik genoeg heb met ijn 64mb en hierdoor ook nooit tegen belemmeringen aanloop.

[ Voor 51% gewijzigd door BSeB op 05-06-2010 22:47 ]

[Q]

Met 64 MB extends kun je voorbij de 16 TB, mits je 64bit draait. Qua performance zul je gewoon moeten testen.

Edit:

http://sunoano.name/ws/lvm.html

With LVM2, there is no limit on the maximum numbers of extents per PV respectively LV. The default extent size is 4 MiB, and there is no need to change this for most configurations, because there is no I/O (Input/Output) performance penalty for smaller/bigger extent sizes. LVM tools usage, however, can suffer from high extent count, so using bigger extents can keep the extent count low. We need to be aware, that different extent sizes can not be mixed in a single VG, and changing the extent size is the single unsafe operation with the LVM i.e. it can destroy data. The best advice is to stick with the extent size chosen in the initial setup.

Kortom, met LVM2 kun je gewoon de 4 MB extend aanhouden en je er verder niet druk om maken.

[ Voor 104% gewijzigd door Q op 05-06-2010 22:55 ]

[BSeB]

Nu de schijf uiteindelijk is geformateerd in de 64 MB PE. Heb ik een test gedaan met de snelheid. Is dit een goede score voor de setup die ik heb?

- 3x WD20EARS
- 1x 3ware - 9650SE-24M8

code:

Hash:~ # hdparm -tT /dev/mapper/Storage_Backup-storage_02

/dev/mapper/Storage_Backup-storage_02:
 Timing cached reads:   2062 MB in  2.00 seconds = 1030.51 MB/sec
 Timing buffered disk reads:  626 MB in  3.01 seconds = 208.29 MB/sec
Hash:~ # hdparm -tT /dev/mapper/Storage_Backup-storage_02

/dev/mapper/Storage_Backup-storage_02:
 Timing cached reads:   2002 MB in  2.00 seconds = 1001.10 MB/sec
 Timing buffered disk reads:  646 MB in  3.01 seconds = 214.64 MB/sec
Hash:~ # hdparm -tT /dev/mapper/Storage_Backup-storage_02

/dev/mapper/Storage_Backup-storage_02:
 Timing cached reads:   1996 MB in  2.00 seconds = 997.89 MB/sec
 Timing buffered disk reads:  644 MB in  3.00 seconds = 214.66 MB/sec

[Q]

Tests met HDPARM zeggen niets. Bovendien geen idee hoeveel disks betrokken zijn en wat voor setup er is.

[BSeB]

code:

Hash:~ # /usr/bin/bonnie++ -d /home/storage_02/tijdelijk/ -s 16g -f -b -m Hash -u root
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Hash            16G           151110  43 49501  16           159298  21  96.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1092   9 +++++ +++  1333   7  1098  10 +++++ +++  1339   7
Hash,16G,,,151110,43,49501,16,,,159298,21,96.5,0,16,1092,9,+++++,+++,1333,7,1098,10,+++++,+++,1339,7

[Q]

Bonnie is kut. Doe eens een dd if=/dev/zero of=/mountpointvanjestorage/testfile.bin bs=1M count=10000 voor schrijf performance en een dd if=/mountpointvanjestorage/testfile.bin bs=1M voor je read performance.

Die files moeten groter zijn dan je ram, dus blocks van 1 mb x 10000 = 10 GB. Heb je 12 gig ram dan zou je dus meer moeten doen.

voorbeeld

code:

Mini:~# dd if=/dev/zero of=test.bin bs=1M count=300
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 9.86939 s, 31.9 MB/s

[BSeB]

Ah, oke, ik had het naar aanleiding van deze pagina gedaan:

http://www.googlux.com/bonnie.html

Overigens had ik net zonder beschrijving gepost, omdat dit van de server kwam. Ik ga nu even dezelfde test doen om iets te testen en erna ga ik deze test doen.

[BSeB]

code:

Hash:~ # /usr/bin/bonnie++ -d /home/storage_02/tijdelijk/ -s 16g -f -b -m Hash -u root
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
Hash            16G           151110  43 49501  16           159298  21  96.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1092   9 +++++ +++  1333   7  1098  10 +++++ +++  1339   7
Hash,16G,,,151110,43,49501,16,,,159298,21,96.5,0,16,1092,9,+++++,+++,1333,7,1098,10,+++++,+++,1339,7

Tweede test, zelfde resultaat.

Nu over op de dd test

code:

Hash:/home/abcabc# dd if=/dev/zero of=/home/storage_02/tijdelijk/test.bin bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 111.981 s, 93.6 MB/s

[ Voor 7% gewijzigd door BSeB op 03-08-2010 10:21 ]

[Q]

Dit is alleen de schrijf snelheid, die is ok voor de array van 3 disks van 5400 RPM. Ik zou als read snelheid ongeveer 150 tot 200 MB/s verwachten, ik zie in de bonny bench iets van 150 MB/s. Beide snelheden zijn iig genoeg om gigabit dicht te trekken.

[BSeB]

is het ook netjes voor de controller/disk config?
Daar heb ik niet zo veel verstand van

[Verwijderd]

De grote vraag is eerder: Is het ook sneller dan wanneer je gewoon 4MiB als PE size had gekozen?

[BSeB]

Ik heb 4MB PE, na de opmerking dat LVM2 geen invloed meer had van beperkte grote heb ik dit aangepast. Tevens zouden hierdoor gewoon alle LVM tools blijven werken itt 64MB PE.

[Verwijderd]

Ok, slimme zet want je zult mischien ooit nog eens op een andere systeem of met een live cd die schijfen willen benaderen voor recovery ofzo en dan is de default 4MiB een goede keuze als 64MiB geen merkbaar verschil oplevert.

Ik zou op je LVM trouwens minstens 2 LV maken. 1tje voor je bulk opslag en 1tje die je ook nog eens backup'd.