Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 120 reacties
Bron: The Register

The Register meldt dat Linux sinds kort ondersteuning biedt voor filesystems van meer dan 100 Petabyte, om precies te zijn 128 Petabyte (144,115,188,075,855,872 bytes). De driver die dit mogelijk maakt zit in de 2.4.13-ac6 kernel, maar is ook los te downloaden. De code maakt gebruik van een nieuwe toevoeging van de ATA specificatie, die onderdeel is aan de ATA-133 standaard. Hiermee is het mogelijk om 48-bit adressen te gebruiken. In eerste instantie dachten de mensen van de The Register dat Linux het eerste desktop besturingssysteem was die dergelijke grote filesystemen aankon, maar moest dit later herzien. FreeBSD heeft namelijk al een tijdje dezelfde mogelijkheden in de FreeBSD 4-STABLE branch:

Tux (linux logo) Oops. Not only can Linux not claim to be the first desktop OS to support multi-PB file sizes, it isn't even the first Unix.

"Soren Schmidt of the FreeBSD Project has added 48-bit addressing support to the FreeBSD 4-STABLE branch," writes Bruce Simpson. "You can find the news here, and the code here (Check revision 1.114 and you will find the code).

"The date on which Soren added the 48-bit support to 5.0-CURRENT is October 6th, however, the Linux patches are dated this Monday. You can therefore clearly see that FreeBSD has had working 48 bit ATA addressing support since the beginning of October, which is as of now being grandfathered in to the 4-STABLE tree after undergoing extensive testing"

Met dank aan Hawks voor het submitten.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (120)

Waar heeft iedereen het hier over zeg? Natuurlijk is dit voor de thuisgebruiker nutteloos. Leuk dat dit kan, maar het is alleen nuttig om te kunnen zeggen dat ze volledige support voor ATA133 hebben... En misschien dat de grotere datacenters en internet zoekmachines hier wat aan hebben....

Ik ben een keer met een excursie van school naar het KPN datacenter in Groningen geweest, en daar doen ze heel luchtig over tape-cabinets van honderden terabytes, en van servers met schijfruimtes van 50 TB. Wij stonden te kwijlen bij het zien van de server-ruimte, maar daar zijn ze het gewoon nodig, om alle telefoongesprekken, post, internetverkeer, rekeningen enzovoorts te kunnen loggen......

En reken maar dat de kernel-developers zich op bovenstaande markt richten, en absoluut niet op de desktopmarkt. Wat de KDE en Gnome mensen doen zal hun een worst wezen. Okee, een OpenGL-drivertje in de kernel kan dan nog wel, maar Linux (de kernel) is altijd al zware overkill geweest voor de desktop....
En reken maar dat de kernel-developers zich op bovenstaande markt richten, en absoluut niet op de desktopmarkt.
Grapje zeker.. het gaat hier over IDE hoor, en dat wordt dus *niet* in zulke datacenters gebruikt. :P
Dit opent op zich mogelijkheden voor het bouwen van gigantische databases, de vraag is alleen: kunnen de huidige database-software pakketen zoals MySQL, Progress, Oracle wel met zulke gigantische file(s) werken??

Het lijkt me dat daar ook nog een grensje doorbroken moet worden.
Wil je een paar Pettabyte vol krijgen met een MySQL database, ben je toch HEEL lang bezig,
een Mysql database beslaat namelijk maar HEEL weinig ruimte.

Maar tis mooi dat het kan he :)
Kan je eindelijk internet downloaden :)
[zwetsmode]
als je een film renderd doe je dat vaak in losse tga's
stel dat die 1600x800 zijn (om later te downscalen)
met alfa en gemiddeld 3 layers per frame, zit je voor 2 uur film zo aan de 5000Gb, en die ruimte heb je nog wel een keer nodig om te swappen als je gaat compileren. 10Tb is dus best te gebruiken voor je renderbakkie. oke,toegegeven, als hobby maak je vast geen 100 speelfilms te gelijk, maar het is fijn te weten dat t kan :)
[/zwetsmode]

correctie: ik dacht dat 1Pb=1024 Tb, maar is blijkbaar 1024^2 Tb
een gigantische wereldwijde en zo goed als allesomvattende database
En nu maar zeuren over M$ die al te veel gegevens hebben. :)

edit:

denk ook niet dat je snel een database kunt maken die allesomvattend is. Dan worden het al snel een aantal verschillende databases.
* 786562 Jochem

