Partitioneren array van 2.4tb wil niet

[Paul]

Ik heb hier een Areca raidcontroller in mijn fileserver zitten (Debian Sarge/Stable, zelfgebakken kernel 2.6.11.5 met Areca drivers 1.20.0.02 met smp-D-process-fix)

Tot gisteren hingen hier 8 300gb schijven aan. Daar kwam gisteren verandering in, ik wilde er een schijf meer inhangen.

Ik had eerst met wat schijven die ik nog heb liggen getest, 3 stuks in een raid5, filesystem aanmaken en wat files erop zetten. Vervolgens in de webbios van de controller de raidset en de volumeset uitgebreid. fdisk zag netjes dat er wat veranderd was en na het verwijderen en opnieuw aanmaken van de (nu grotere) partitie op hetzelfde startpunt, kon ik van de extra vrije ruimte genieten.

Deze testopstelling was met schijven van 250gb, dus dat ging van 500 naar 750gb, en werkte vlekkeloos.

Echter nu, ik ging van 2100 naar 2400gb. Eerst zoveel mogelijk gebackupped (6x 250gb in raid0 en dan mis ik nog een hoop, maar daar heb ik iig de filelist van), toen de raidset en de volumeset uitgebreid. Na een uur of 10 was hij daar eindelijk mee klaar, maar toen begon het gezeik.

cfdisk miept dat hij de grootte niet kan vinden en stopt. Dit kende ik al, dus dan maar een wat lastiger fdisk, namelijk fdisk.
Die komt met de melding "You must set cylinders. You can do this in the extra functions menu.".

Euh, tja, fijn... En hoe weet ik welk getalletje ik daar in moet vullen? hdparm komt met een geomerty van 24433/255/63, dus ik vul 24433 in. Hmm, fout, veel te klein. Wel geven alle programma's concequent die 255/63 aan, dus daar ben ik mee gaan rekenen.

Een van de dingen die in dmesg en als ik een partitietabel write tevoorscijn komen is:

sdc: very big device. try to use READ CAPACITY(16).
SCSI device sdc: 4687499264 512-byte hdwr sectors (2400000 MB)
SCSI device sdc: drive cache: write back
 sdc:
sdc: very big device. try to use READ CAPACITY(16).
SCSI device sdc: 4687499264 512-byte hdwr sectors (2400000 MB)
SCSI device sdc: drive cache: write back
 sdc:

Met 255 heads en 63 sectoren per track en 512 byte sectoren je op 8225280 bytes per cylinder, zoals p(rint) in fdisk me zo mooi weet te vertellen.

Deel ik dat op die 2400000 MB dan kom ik (afgerond) op 305975 cylinders uit.
neem ik die 468..,.. sectoren en deel ik dat door 63 en 255 dan kom ik, wederom afgerond (en hier vind ik dat wel erg vreemd, dat het een kommagetal is) op 291783 cylinders uit.

Nou, veilige voor het onveilige: 291783 invullen in fdisk dan maar. writen: zelfde melding @ start fdisk. Na invullen cylinders partitie aanmaken dan komt hij met een max cylinder van 24434...

Ik zit dus met een probleem. Mijn array laat zich niet partitioneren, en ik laat mijn backup natuurlijk het liefste zo kopt mogelijk op die raid0 van 6 schijven staan...

Die fdisk-melding komt maar een paar keer voor op Google, en niet op GoT, voor zover ik heb gezien waren ze geen van allen nuttig. Zoeken naar 2tb levert met name resultaten van 3 jaar oud op en hebben het dan over beperkingen in filesystems etc.

Wie helpt?

[Nitroglycerine]

De melding komt ook als je een andere schijf als laatste gebruikt?

Het klinkt me in de oren als een beperking binnen Linux. De grootte (TB) kan ik me niet voorstellen, wel het aantal physical extends/partitions. Op AIX en HP-UX ben ik in het verleden tegen situaties aangelopen dat ik voor erg grote filesystemen (volumes van 500 GB e.d.) een grotere physical extend moest gebruiken. Dus geen 512 KB zoals je hier hebt gebruikt, maar misschien 2 MB.

[Paul]

Nitroglycerine schreef op donderdag 28 juli 2005 @ 02:21:
De melding komt ook als je een andere schijf als laatste gebruikt?

Leg uit? Wat gebruik ik nu als laatste? Ik heb een schijf toegevoegd aan de array, dit is allemaal goed gegaan, en vanaf dat punt heb ik met losse schijven niets meer te maken, de Areca-driver levert 1 block-device aan, namelijk de gehele array. Dat het intern 9 schijven heeft is daar totaal niet van belang.

