Raid-5 auf ICH9R Problem! - Seite 2

Seite 2 von 3 - Forum: Storage & Memory auf overclockers.at

URL: https://www.overclockers.at/storage-memory/raid-5_auf_ich9r_problem_191529/page_2 - zur Vollversion wechseln!

.dcp schrieb am 12.02.2008 um 10:19

ich spekulier auch auf ein raid5 mit 4x1tb / evtl 4x 750gb.

beide fälle sinds > 2GB.
eine große partition wird von mir favorisiert.

gibts ausser vista64 keine möglichkeit?
der Controller ist ein nvidia 430 onboard (performance spielt keine rolle, reiner netzwerkserver, max 30-40mb/s durchsatz).
da denke ich nicht das er lun carving kann.

hab kein problem mit vista, lizenzen hab ich eh, arbeiten muss ich auf dem ding auch nich wirklich.

GrandAdmiralThrawn schrieb am 12.02.2008 um 19:42

Sobald die 2TB Grenze überschritten wird, ist ein einzelner, konventioneller MBR machtlos.

Da gibts mehrere Lösungsansätze:

1.) LUN Carving

Können, soweit ich weiß nur teurere RAID Controller. Da wird der Array halt in mehrere <=2TB Teilstücke zerbrochen, die dann als logische Datenträger im Windows dastehen, jeder mit seinem eigenen MBR. Das läßt sich im Windows mittels dynamischem Datenträger wieder wie ein JBOD zusammenpfropfen, und als ein Laufwerk nutzen.

2.) 4096 Byte Sektoren, statt 512 Byte Sektoren

4kB Sektoren verachtfachen den Adressraum. Leider muß eine Festplatte physikalisch anders aufgebaut sein, mit konventionellen HDDs kappt's also nicht.

3.) GPT statt MBR

Partitioniert man die HDD mit GPT anstatt einem MBR, hat man auch weit mehr Adressraum. Hier wird mit 512 Byte Sektoren gearbeitet, aber das Adressfeld ist größer (ich weiß jetzt ned genau wieviele Bit, aber mehr als 32 halt). Nachteil: Das 64er Vista...

ÜBRIGENS:

Um so ein großes Laufwerk mit NTFS nutzen zu können, muß man auch die NTFS Blockgröße erhöhen, denn die ist per default auch auf 512 Bytes gesetzt, und NTFS hat eine 32-Bit Adressierung. Also wieder 2TB Größenlimit, dieses Mal auf Filesystemebene. Mit 4kB Blöcken lassen sich dann 16TB adressieren z.B. Darauf muß man beim Formatieren noch acht geben.

.dcp schrieb am 12.02.2008 um 19:49

1) afaik können als dynamische datenträger zusammengefügte luns nur von der _selben_ windows installation gelesen werden. windows futsch -> daten futsch.

ausserdem verbietets mein controller

2) fällt flach, obwohl ich irgendwo diesen lösungsansatz gelesen hatte, da stand nix von speziellen platten. naja, ich glaub dir mal

3) wollt ich eigentlich vermeiden, aber schein die einzige möglichkeit (für mich) zu sein.
dann heißts ram aufrüsten am server.

könnte ich denn 2 partitionen à 1,5 tb machen?

davebastard schrieb am 12.02.2008 um 20:03

wo ma grad bei dem thema sind, gibts das problem mit 64 bit linux auch? ich nehm mal an nein, oder ist man da vom controller her beschränkt ? möcht entweder 2,5TB oder 3 TB realisieren

graYeichL schrieb am 12.02.2008 um 20:18

Zitat von Deejay2k1
danke für die hilfe. IN der zwischenzeit hängt sich mein System beim booten auf (genau dort wo das Raid angezeigt wird im Bios)...
tja von einem fehler zum anderen =(

möglicherweise hast du kompatibilitätsprobleme zwischen der controller bios version und den installieren windows treiber

beides aktuell?

Deejay2k1 schrieb am 12.02.2008 um 22:37

beides aktuell werds am donnerstag mal checken indem ich im bios das raid auf normal einstelle und dann das raid neu mache und vista x64 installe

schizo schrieb am 13.02.2008 um 12:00

Zitat von .dcp
1) afaik können als dynamische datenträger zusammengefügte luns nur von der _selben_ windows installation gelesen werden. windows futsch -> daten futsch.

Bist du dir da sicher? Hab zuhause n dynamisches 4TB Software Raid5, dass ich eigentlich doch etwas länger haben möchte :eek:

chris_87 schrieb am 13.02.2008 um 12:41

Zitat von davebastard
wo ma grad bei dem thema sind, gibts das problem mit 64 bit linux auch? ich nehm mal an nein, oder ist man da vom controller her beschränkt ? möcht entweder 2,5TB oder 3 TB realisieren

Mein Controller hat auch eine Beschränkung wenn man Adaptec glaubt. Mehr als 512TB pro Array (bestehend aus max. 120 Festplatten) sind nicht möglich.

Ich vermute sehr stark dass auch andere Controller Einschränkungen haben

MfG Christoph

.dcp schrieb am 13.02.2008 um 13:05

Zitat von schizo
Bist du dir da sicher? Hab zuhause n dynamisches 4TB Software Raid5, dass ich eigentlich doch etwas länger haben möchte

absolut nicht, das hatn kollege zu meinen überlegungen begesteuert.

stieß mir auch etwas sauer auf.

Indigo schrieb am 13.02.2008 um 16:08

Zitat von .dcp
1) afaik können als dynamische datenträger zusammengefügte luns nur von der _selben_ windows installation gelesen werden. windows futsch -> daten futsch.

das gilt aber dann nur für LUNs, normale dynamische datenträger/arrays können von jedem windows gelesen werden

.dcp schrieb am 13.02.2008 um 16:24

ja stimmt. so hat ers wohl gemeint.
auf einem 32bit xp wär die einzige möglichkeit, <=2tb große luns zu erstellen und die als dynamischen datenträger zusammenzufügen.

schizo schrieb am 15.02.2008 um 10:30

Zitat von .dcp
ja stimmt. so hat ers wohl gemeint.
auf einem 32bit xp wär die einzige möglichkeit, <=2tb große luns zu erstellen und die als dynamischen datenträger zusammenzufügen.

Es gibt nen registry hack, mit dem Raid 1/5/6 Arrays gebildet werden können, standardmäßig Raid0 und afair JBOD - so braucht ma keine LUNs

.dcp schrieb am 15.02.2008 um 14:01

huh? das wär ja ein software raid, ich will ja mim controler ein raid bauen. unter vista64 / server20003sp1 könnt ich eine 3tb platte mounten. bei winxp32 müsst ich diese 3tb platte (also das raid) wieder aufteilen in virtuelle platten. dann wieder zusammenfügen in xp.

vllt versteh ich aber auch was falsch, kenn mich mit raids noch nich so aus.

schizo schrieb am 15.02.2008 um 14:09

Nein, hast schon recht, war gedanklich jetzt beim Software Raid. Wobei es mich trotzdem wundert, warum mehrere mittels JBOD zusammengeführte LUNs nur von der selben Windows installation gelesen werden können.

.dcp schrieb am 15.02.2008 um 14:26

wie gesagt, das hab ich so vom kollegen übernommen. im internet konnt ich das noch nicht bestätigen.