dan ben je ongeveer 30.000.000 Jaar bezig met downloaden op mijn chello account.
Heel vaak is voor DBMS'en de grens van het filesysteem de beperkende factor. Toegang tot de bestanden wordt niet door DBMS geregeld maar door het OS. Er zou misschien wel een patch uit moeten komen omdat de 100 PB grens wel wat erg ver ligt...
Tegenwoordig hebben DBMS'en vooral last van de grens van het RAM geheugen: in 32-bit mode is dat 4 GB... Voor een desktop PC is dit momenteel nog te veel, maar voor DB-servers is dit echt wel krap. Dat is ook de reden waarom 64-bit CPU's steeds interessanter worden trouwens.

De plaats op HD's is voor grote DB's tegenwoordig minder belangrijk. De grootste DBMS'en ondersteunen drive-arrays zonder problemen.
Met 64-bits hardware is het mogelijk de complete database in het geheugen te houden. Wel geswapt natuurlijk.
De swap komt dan exact overeen met de disk-opslag.

Bij het opstarten wordt de complete database uitgeswapt in het ram geladen (in de praktijk hoeft er voor iedere pagina precies 1 verwijzing in het MMU gezet te worden).
Bij het page-mis geeft de MMU een interrupt en haalt het OS de juiste pagina van de "swap". Geen overhead, dus razendsnel.

Voor de Alpha is er in de begintijd zo'n DBMS gemaakt. Was (op onderdelen) tot 100x zo snel als de standaard implementatie.

Waarom het nooit echt wat geworden is weet ik niet. Waarschijnlijk is de markt toch te klein om zulke hele specifieke implementaties voor de vrije markt te maken.
Er zijn 32 bitters die tot 64GB kunnen adresseren (bijv. de P2/PIII).

En *echte* databases (bijvoorbeeld Oracle) maken helemaal geen gebruik van je FS. Die slaan alles direct op de HD op, zodat ze zelf kunnen optimaliseren voor de snelste performance en een virtualisatie laag overslaan.
"Waarom het nooit echt wat geworden is weet ik niet"

Ehm, in de begintijd was het geheugen heeeeeeeel erg duur. Da's nu niet meer zo :-).

Daarbij is de hele database in het geheugen houden niet bevorderlijk voor de stabiliteit van je database. En power-dip, je server loopt vast en hoe wou je dan nog de data uit het geheugen halen?

Caching van de hele database is onzin, het is nooit zo dat _alle_ records in de database tegelijkertijd worden aangesproken. In de praktijk worden een paar records vaak aangesproken, dus of je nou 10% van de database cached of 100% zal niet veel uitmaken in snelheid tijdens het gebruik.

Het is belangrijker om goede en snelle caching-methodes te hebben. Veel DBMSsen cachen de data in het geheugen op dezelfde manier als dat het op disk staat. Dat is natuurlijk onzin, als je toch iets in het geheugen cached, sla het dan ook zo op dat je er meer voordeel uit haalt. Op disk staat het in losse records, in het geheugen met onderlinge verwijzingen/tabellen. Kost je veel meer opslagruimte, maar het komt de snelheid zeker ten goede.

Overigens zijn dit soort dingen altijd een trade-off tussen prijs, prestatie en veiligheid. Als je het n bevoordeelt, benadeel je het andere.
En dan maar zien dat er in zo'n Pentastische files (want gigantisch past niet meer IMHO ;)) geen bad sector zit... Wordt wel leuk:

Mom! There is a bad sector on the Internet file on my computer!! I'll need to download it again!

Misschien is het wel de bedoeling een soort van distributed network op te bouwen voor HD-space. Op die manier zou je dus een programma op je thuis-HD kunnen draaien die je een bepaalde quota geef op je HD. In Linux zou je dan een extra drive hebben die gemaakt is van de 1000'en distributed HD-space clients. Aangezien je dan een enorme adresseerbare ruimte hebt, zou je zoiets misschien wel kunnen doen.

edit:
aanvulling
Misschien is het wel de bedoeling een soort van distributed network op te bouwen voor HD-space. Op die manier zou je dus een programma op je thuis-HD kunnen draaien die je een bepaalde quota geef op je HD. In Linux zou je dan een extra drive hebben die gemaakt is van de 1000'en distributed HD-space clients. Aangezien je dan een enorme adresseerbare ruimte hebt, zou je zoiets misschien wel kunnen doen.