Het klinkt me in de oren als een beperking binnen Linux. De grootte (TB) kan ik me niet voorstellen, wel het aantal physical extends/partitions. Op AIX en HP-UX ben ik in het verleden tegen situaties aangelopen dat ik voor erg grote filesystemen (volumes van 500 GB e.d.) een grotere physical extend moest gebruiken. Dus geen 512 KB zoals je hier hebt gebruikt, maar misschien 2 MB.

500gb is in dit voorbeeld peanuts, arrays van 0.5, 0.75 en 2.1tb gingen ook perfect.

[Nitroglycerine]

Ik bedoel dat je mogelijk tegen een beperking van veritas volume manager aan bent gelopen. Die worden niet altijd even duidelijk weergegeven.

[Paul]

Veritas Volume Manager? Veritas is toch een of ander backup pakket ofzo?

Ik heb het hier gewoon over normaal Linux, geen backuppaketten of zo, gewoon standaard Linux / fdisk

[thunder7]

Paul Nieuwkamp schreef op donderdag 28 juli 2005 @ 11:19:
Veritas Volume Manager? Veritas is toch een of ander backup pakket ofzo?

Ik heb het hier gewoon over normaal Linux, geen backuppaketten of zo, gewoon standaard Linux / fdisk

start google, type 'linux raid very big device' en zie

https://www.redhat.com/ar...005-January/msg01010.html

dit ziet er ook wel interessant uit (want iemand die het probleem opgelost heeft):

http://lisas.de/blog/adrian/2005/Jul

Kortom, zelf even zoeken - dit is toch niet zo moeilijk te vinden?

[Verwijderd]

Of gewoon een filesystem gebruiken dat er voor gemaakt is, zaols XFS of JFS Maar goed je zit waarschijnlijk vast aan iets anders.

[Kippenijzer]

In linux zit tegenwoordig een expliciete optie voor large block devices in de kernel. Volgens mij is dit voor alles van 2TB en groter. Je vorige disk, uitgegaan van 2100000MB (en dat dat dmv 1000/K omrekenen naar bits, en dan dmv 1024/K naar TB omrekenen) is denk ik net geen 2 "echte" TB, terwijl je 2.4M-MB dit wel is, staat deze optie aan in je kernel?

edit:
Hoofdletters en kleine letters voor eenheden, who cares???

[ Voor 12% gewijzigd door Kippenijzer op 28-07-2005 22:48 ]

[Paul]

thunder7 schreef op donderdag 28 juli 2005 @ 22:19:
[...]


start google, type 'linux raid very big device' en zie ... Kortom, zelf even zoeken - dit is toch niet zo moeilijk te vinden?

Ik heb gezocht, 3 uur lang (op een vrij brakke verbinding ), en uiteraard overal op behalve op die 3 woordjes: very big device... Ik had me meer op de "fout"melding van fdisk geconcentreerd...

Verwijderd schreef op donderdag 28 juli 2005 @ 22:39:
Of gewoon een filesystem gebruiken dat er voor gemaakt is, zaols XFS of JFS Maar goed je zit waarschijnlijk vast aan iets anders.

Euh, lees mijn verhaal nog eens, maar nu _goed_ ofzo...

Kippenijzer schreef op donderdag 28 juli 2005 @ 22:45:
In linux zit tegenwoordig een expliciete optie voor large block devices in de kernel, staat deze optie aan in je kernel?

Yup.

Ik heb nu mbv van parted (maar ik heb ook de nieuwste drivers van Areca gedownload en mijn kernel opnieuw gecompileerd) inderdaad een partitie aangemaakt die werkt. Enige probleem nu is dat ik alle data die erop stond kwijt ben.
Voordat je heel hard _DUH_ gaat roepen:
Met fdisk kun je kijken waar _exact_ een partitie begint, deze vervolgens verwijderen en ten slotte een nieuwe partitie aanmaken die op de zelfde plaats begint als de vorige, maar de (nu grotere) gehele schijf gebruikt. Hierna kon je je schijf geoon weer mounten en xfs_growfs erop loslaten zodat het FS ook van de nieuwe ruimte gebruik maakt.

Ik had toch eigenlijk wel graag dat dit weer zou werken, want ik heb, als ik er weer een schijf bij wil proppen, niet echt de mogelijkheid om 2.2TB te backuppen...

[usr-local-dick]

Of gewoon een filesystem gebruiken dat er voor gemaakt is, zaols XFS of JFS