En wat is het internet dan? In feite ook een groot filesystem waar iedereen dingen van af kan halen en op kan zetten. Die quota zijn dan de quota die je aan je webserver oplegt en het addresseren doe je met IP's en directory-namen. Het enige wat nog niet gebeurt bij mijn weten is het verdelen van een groot bestand over meerdere computers over de hele wereld, al kan dat technisch natuurlijk wel. En naast het www zoals de meesten het gebruiken bestaat er ook al een tijdje een alternatief: freenet. Daar ga je niet naar een bepaalde host toe, maar een bepaalde key. Die key kan overal ter wereld opgeslagen zijn (zelfs zonder dat je het weet op je eigen computer). De computers van gebruikers slaan steeds veelgevraagde keys op, terwijl ze minder belangrijke informatie weggooien. Alle belangrijke informatie blijft dus automatisch staan, de minder interessante verdwijnt vanzelf. Een mooi idee, vind ik.
Format HD0 :

Volgend jaar is die wel klaar dan ? Mischien ?

Windows systemen dan maar helemaal buiten beschouwing gelaten.

Ga maar eens 160 GB defraggen! :( laat staan 1 Petabyte ! :)
Voordat je aan het einde bent heb je de volgende 3 defraggers al weer runnen :)

FF foutcontrole, en dan wel uitgebreid he :)

Denk dat als iemand zo'n opslagruimte heeft, het ook wel de snelste schijven zullen zijn, en hij ook wel een aantal leuke proc erbij heeft staan.

Zo'n opslagruimte krijgen we (voorlopig :) ) NOOIT op 1 schijf, dus je kunt het defraggen en de foutcontrole per schijf uitvoeren.

En als er 1 gruwelijk grote database (lees ff 1 bestand) op staat hoeft er niets gedefragd te worden.
En als er 1 gruwelijk grote database (lees ff 1 bestand) op staat hoeft er niets gedefragd te worden.
Nou, je zou maar de index opnieuw op moeten bouwen op zo'n grote database :)
Neem dan gewoon een indeling die niet of weinig fragmenteert!
euhh heb laatst 100 gig gedrefragmenteert
valt wel mee

staat voor 70% vol met films }>
maar gaat lekker snel in 4 uur
Nou alleen zo'n grote schijfjes zien te maken :)

Tis wel weer een mooie doorbraak van linux, maar denk dat er voorlopig nog niet zo veel gebruik van gemaakt zal worden.
which is as of now being grandfathered in to the 4-STABLE tree after undergoing extensive testing"
Dit is dus ironisch bedoeld. Waarschijnlijk bestaat er helemaal nergens op deze planeet een storage system welke meer dan 100 PetaByte is. Van testen kan dus helemaal geen sprake zijn....
Ligt er aan. je kunt met virtuele devices een hoop emuleren hoor....
Een 48bits adressering kan je al testen met een 32bits+1 adres natuurlijk... Testen is dus WEL mogelijk...
Waarschijnlijk wordt bedoeld, dat de nieuwe driver die de grotere file systems mogelijk maakt wordt getest. Als deze stabiel werkt met huidige storage devices, zal deze ook werken met de toekomstige storage devices.
<nostalgia alert>
Mmz, toen ik hoorde dat er een 5Mb harddisk op de markt kwam dacht ik ook - dat is alleen voor bedrijven. Nooit gedacht dat ik een klein Palmpje zou hebben met 72Mb RAM :7
</nostalgia alert>
Disk array van 100,000 Maxtor 160GB disks kom je wel een eind mee :9
van 100,000 Maxtor 160GB
daar heb je flink wat SCSI controllers voor nodig :+
daar heb je flink wat SCSI controllers voor nodig :+
Dit gaat over IDE...
Inderdaad - ik heb dit (oude) beestje staan http://www.compaq.com/alphaserver/archive/8400/as800 0_pb.html en kan daar dus 132 PCI bordjes in stoppen.
Dat is nog steeds 2.5TB respectievelijk 4.5TB.

Maar 128 PetaByte (PB) is nog steeds 128 x 1024 = 131072 GigaByte (GB). :Y)

En het is trouwens Promise.
Niet helemaal: 128 PetaByte (PB) = 128 x 1024 TeraByte (TB) = 128 x 1024 x 1024 GigaByte.
Je vergat een factortje 1024 :)

Dus:
Mega, Giga, Tera, Peta...
had ik maar zoveel Peta's :)
<droom, zucht, koude douche :o>
Ik ben nieuwsgierig welke instanties/bedrijven hier gebruik van kunnen maken...
<edit ->typo's>
Wat ben je daar NU mee als thuisgebruiker? Maak eens zo'n pak folders aan zodat je een alles mooi kan sorteren... op zo'n schijf vind je immers helemaal niks terug!

Met aparte partities werken wordt ook al zottenwerk... Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters. Zo'n 128 Petabytes verspreiden over 26 drive-letters is dan ook niet echt praktisch: je blijft dan nog steeds over met een kleine 5 petabyte per partitie. Zo'n systemen zouden *op dit moment* enkel handig voor netwerk server systemen. Maar dan nog enkel indien de netwerken zelf een PAK sneller zouden werken.

't is leuk dat dat nu al ondersteund wordt, maar ik vrees dat dat momenteel erg weinig nut heeft. En waarom hebben ze daarvoor moeten wachten op een nieuwe spec in ATA133? De grootste schijven gebruik je toch voor servers en dan gebruik je op zijn minst SCSI dacht ik zo?! Of zie ik iets over het hoofd?

edit:
aanvulling
Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters.
We hebben het hier dan ook over Linux en BSD systemen. Natuurlijk blijft de hoeveelheid nauwelijks te beheersen door 1 persoon, maar als je dus een mega-server in je bedrijf wilt plaatsen met daarop viruele disks (iedere gebruiker z'n eigen stukkie dat er hetzelfde uitziet, maar fysiek op een andere plek is opgeslagen) dan wordt het wel ineens heel interessant. Of wat dacht ge van het webarchief waarin heel veel oude websites zijn opgeslagen (zie het stukje van een aantal dagen geleden). Allee, dat kost toch echt wel een bak aan schuifruimte. Zeker en vast!
Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters
Aangezien dit een *nix smaak betreft hoe je je hier geen zorgen om te maken .. hier gebruik je geen driveletters maar kun je gewoon de zoveel partities mounten als je wil ( je bent in ieder geval niet beperkt tot de lettertjes van het alfabet )
bij NT kon ja altijd al filesystemen aanmaken zonder driveletter. Hoe dat er dan uit gaan zien weet ik niet maar het kan wel!
Dat kon in dos ook al lang

subst T: C:\divx

werkt ook in win98/Me/2k/XP

not a problem
Het lijkt mij niet dat driveletters veeluitmaken.
Of je je data nu sorteert in partities of in directories op 1 partitie maakt eigenlijk toch niks uit.
Die directories zou je dan kunnen mappen als echte Network Drives, en die hebben, zoals directories geen beperkingen qua naamgeving.
Het enige nut van meerdere partities zou dan data-veiligheid zijn, omdat er dan verschillende apparte FAT tables (algemeen dus, niet specifiek verwijzend naar FAT16 of FAT32, maar ook naar andere) zijn, zodat 1 partitie nog kan werken als een andere fouten vertoont.
Of de verschillende FAT tables echt op verschillende delen van de drive zitten, of toch allemaal in het begin ofzo, weet ik echter niet, en zal ook wel afhangen van het gebruikte systeem.
Je gebruikt dan een soort mount commando, zoals in Linux (zie de help). (8>
Yep in je Volume manager van windows
kan je zowaar disken mounten aan een dir :P

Word steeds mooier met ze , ohja is veritas hehe :)

Anyway's in de adressering van ide drives hebben we geen problemen meer voorlopig :*)
Of je je data nu sorteert in partities of in directories op 1 partitie maakt eigenlijk toch niks uit.
Ik hoor je nog wel een keer als je format moet doen
Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters. Zo'n 128 Petabytes verspreiden over 26 drive-letters is dan ook niet echt praktisch: je blijft dan nog steeds over met een kleine 5 petabyte per partitie
Uhm..Linux en FreeBSD doen niet aan drive-letters hoor.
En dit nieuwtje gaat over Linux/FeeeBSD, daar heeft Windows niks mee te maken. Bovendien haalt het FAT32 filesystem die 128 petabyte ook niet. (NTFS volgens mij ook niet)
Bij mijn weten ben je in
Win-systemen nog steeds beperkt tot 26 drive-letters.
Ik dacht dat ie dan gewoon verder gaat met drive AA, AB, AC, etc. t/m ZZ, maar ik kan het mis hebben.
"... Bij mijn weten ben je in Win-systemen nog steeds beperkt tot 26 drive-letters."

dit is fout, in windows 2000 kan je je schijven makkelijk mounten op een andere letter
bijvoorbeeld:
drive 1 == C:\
drive 2 == C:\Program files
drive 3 == C:\DriveXYZ

misschien zit er een limiet op, dat weet ik niet, maar de 26 letters is zeker geen limiet...
Is wel leuk hoor.
Dan kan je elke film die ooit is gemaakt op je PC opslaan :9

Da's pas een video-jukebox
Tja ik vind het jammer dat als ik een Filmpje ga capturen met mijn capture kaart dat i max 3,99Gb kan opslaan aangezien met mijn software alles in avi moet opslaan en pas later kan omzetten in Mpg2 bv kan ik max een filmpje maken van 2 a 4 min met een resolutie van 800x600x32bitsx25FPS dus...

ik draai nu nog win982de ik weet niet of het is opgelost in Win2k?
In ieder geval is de limiet veel groter bij Win2k/WinXP indien je NTFS als filesysteem gebruikt (ik dacht dat dan de maximale bestandsgrootte zo rond de 1600GB lag). Dat lijkt me voorlopig wel voldoende :)
Denk nog maar een keer dan. De installatie van verschillende distributios mag dan niet zo vriendelijk zijn (alhoewel elke tweakers makkelijk SuSE of Mandrake installeerd) als je kde 2.2.1 hebt draaien is ie echt WEL gebruiksvriendelijk...
T'ja jongens, het gaat hier dan ook om een " enabling technologie" de doorbraak in zichzelf is niet zo veelzeggend als wat men ermee gaat kunnen. Denk nu eens na hoeveel instanties geld kunnen sparen en tegelijkertijd imposante bestandsystemen kunnen implementeren voor dingen waar ze vroeger alleen maar konden kibbelen in budget overleggen. Ik denk met name aan de academische en wetecnschappelijk gemeenschap die hierbij mega baat kan aan hebben door telkens een beetje meer enabling technologie te implementeren en, al lerende -muddling through- , nieuwe operationele processen ontwikkelen in hun core activiteiten. Grote rganisaties zijn als het ware een oersoep van ideen en voorstellen waaruit blijkt dat het voortgangsprocess een beetje chaotisch verloopt en aldus voortchaossend (bestaat dit woord??) "enabling" randvoorwaarden opslorpt in de oersoep der vooruitgang.