De TS is daar nog niet aan toegekomen. Hij wil eerst zijn device partitioneren. Als dat gedaan is dan is het tijd om een filesysteem aan te maken

Als die tijd daar is dan kies je natuurlijk NIET voor XFS maar voor ext3. Maar dat terzijde.

Ik had ook probs met een 2Tb partitie tijdens de installatie, en cfdisk *leek* de truuk te zijn. Uit verschillende berichten maak ik nu op dat dit ook niet goed werkt. Waarschijnlijk zat ik net voor een grens in de buurt van de 2Tb. Voor het debuggen van mijn custom Sarge installer zou ik graag een proefkonijn hebben die hem installeert op een volume van ruim 2 Gb en kijken wat er gebeurt....

De oplossing die wordt aangedragen op diverse forums is parted (of dat met de Sarge installer kan weet ik zo 1-2-3 niet).

PS. Vandaag is driver 1.20.0x.08 gereleased van de areca driver....

[Paul]

usr-local-dick schreef op donderdag 28 juli 2005 @ 23:14:
Als die tijd daar is dan kies je natuurlijk NIET voor XFS maar voor ext3. Maar dat terzijde.

Mag ik vragen waarom? Ik nu namelijk XFS, waar ik eerst ext3 had.

Ik had ook probs met een 2Tb partitie tijdens de installatie, en cfdisk *leek* de truuk te zijn. Uit verschillende berichten maak ik nu op dat dit ook niet goed werkt. Waarschijnlijk zat ik net voor een grens in de buurt van de 2Tb.

Bij mij nu leek het erop dat de grens niet in de partitioneer-software maar dieper zat, want zowel fdisk als sfdisk als cfdisk konden er niets mee.

Voor het debuggen van mijn custom Sarge installer zou ik graag een proefkonijn hebben die hem installeert op een volume van ruim 2 Gb en kijken wat er gebeurt....

Ik zit nu op Campzone, en als ik hier die installer van 100mb ga downloaden dan wordt ik door 1750 man gelynched... Na campzone (bij voorkeur _tijdens_ Campzone, liefste gisteren) heb ik de backup al teruggezet en heb ik hem weer in gebruik als fileserver. Ik ben bang dat ik dan ook niet meer echt van dienst kan zijn...

PS. Vandaag is driver 1.20.0x.08 gereleased van de areca driver....

De 28e om 15:29 geeft ls -l aan bij mij M.a.w die heb ik nu in gebruik.

[usr-local-dick]

Mag ik vragen waarom? Ik nu namelijk XFS, waar ik eerst ext3 had.