(voor de geinteresseerden zoek effe op, "the science of muddling through van Lindblom)

To geek where no geek has geeked before.... 8-)
Heb je wel ruimte voor een vette swapfile :P
... en zit je RAM vol met de virtuele adres-mapping voor deze pentastische swapfile.

Ik vind zo'n filesysteem enkel zinvol om onderzoekers op een volledig nieuw systeem te laten zoeken om de ruimte in te delen. Je zou er bv. aan kunnen denken om een volledige cluster dezelfde HD adres-space te laten gebruiken (geshared dus). Als je dan zo'n 1024 nodes hebt, dan komt dat neer op zo'n 1024 TB per node. Momenteel is dat nog enorm veel, maar de TerraByte is de volgende stap na de GigaByte.
... en zit je RAM vol met de virtuele adres-mapping voor deze pentastische swapfile.
Daar heb je toch die lekkere grote swapfile voor? :)
SGI heeft een File system dat heet XFS dat kan 9 exebytes :? aan is dat meer dan 128 Petabyte :? ?
meer info http://www.sgi.com/software/xfs/
Nou, he he, kan ik EIN-DE-LIJK m'n nieuwe schijf een keer gaan gebruiken! :P
Eindelijk! Vroeg me al af wat ik toch met dat bestandje op m'n C-schijf moest. Nu weet ik het: gewoon Linux installeren... hadden ze dan niet even eerder kunnen vertellen ;)
Wat heb je nou weer aan zoveel?

Sorry hoor, maar dit is voorlopig nog waardeloos :Z
The Register meldt dat Linux sinds kort ondersteuning biedt voor filesystems van meer dan 100 Petabyte
Nee, daar gaat het niet om. Het is niet het bestandssysteem dat nu grotere partities ondersteunt, het is de IDE driver die grotere harde schijven ondersteunt. Bestandssystemen kunnen al lang veel groter zijn.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True