XFS journalt alleen meta-data, en ext3 meta-data plus data.
Dus tijdens een power failure ben je met XFS (ook met JFS etc etc) data kwijt, en met ext3 niet.
Als ik servers installeer doe ik deze test altijd (uit een draaiend systeem de stekker trekken )
en met XFS heb ik ca de helft van de keren heftige errors waardoor de partitie niet meer gemount kan worden en meer van dat soort gelul... dat wil je dus niet.
Qua performance is XFS wel beter maar als je dat (tegenwoordig, met buffel CPU's) moet afwegen tegen realworld scenario's zoals een powerfailure dan heb ik de keus snel gemaakt....
Bovendien... als je een nieuwe server ergens installeert dan is hij toch meestal een X aantal keren sneller dan de oude (of hij is nieuw dus er is geen vergelijking ), dus die performance doet absoluut niet ter zake. Denk ervan wat je wilt maar dit is mijn praktijk ervaring, die benchmarks etc zeggen mij niks ik wil gewoon stabiele shit waar hupsakee de power afgehaald kan worden. Zeker met terabyte filesystemen, heb het gelukkig nog niet hoeven meemaken dat die naar hun grootje gingen

XFS: Betere performance met groot risico op data verlies tijdens powerfailure
etx3: Iets mindere performance maar minimaal risico op data verlies tijdens power failure


prettige avond nog op de campzone

[ Voor 3% gewijzigd door usr-local-dick op 28-07-2005 23:45 ]

[burne]

usr-local-dick schreef op donderdag 28 juli 2005 @ 23:44:
XFS journalt alleen meta-data, en ext3 meta-data plus data.

Je moet de docs van je kernel nog maar eens goed nalezen. Standaard gebruikt ext3 een mode die 'ordered' heet. In die mode worden groepen van updates verzameld en naar schijf geschreven, en pas als dat gedaan is wordt het journal bijgewerkt. Dat houdt in dat je wel data verliest, maar dat niet terug zult vinden in de staat van je fs. Het is dus een aardige manier van maskeren dat er inherente problemen zijn met journalling van metadata. Als je naar de staat van je filesystem zou kijken zou je denken dat de powerfailure eerder plaatsgevonden heeft dan in werkelijkheid. Je mist gewoon de laatste paar honderd milliseconden.

XFS heeft een paar voordelen die voor hele grote filesystems wel degelijk heel belangrijk zijn. Allocation-groups, delayed allocation en pre-allocation maken mensen met grote bestanden of grote aantallen bestanden die kort leven erg blij.

[Verwijderd]

Paul Nieuwkamp schreef op donderdag 28 juli 2005 @ 23:06:
Euh, lees mijn verhaal nog eens, maar nu _goed_ ofzo...

En verander jij je houding eens lekker.
Goed een volledig uitgeschreven verhaal van hoe je het zou kunnen doen:
open fdisk (begint te mekkeren over cylinders e.d.)

fdisk /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

You must set cylinders.
You can do this from the extra functions menu.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

kies voor x --> g (create an IRIX (SGI) partition table) en schrijf de veranderingen weg, hierna kan je dus een XFS partitie schrijven die overeen komt met de grootte van de partitie. Zo hebben we het hier ook gedaan met een 3.25 TB raid 6 config op de areca controller. (2.6.11-mm kernel)

df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda xfs 3173696000 250337032 2923358968 8% /data

[Paul]

Verwijderd schreef op vrijdag 29 juli 2005 @ 12:44:
[...]

En verander jij je houding eens lekker.

Waarom zou ik mijn houding veranderen als men met "oplossingen" komt waaruit blijkt dat ze mijn hele verhaal niet eens gelezen hebben, laat staan begrepen. Alsze geen moeite doen voor mij (en ja, ik besef me dat ik degene ben die hier om hulp vraagt) dan ga ik geen ellenlange post schrijve om maar netjes uit te leggen dat je een schijf eerst van een partitie moet voorzien voordat je er zoiets als een filesystem op kunt zetten.
(Dat, en iedere windows zealot hier in de tent loopt aan mijn kop te zeiken adhv dit probleem dat ik er maar vooral Windows op moet zetten )

kies voor x --> g (create an IRIX (SGI) partition table) en schrijf de veranderingen weg, hierna kan je dus een XFS partitie schrijven die overeen komt met de grootte van de partitie. Zo hebben we het hier ook gedaan met een 3.25 TB raid 6 config op de areca controller. (2.6.11-mm kernel)

Hoe kom je erbij om een IRIX/SGI tabel te maken? Ik heb geen van beiden, dus dat vind ik niet echt een logische keuze. Hij zegt zelf dat er geen geldige tabel opstaat, en dat hij er een DOS-tabel aanmaakt. Waarom dan nog eens een andere eroverheen?

[ Voor 6% gewijzigd door Paul op 29-07-2005 14:30 ]

[Verwijderd]

Paul Nieuwkamp schreef op vrijdag 29 juli 2005 @ 14:29:
Hoe kom je erbij om een IRIX/SGI tabel te maken?

Misschien omdat ik XFS wil gebruiken?

Ik heb geen van beiden, dus dat vind ik niet echt een logische keuze. Hij zegt zelf dat er geen geldige tabel opstaat, en dat hij er een DOS-tabel aanmaakt. Waarom dan nog eens een andere eroverheen?

Ik geef je een voorbeeld van hoe wij het aan de praat hebben gekregen, het is aan jou omdat al dan niet ook te proberen. Nu ziet linux het bij ons als een groot blockdevice en dat is precise wat ik wilde.

[Paul]

Verwijderd schreef op vrijdag 29 juli 2005 @ 15:07:
Misschien omdat ik XFS wil gebruiken?

Hmm Hoe zit dat dan? Bij mijn weten is XFS gewoon een filesystem, en staan filesystems los van onderliggende mechanismes als de manier waarop een OS de partities op een schijf opslaat? Op een loop-device heb je ook geen partitietabellen afiak, en daar kun je ook een filesystem op zetten?

Ik geef je een voorbeeld van hoe wij het aan de praat hebben gekregen, het is aan jou omdat al dan niet ook te proberen. Nu ziet linux het bij ons als een groot blockdevice en dat is precise wat ik wilde.

Ah, op die manier tnx

[usr-local-dick]

Je moet de docs van je kernel nog maar eens goed nalezen. Standaard gebruikt ext3 een mode die 'ordered' heet. In die mode worden groepen van updates verzameld en naar schijf geschreven, en pas als dat gedaan is wordt het journal bijgewerkt. Dat houdt in dat je wel data verliest, maar dat niet terug zult vinden in de staat van je fs. Het is dus een aardige manier van maskeren dat er inherente problemen zijn met journalling van metadata. Als je naar de staat van je filesystem zou kijken zou je denken dat de powerfailure eerder plaatsgevonden heeft dan in werkelijkheid. Je mist gewoon de laatste paar honderd milliseconden.

XFS heeft een paar voordelen die voor hele grote filesystems wel degelijk heel belangrijk zijn. Allocation-groups, delayed allocation en pre-allocation maken mensen met grote bestanden of grote aantallen bestanden die kort leven erg blij.

Dat is inderdaad helemaal waar. Echter de servers die ik plaats komen niet in super professionele ruimten te hangen en het gebeurt gewoon dat de stroom eraf gaat (stekker er per ongeluk uit, of als het internet niet werkt wordt zo'n bak gewoon maar gereset ). Het hoort niet zo maar het gebeurt wel.
In enkele jaren tijd heb ik nog nooit een corrupt ext3 filesysteem gehad, en met XFS dus wel (beyond repair dus). De servers zijn grote fileservers waar veel data op staat maar die niet 24 uur per dag door tig users gebruikt worden.
De users begrijpen overigens heel goed dat als er tijdens een schrijf actie gereset wordt dat dan de files waarschijnlijk stuk zijn.
Overigens heb ik redelijk wat vage kernel panics met XFS in combinatie met SMP kernels, wat me ook niet veel vertrouwen geeft. ext3 is al zo oud dat dat uit-ontwikkeld is. Maar goed dat is weer een ander verhaal....

[ Voor 12% gewijzigd door usr-local-dick op 29-07-2005 19:00 ]

[Olaf van der Spek]

Paul Nieuwkamp schreef op vrijdag 29 juli 2005 @ 14:29:
Hoe kom je erbij om een IRIX/SGI tabel te maken? Ik heb geen van beiden, dus dat vind ik niet echt een logische keuze. Hij zegt zelf dat er geen geldige tabel opstaat, en dat hij er een DOS-tabel aanmaakt. Waarom dan nog eens een andere eroverheen?

Heeft een DOS tabel geen limiet van 2 tbyte voor begin en eind (of grootte)?

[Verwijderd]

OlafvdSpek schreef op vrijdag 29 juli 2005 @ 19:34:
Heeft een DOS tabel geen limiet van 2 tbyte voor begin en eind (of grootte)?

correctemundo

[TD-er]

OlafvdSpek schreef op vrijdag 29 juli 2005 @ 19:34:
[...]

Heeft een DOS tabel geen limiet van 2 tbyte voor begin en eind (of grootte)?

Is dat niet gewoon weer een 32-bits unsigned integer voor het aantal cylinders? (2^32 * 512 Bytes = 2 TB)

[Olaf van der Spek]

TD-er schreef op zaterdag 30 juli 2005 @ 13:02:
Is dat niet gewoon weer een 32-bits unsigned integer voor het aantal cylinders? (2^32 * 512 Bytes = 2 TB)

Ja, nee. Het is voor het aantal sectors.

[TD-er]

OlafvdSpek schreef op zaterdag 30 juli 2005 @ 13:03:
[...]

Ja, nee. Het is voor het aantal sectors.

* TD-er bladert terug naar de OP...

SCSI device sdc: 4687499264 512-byte hdwr sectors (2400000 MB)

* TD-er gaat ff koffie zetten... sectors, cylinders... hmmm koffie.

[Verwijderd]

Er zijn problemen met "partities" groter dan 2TB en als je toch meer wilt dan moet je gewoon het device direct aanspreken. Als je dan volumes wilt maken dan kan je dat doen met LVM. Een andere oplossing kan zijn om kleinere partities te maken en die weer met LVM aan elkaar te plakken en levert geen performance hit op hoor als je daar bang voor bent. Dit laatste is btw wel een gebruikte methode bij de wat grotere omgeving en geeft je ook een stukje flexibiliteit trouwens. Bij oa een voorgaande opdracht hadden we 300+TB opgebroken in volumes 50/100/250GB die naderhand op de machine met LVM weer aan elkaar werden geplakt en verdeelt onder filesystems om het maar even simpel te zeggen

Voor jouw info btw, Veritas levert meer dan alleen een backupoplossing namelijk ook oa een commerciele LVM en VxFS (Veritas FileSystem). Mag ik je trouwens aanraden om bij Linux op dit moment ext3 te (blijven) gebruiken aangezien andere helaas nog niet volwassen genoeg zijn qua implementatie op Linux.