Oracle: btrfs-bestandssysteem is rijp voor productiesystemen
Oracle heeft in 'release 2' van de Unbreakable Enterprise Kernel het btrfs-bestandssysteem geschikt bevonden om op productiesystemen ingezet te worden. Daarmee is Oracle na SUSE de tweede leverancier die btrfs-ondersteuning biedt.
Hoewel btrfs, een bestandssysteem dat een aantal tekortkomingen van de huidige file systems moet verhelpen, binnen de huidige Linux-kernel nog het stempel 'experimenteel' draagt, gaat Oracle ondersteuning bieden voor het next generation file system. Btrfs, dat tot 16 exabyte aan opslag kan adresseren, is dan ook opgenomen in de laatste release 2-uitvoering van de Unbreakable Enterprise Kernel, een kerneluitvoering die bedoeld is voor Oracle Linux 5.8 en 6.2. Met de ondersteuning voor btrfs volgt Oracle het voorbeeld van SUSE dat vorige maand in het tweede servicepack voor SUSE Linux Enterprise het nieuwe bestandssysteem integreerde.
Een aantal populaire Linux-distributies, zoals Ubuntu, OpenSUSE en Fedora, bieden btrfs weliswaar aan als een installatie-optie, maar het bestandssysteem wordt nog niet gebruikt als standaard file-system. Belangrijkste reden is het ontbreken van een betrouwbare controle- en reparatietool voor btrfs-partities; ontwikkelaars van de huidige btrfsfsck-tool raden af om deze te gebruiken omdat er nog de nodige bugs in de code aanwezig zijn. Oracle en SUSE bieden beide echter aangepaste versies van btrfsck aan, maar deze zijn nog niet vrij beschikbaar.
De nieuwe release van Oracle's Unbreakable Enterprise Kernel is gebaseerd op Linux 3.0.16 en is een afgeleide van de kernel die te vinden is in Red Hat Enterprise Linux. Om compatibiliteit met enkele low-level onderdelen te garanderen, is de UEK-kernel echter noodgedwongen voorzien van versienummer 2.6.39.
Oracle-gebruikers zouden met de release 2-editie kunnen profiteren van verbeterd geheugenbeheer dankzij transparent hugepages, meer mogelijkheden voor de Xen-hypervisor en een groter driveraanbod. Ook zijn enkele niet-ondersteunde 'technology previews' in de kernel opgenomen: de ontwikkeltool DTrace, drbd-replicatiemogelijkheden voor clusteromgevingen en lxc, een technologie voor container-based virtualisatie.
Reacties (57)
Het verbaast me dat ze btrfsck nog niet vrijgeven. Heb op Ubuntu nog wel wat rare crashes gezien bij een hoge belasting, maar ben benieuwd naar de nieuwste versies!
Tja wat voor voordelen heeft het dan en is dit voor de gewone gebruiker interessant om ext4 te vervangen door btrfs? Ik gebruik nu alleen ext4 voor m'n servers en nooit geen problemen dus moet er wel een goede reden zijn om over te stappen.
Is het trouwens de bedoeling dat dit de opvolger van ext4 gaat worden? Want voorheen had je ook ReiserFS bijv. en nog wat andere varianten maar waarom zouden die dan meteen standaard worden in bijv. Ubuntu?
Is het trouwens de bedoeling dat dit de opvolger van ext4 gaat worden? Want voorheen had je ook ReiserFS bijv. en nog wat andere varianten maar waarom zouden die dan meteen standaard worden in bijv. Ubuntu?
Ik denk zelf dat ext4 eerst nog een tijdje word gebruikt aangezien het zoals je ook zegt gewoon goed werkt, mischien dat op het moment dat dit verouderd is er al wel weer wat nieuws is.
BTRFS. Voordelen:
Ubuntu apt-snapshot: Je maakt een btrfs snapshot en je kan het hele systeem teruggooien naar die status. Is dit het zelfde als een backup dan? Ja en nee want een snapshot kun je achteraf nog bijwerken. Daarnaast kun je hier gewoon een schijf bijpluggen en het bestandsysteem wordt groter zonder wat te hoeven doen!
Het is sneller met grote bestanden. Zelfs de maker van ext4 vindt btrfs beter
Maar zover is het nog niet! Fedora kan met yum volgens mij ook al btrfs yum-snapshots maken
Ubuntu apt-snapshot: Je maakt een btrfs snapshot en je kan het hele systeem teruggooien naar die status. Is dit het zelfde als een backup dan? Ja en nee want een snapshot kun je achteraf nog bijwerken. Daarnaast kun je hier gewoon een schijf bijpluggen en het bestandsysteem wordt groter zonder wat te hoeven doen!
Het is sneller met grote bestanden. Zelfs de maker van ext4 vindt btrfs beter
Maar zover is het nog niet! Fedora kan met yum volgens mij ook al btrfs yum-snapshots maken
had de maker van ext4 ext4 ook niet gemaakt als lapmiddel tot btrfs klaar was?Zelfs de maker van ext4 vindt btrfs beter
Die snapshotmethode gebruiken we bij Archlinux voor onze buildserver.
Vroeger hadden we voor elke gebruiker een buildroot die we bij elke build met rsync synchroniseerden met een schone root. Tegenwoordig maken we gewoon een container met btrfs en bouwen we daarin. Behalve dat het ruimte scheelt, scheelt het ook enorm in I/O bewerkingen van de harddisk, en nog belangrijker: we raken niet meer door onze inodes heen.
Vroeger hadden we voor elke gebruiker een buildroot die we bij elke build met rsync synchroniseerden met een schone root. Tegenwoordig maken we gewoon een container met btrfs en bouwen we daarin. Behalve dat het ruimte scheelt, scheelt het ook enorm in I/O bewerkingen van de harddisk, en nog belangrijker: we raken niet meer door onze inodes heen.
De maker mag dat wel vinden, maar de performance spreekt het tegen.
EXT4 vs. BTRFS
EXT4 vs. BTRFS
Het verschil zou hem zitten in de ondersteuning van concurrent writes.
Iets wat van belang is voor db servers.
Volgende blog past handeld daarover (wel niet over btrfs en ext4, maar over xfs en ext4): http://kevinclosson.wordp...-look-at-xfs-versus-ext4/
Iets wat van belang is voor db servers.
Volgende blog past handeld daarover (wel niet over btrfs en ext4, maar over xfs en ext4): http://kevinclosson.wordp...-look-at-xfs-versus-ext4/
LVM ondersteund ook snapshots.
LVM ondersteund ook "gewoon een schijf" bijpluggen en lv's vergroten.
LVM ondersteunt snapshots op blockniveau, wat zijn beperkingen heeft, zowel qua werking als qua efficiency. Zo weet de filesystem cache niet dat bestanden op de snapshot volume over het algemeen hetzelfde zijn als de bestanden op het volume waar de snapshot van genomen is.
Verder moet je bij LVM een snapshot-grootte opgeven, waar alleen LVM weet van heeft. Schrijf je meer op een van beide volumes dan wat je hebt opgegeven als snapshot size, dan is je snapshot meteen stuk en kan je er niks meer mee. Dit alles zonder enige vorm van waarschuwing.
Verder moet je bij LVM een snapshot-grootte opgeven, waar alleen LVM weet van heeft. Schrijf je meer op een van beide volumes dan wat je hebt opgegeven als snapshot size, dan is je snapshot meteen stuk en kan je er niks meer mee. Dit alles zonder enige vorm van waarschuwing.
BTRFS is veel meer als ZFS, je kunt er ook (o.a.) pools mee maken van meerdere schijven. Het volgende is bijvoorbeeld mogelijk:
3 schijven als 1 volume zien met net als RAID de mogelijkheid om 1 schijf te verwijderen zonder problemen als deze bijvoorbeeld beschadigd is. Met wat simpele commandos heelt het filesystem zichzelf vervolgens als er een nieuwe schijf inzit en is alles weer veilig.
Ik hoop dat het beter op low-end systemen werkt dan ZFS zodat ik het op mijn Atom servertje (nu met Arch Linux erop) kan gaan gebruiken. ZFS (toen op FreeBSD) draaide veel te traag.
3 schijven als 1 volume zien met net als RAID de mogelijkheid om 1 schijf te verwijderen zonder problemen als deze bijvoorbeeld beschadigd is. Met wat simpele commandos heelt het filesystem zichzelf vervolgens als er een nieuwe schijf inzit en is alles weer veilig.
Ik hoop dat het beter op low-end systemen werkt dan ZFS zodat ik het op mijn Atom servertje (nu met Arch Linux erop) kan gaan gebruiken. ZFS (toen op FreeBSD) draaide veel te traag.
[Reactie gewijzigd door teek2 op 15 maart 2012 08:41]
volgens mij is ZFS juist meer als BTRFS
http://www.codestrom.com/...-vs-btrfs-comparison.html
dat ZFS niet zo aardig is voor je geheugen vooral met dedup en dergelijke klopt dan weer wel
maar die functie zit niet eens in btrfs dus appels met peren lijkt me.
http://www.codestrom.com/...-vs-btrfs-comparison.html
dat ZFS niet zo aardig is voor je geheugen vooral met dedup en dergelijke klopt dan weer wel
maar die functie zit niet eens in btrfs dus appels met peren lijkt me.
[Reactie gewijzigd door Proxx op 15 maart 2012 08:52]
Altijd mooi een stukje technologie, ik ben benieuwd hoelang het duurt voordat windows met iets nieuws komt. Hoeveel geheugen kan NTFS adresseren?
Edit: wat gevonden op wikipedia 256 TB, zou dit kunnen?
Wat mij betrefs mogen die 255 tekens ook wel wat langen kunnen
Edit: wat gevonden op wikipedia 256 TB, zou dit kunnen?
Wat mij betrefs mogen die 255 tekens ook wel wat langen kunnen
[Reactie gewijzigd door Sharpen op 14 maart 2012 20:09]
NTFS kan helemaal geen geheugen adresseren. Het is een filesysteem geen memory manager.
Ik ben nou niet de gene die dit helemaal snapt maar ik dacht dat het ging om en oplaan op hdd's en ssd's, zegmaar NTFS FAT enz. ik ga het nog even bekijken want ik denk dat ik het een en ander gemist heb
Ja, het gaat inderdaad over hard drives. Dat is opslag, geheugen word meestal gebruikt voor RAM.
Ik hoop niet dat Microsoft met iets nieuws komt, duurt het weer jaren voordat je fatsoenlijk 2 OS'en naast elkaar kan laten lopen omdat het file system proprietary is.
Ik hoop niet dat Microsoft met iets nieuws komt, duurt het weer jaren voordat je fatsoenlijk 2 OS'en naast elkaar kan laten lopen omdat het file system proprietary is.
Microsoft heeft al iets in de pijplijn: ReFS. Een artikel op Phoronix behandelt de verschillen met Btrfs: http://www.phoronix.com/s...=news_item&px=MTA0NDA
Ik weet niet ... zou MS dat nu nog kunnen doen? Een gesloten filesysteem zomaar massaal in gebruik nemen? Ik denk dat ze daar nu dan hoop gezeik mee krijgen. Vijf jaar geleden niet, maar nu ... de wereld is nu wel iets anders, Linux word langzaam aan steeds meer "normaal" gevonden.... duurt het weer jaren voordat je fatsoenlijk 2 OS'en naast elkaar kan laten lopen omdat het file system proprietary is.
MS krijgt het voor elkaar rechtzaken te beginnen over fat 32 licenties, dus ik denk echt niet dat een volgend MS filesysteem zomaar vrijgegeven gaat worden.
Niet langzaam hoor.Linux word langzaam aan steeds meer "normaal" gevonden.
In de laatste 12 jaar heeft Linux en *BSD zowel als server als in verschillende appliances, zoals routers, ssl accelerator, firewalls etc.. (zover klant het niet weet) vele AIX, HP-UX, Windows servers doen vervangen bij banken, verzekeraars en overheden.
De meeste servers aan het Internet draaien Linux/*BSD het is eerder de standaard dan uitzondering.
Het is juist niet "normaal" om achterhaalde OS direct aan het Internet te hangen zonder daarvoor een reverse proxy en/of een firewall die Linux/*BSD gebruikt.
Om maar over performance, continuïteiy, support (welke support?) en licentie kosten maar te zwijgen. MCSE betekend niet voor niets "Must Consult Someone Experienced" je ziet vaak bij grotere bedrijven dat de *NIX beheerders de problemen van Wintendo beheerders oplossen zeker als het netwerk aangaat.
Oracle weet dit daarom hebben ze marktleider in dit segment RedHat ES gekloond.
Wat overigens uitgekookt is, immers de huidige RedHat ES licentie nemers zijn gecharmeerd om en hun MySQL/ORACLE DB licenties + support en OS bij zelfde leverancier af te nemen.
Terwijl RedHat een bewezen trackrecord heeft en erg veel terug doet voor GNU/Linux gemeenschap.
Oracle heeft een monopolie en tot op heden niet bewezen het beste met de wereld voor te hebben.
Los van bovenstaande GNU/Linux tweemaal de boot gemist door geen misbruik te maken van GUI veranderingen van Wintendo desktop OS en te zorgen dat ze klaar waren om het gat wat Windows 95 qua user experience heeft achtergelaten destijds op te vullen. Anders was GNU/Linux ook als desktop OS nu de marktleider geweest.
Indien je het nog niet wist, maar de meeste huis tuin en keuken elektronica met intelligente functies bevat Linux of een *BSD. Te denken aan je telefoon (o.a. Android) je Navigatie systeem (o.a. TomTom), je ADSL/Kabelmodem (meeste merken), Telefooncentrales (Asterisk embedded + Linux), Internet Radio's/Wekkers, Intelligente Televisies etc.. etc..
Maar ook voor supercomputers.
http://en.wikipedia.org/w...frames_and_supercomputers
Een "gratis" open besturing systeem scheelt veel R&D en hoef je als fabrikant alleen maar te focussen op je hardware en de specifieke toepassing.
[Reactie gewijzigd door totaalgeenhard op 15 maart 2012 05:37]
Mooi stukje, maar je laatste 2 zinnen snap ik absoluut niets van. Volgens mij is juist het enige grote nadeel aan linux, het feit dat het VEEL meer R&D uren kost om het perfect aan de praat te krijgen met bovendien kennis die maar bij relatief weinig (dure) mensen beschikbaar is.
Ik werk in de elektronica en zelfs elektroboys krijgen zonder problemen vanalles aan de gang in (embedded) windows, ondanks het feit dat programmeren niet hun vakgebied is. Maar ze zullen nooit ook maar iets aan de praat krijgen in linux. Daar is dan een embedded linux specialist voor nodig (die op zijn beurt weer niks met windows of elektronica kan).
Ik werk in de elektronica en zelfs elektroboys krijgen zonder problemen vanalles aan de gang in (embedded) windows, ondanks het feit dat programmeren niet hun vakgebied is. Maar ze zullen nooit ook maar iets aan de praat krijgen in linux. Daar is dan een embedded linux specialist voor nodig (die op zijn beurt weer niks met windows of elektronica kan).
Dat zegt dan misschien meer over de specifieke ervaring van die elektroboys... voor het zelfde geld is het precies andersom... Ik denk dat het over het algemeen niet veel verschilt, beide systemen hebben hun eigenaardigheden en specifieke problemen.
(OT)
Blijkbaar zijn bijvoorbeeld Panasonic, LG en Samsung (om er een paar te noemen) het daar niet mee eens: ze gebruiken allemaal Linux in (onder andere) hun televisies, waar vroeger nog zelfgemaakte OS/firmware op de electronica draaide.Mooi stukje, maar je laatste 2 zinnen snap ik absoluut niets van. Volgens mij is juist het enige grote nadeel aan linux, het feit dat het VEEL meer R&D uren kost om het perfect aan de praat te krijgen met bovendien kennis die maar bij relatief weinig (dure) mensen beschikbaar is.
Zolang je met mainstream electronica werkt en zelf geen ontwikkeling doet, kun je inderdaad met (allerlei) Windows uit de voeten. Zodra je specifieke wensen hebt, is dat makkelijker te integreren in een Linux-omgeving dan op Windows.Ik werk in de elektronica en zelfs elektroboys krijgen zonder problemen vanalles aan de gang in (embedded) windows, ondanks het feit dat programmeren niet hun vakgebied is. Maar ze zullen nooit ook maar iets aan de praat krijgen in linux. Daar is dan een embedded linux specialist voor nodig (die op zijn beurt weer niks met windows of elektronica kan).
Panasonic, LG, Samsung.... Dat zijn multinationals die voldoende budget hebben om een compleet team op te zetten voor dit soort doeleinden. Die hoeven niet terug te vallen op "electroboys".
Wat R&D uren betreft, hij had het over embedded appliances. Als het geen intel is is Windows sowieso geen optie. Je hebt dan de keus tussen zelf een (evt Realtime) OS ontwikkelen of laten ontwikkelen, of een open source OS als linux/BSD, waarbij je alleen drivers voor je specifieke hardware hoeft te ontwikkelen. Dat laatste is uiteraard goedkoper.
In de elektronica zie je helaas nog dat voor veel micro controllers alleen compilers en programmers in windows bijgeleverd worden (PIC, AVR). Arduino is een uitzondering en gelukkig sterk in opkomst, al is het nog een beetje in de hobby sfeer. Maar daar begint het vaak :-)
In de elektronica zie je helaas nog dat voor veel micro controllers alleen compilers en programmers in windows bijgeleverd worden (PIC, AVR). Arduino is een uitzondering en gelukkig sterk in opkomst, al is het nog een beetje in de hobby sfeer. Maar daar begint het vaak :-)
Dat Linux de desktopmarkt heeft gemist, heeft niet zozeer te maken met de UI. Ik zie trouwens niet in waar Win95 een gat heeft achtergelaten?
Linux heeft eerder last van een kip-of-eiverhaal wat betreft consumentensoftware/hardware. Ik gebruik hier op 't werk Ubuntu, heel tevreden over, verschroeiend snel en fijne GUI.
Maar thuis, als ik mijn audio-interfaces wil gebruiken, Cubase wil draaien of Fallout wil spelen, blijf ik in de kou staan. Ik weet het, dat is niet "de fout van Linux", maar het blijft wel een feit dat bepaalde dingen niet willen vlotten, en dat zijn net die dingen die veel techies gebruiken.
Nu kan je zeggen, jamaar, mijn opa heeft geen Cubase nodig, installeer dan daar Ubuntu. Maar het probleem is dat je early adopters en techneuten nodig hebt die zichzelf er vertrouwd mee maken, en dat vervolgens mond-aan-mond aan andere mensen verkopen. FF heeft het zo gedaan: toffe browsers, mooi alternatief, alle IT-volk installeert dat thuis, en de volgende stap is dat ze het bij oma en opa installeren, en hoppekee, de bal gaat aan het rollen.
PS: Laat die Wintendo alsjeblieft achterwege. Dat komt echt wel infantiel over...
Linux heeft eerder last van een kip-of-eiverhaal wat betreft consumentensoftware/hardware. Ik gebruik hier op 't werk Ubuntu, heel tevreden over, verschroeiend snel en fijne GUI.
Maar thuis, als ik mijn audio-interfaces wil gebruiken, Cubase wil draaien of Fallout wil spelen, blijf ik in de kou staan. Ik weet het, dat is niet "de fout van Linux", maar het blijft wel een feit dat bepaalde dingen niet willen vlotten, en dat zijn net die dingen die veel techies gebruiken.
Nu kan je zeggen, jamaar, mijn opa heeft geen Cubase nodig, installeer dan daar Ubuntu. Maar het probleem is dat je early adopters en techneuten nodig hebt die zichzelf er vertrouwd mee maken, en dat vervolgens mond-aan-mond aan andere mensen verkopen. FF heeft het zo gedaan: toffe browsers, mooi alternatief, alle IT-volk installeert dat thuis, en de volgende stap is dat ze het bij oma en opa installeren, en hoppekee, de bal gaat aan het rollen.
PS: Laat die Wintendo alsjeblieft achterwege. Dat komt echt wel infantiel over...
LOI PC cursus gevolgd zeker? Ik heb er wel eens inzage in gehad, daar stellen ze inderdaad dat een harddisk geheugen is. Feitelijk wel juist maar in de praktijk verwarrend
Het onderscheid tussen disk en geheugen is helemaal niet zo scherp. Ook niet altijd in de praktijk.
Zo zijn er genoeg mensen die een Flash drive gebruiken voor wat extra RAM. (ReadyBoost)
Met de komst van SSD's aan de ene kant en 64-bits geheugen adressering aan de andere kant, zie ik op de midellange-termijn nog wel weer dat "geheugen" en "schijfruimte" weer 1 en hetzelfde worden.
Vroeger maakte ik, voor performance, nog wel eens een RAM-drive aan, maar in de toekomst dan maak je misschien gebruik van disk-RAM. Een soort ReadyBoost, maar dan gewoon een partitie van je SSD.
Zo zijn er genoeg mensen die een Flash drive gebruiken voor wat extra RAM. (ReadyBoost)
Met de komst van SSD's aan de ene kant en 64-bits geheugen adressering aan de andere kant, zie ik op de midellange-termijn nog wel weer dat "geheugen" en "schijfruimte" weer 1 en hetzelfde worden.
Vroeger maakte ik, voor performance, nog wel eens een RAM-drive aan, maar in de toekomst dan maak je misschien gebruik van disk-RAM. Een soort ReadyBoost, maar dan gewoon een partitie van je SSD.
[Reactie gewijzigd door Keypunchie op 15 maart 2012 08:37]
Misschien in hoeveelheid en in prijs niet, voor de gebruiker dan. Voor het systeem is er een onoverbrugbaar verschil in block devices en memory technology devices aan de ene kant, en RAM (in allerlei varianten) aan de andere kant. Dat je op den duur RAM met persistentie krijgt, is een heel ander verhaal.Het onderscheid tussen disk en geheugen is helemaal niet zo scherp. Ook niet altijd in de praktijk.
Nee, ook voor het systeem is er geen scherp verschil. RAM wordt al lang niet meer byte-wise benadert, maar in "blokken" c.q. cache lines. Het wordt gemanaged in pages, ook op HW nivo (dmv de MMU). RAM is dus hardwarematig een block device.
Ik denk dat ie de maximale partitie grote bedoeld. Uit m'n hoofd is die bij de laatste versie van NTFS 256 TB.NTFS kan helemaal geen geheugen adresseren. Het is een filesysteem geen memory manager.
NTFS (in brede zin) wijzigt bijna bij elke Windows versie wel iets. Zie ook het versie overzicht op Wikipedia.Altijd mooi een stukje technologie, ik ben benieuwd hoelang het duurt voordat windows met iets nieuws komt. Hoeveel geheugen kan NTFS adresseren?
En waarom zou een filename meer dan 255 karakters moeten zijn, het is een beperking maar ik ben er werkelijk nog nooit tegen aangelopen.
[Reactie gewijzigd door PolarBear op 14 maart 2012 20:38]
Dat is geen beperking van ntfs, maar van unc paden, of beter: de windows api. Niet het bestandssysteem. En ik ben er al heel vaak tegen aan gelopen: diepe paden met lange bestandsnamen waar opeens niet weggescreven kan worden. (en met een mapping waarmee je het pad drastisch inkort weer wel.)
Die beperking blijft bestaan vanwege backwards compatibaliteit.
Die beperking blijft bestaan vanwege backwards compatibaliteit.
Ben ik laatst tegenaangelopen op de computer van een collega. Die had via FTP een directorystructuur met een recursive symlink erin gedownload, en dat was wonder boven wonder dus honderden niveau's diep op zijn harddisk beland. Hoe het erop gekomen is weet ik nog steeds niet, maar wat ik wel weet is dat windows op een gegeven moment niet verder kan waardoor je die map never de nooit niet van je harddisk af kunt krijgen.
Uiteindelijk met linux geboot, ntfs-3g gebruikt en met een simpele rm -rf was de map weg.
Uiteindelijk met linux geboot, ntfs-3g gebruikt en met een simpele rm -rf was de map weg.
Dat kun je prima, maar dan moet je wel \\?\ voor het pad zetten. Tikje obscuur, dat wel.maar wat ik wel weet is dat windows op een gegeven moment niet verder kan waardoor je die map never de nooit niet van je harddisk af kunt krijgen.
Ik ben er ook regelmatig tegenaan gelopen, een rar file gedownload bijv. met ontzettend veel submappen. Die moest ik dan in de root van de hdd uitpakken, deed ik dat in de downloadfolder waardoor je al 3 a 4 niveau's diep zat werd het hem net teveel en gaf Winrar foutmeldingen. Verbaasde mij ook moet ik zeggen.
Dat heeft niks te maken met te lange bestandsnamen, maar met te lange paden.
Eventjes gequote:
Dit was bij xp vista en 7 zijn wat groter
http://en.wikipedia.org/wiki/NTFS#LimitationsMaximum volume size
In theory, the maximum NTFS volume size is 264−1 clusters. However, the maximum NTFS volume size as implemented in Windows XP Professional is 232−1 clusters partly due to partition table limitations. For example, using 64 kB clusters, the maximum Windows XP NTFS volume size is 256 TB minus 64 kB. Using the default cluster size of 4 kB, the maximum NTFS volume size is 16 TB minus 4 kB. (Both of these are vastly higher than the 128 GB limit lifted in Windows XP SP1.) Because partition tables on master boot record (MBR) disks only support partition sizes up to 2 TB, dynamic or GPT volumes must be used to create NTFS volumes over 2 TB. Booting from a GPT volume to a Windows environment requires a system with UEFI and 64-bit support.[63]
Dit was bij xp vista en 7 zijn wat groter
[Reactie gewijzigd door Damic op 14 maart 2012 20:43]
Zover ik weet komt Microsoft in Windows 8 met ReFS. Voorlopig echter alleen voor servers.ik ben benieuwd hoelang het duurt voordat windows met iets nieuws komt
Ik heb nog linux spul op ext3 en ext2 draaien... Laptops, oude SUN sparc machine, m'n routertje wat op dit moment draait met een embedded AMD pentium class CPU en als 'HD' een CF kaartje (maar wat ooit is begonnen als een afgedankte 486 met een slackware distro en een Quantum Bigfoot erin) dat soort spul.
Misschien moet ik toch maar eens wat upgraden of op z'n minst voor mijn routertje GCC op wat nieuwe kernel code laten kauwen.
[Reactie gewijzigd door jiriw op 14 maart 2012 20:58]
waarom niet concentreren op verdere ontwikkeling van zfs oracle?
Omdat Oracle zelf de licentie niet aanpast?
ZFS is gelicenceerd onder CDDL, de linux kernel onder GNU GPL. Hoewel dit allebei open source licenties zijn zijn ze niet compatible met elkaar.
[Reactie gewijzigd door Roconda op 14 maart 2012 21:07]
Daarnaast is Oracle aangeklaagd door NetApp wegens patentinbreuk. Dat is tevens de reden dat Apple nooit is overgeschakeld van HFS+ naar ZFS. (ZFS zat experimenteel in OS X Leopard (10.5) maar was verdwenen met 10.6. (snow leopard).ZFS is gelicenceerd onder CDDL, de linux kernel onder GNU GPL. Hoewel dit allebei open source licenties zijn zijn ze niet compatible met elkaar.
je kan wel spelen met zfs op linux. Dit werkt met kernel modules.
Tevens is er ook een zfs-fuse package welke je onder ubuntu gewoon kan installeren:
$ apt-cache search zfs-fuse
zfs-fuse - ZFS on FUSE
zfs-fuse is erg leuk, alleen erg langzaam en vreet cpu.
Zie hier voor demo's/cheatsheet mbt native zfs en zfs-fuse: http://wiki.gentoo.org/wiki/ZFS
Tevens is er ook een zfs-fuse package welke je onder ubuntu gewoon kan installeren:
$ apt-cache search zfs-fuse
zfs-fuse - ZFS on FUSE
zfs-fuse is erg leuk, alleen erg langzaam en vreet cpu.
Zie hier voor demo's/cheatsheet mbt native zfs en zfs-fuse: http://wiki.gentoo.org/wiki/ZFS
[Reactie gewijzigd door TvL2386 op 15 maart 2012 08:31]
Wat mij vooral aanspreekt is dat er van alle data een checksum wordt gemaakt. Zo kan er geen stille corruptie van je bestanden meer plaatsvinden.
Het zou wel prettig zijn als je nog bij je bestanden mocht als er tóch een foute checksum geconstateerd werd.Wat mij vooral aanspreekt is dat er van alle data een checksum wordt gemaakt. Zo kan er geen stille corruptie van je bestanden meer plaatsvinden.
Een schijf met BTRFS wilde niet meer mounten omdat er inconsistente checksums geconstateerd waren. Check leerde dat er vijf foute checksums waren, maar zonder functionele fsck-utility kun je die niet corrigeren/overriden/verwijderen.
Ik ben er nog niet achter hoe ik de schijf alsnog kan aanspreken.
Niet meer kunnen mounten heb ik ook gehad. Ik weet niet of de reden daarvan precies is zoals bij jou.
Ik heb het kunnen oplossen door het commando btrfs-zero-log te gebruiken wanneer de partitie niet gemount is.
Ik heb het kunnen oplossen door het commando btrfs-zero-log te gebruiken wanneer de partitie niet gemount is.
en met oracle linux, bedoelen ze dus redhat linux met een stickertje
Oracle Enterprise Linux wordt maar zijdelings genoemd in te dit artikel, het gaat in het artikel voornamelijk om de Oracle Unbreakable Enterprise Kernel (en de btrfs support daain), wat gewoon is ontwikkeld op de mainline linux kernel. En de UEK is weer ontwikkeld om de nieuwe hardware van Sun te kunnen uitleveren en dan vooral de Exadata X2-8.
edit:serieus, een post over UEK die btrfs ondersteund, en mijn post over de UEK wordt gemodereerd als off-topic? que?
edit:serieus, een post over UEK die btrfs ondersteund, en mijn post over de UEK wordt gemodereerd als off-topic? que?
[Reactie gewijzigd door Ford Prefect op 15 maart 2012 14:58]
Btrfs is hartstikke mooi! Ik was er zeer over te spreken. Reden waarom ik het graag wilde was performance en de snapshot mogelijkheden.
Laptop met OCZ Vertex SSD opnieuw geinstalleerd met btrfs als filesystem.
Eerste wat mij opviel, was dat al mijn virtuele machines (windows xp, freebsd, ubuntu11.10) zo traag als stront zijn.
Blijkt dat de fsync system call onder btrfs extreem langzaam is. Apt maakt bijvoorbeeld heel veel gebruik van fsync om consistentie bij een crash/power failure te kunnen garanderen.
Zie hier een post:
http://lists.fedoraproject.org/pipermail/devel/2011-July/154251.html
Hier nog een (oude) interessante post:
http://blogs.gnome.org/desrt/2010/12/19/more-on-dconf-performance-btrfs-and-fsync/
Dit is de reden waarom ik de boel terug heb gezet naar ext4. Performance in mijn VM's is weer perfekt.
Laptop met OCZ Vertex SSD opnieuw geinstalleerd met btrfs als filesystem.
Eerste wat mij opviel, was dat al mijn virtuele machines (windows xp, freebsd, ubuntu11.10) zo traag als stront zijn.
Blijkt dat de fsync system call onder btrfs extreem langzaam is. Apt maakt bijvoorbeeld heel veel gebruik van fsync om consistentie bij een crash/power failure te kunnen garanderen.
Zie hier een post:
http://lists.fedoraproject.org/pipermail/devel/2011-July/154251.html
Hier nog een (oude) interessante post:
http://blogs.gnome.org/desrt/2010/12/19/more-on-dconf-performance-btrfs-and-fsync/
Dit is de reden waarom ik de boel terug heb gezet naar ext4. Performance in mijn VM's is weer perfekt.
Verschillen tussen ext4 & btrfs zijn volgens deze benchmarks (staar je er niet blind op) nog zeker aanwezig maar zo dramatisch:
http://www.phoronix.com/s...=linux_33_btrfs&num=1
En btrfs is nog volop in ontwikkeling dus benchmarks zien er ongetwijfeld anders uit bij kernel 3.4 en verder
http://www.phoronix.com/s...=linux_33_btrfs&num=1
En btrfs is nog volop in ontwikkeling dus benchmarks zien er ongetwijfeld anders uit bij kernel 3.4 en verder
Ik vind het een prachtig bestandssysteem, zomaar schijven toevoegen en er vanaf halen, enorme maximum capaciteit, ssd opties, snapshots, checksums en andere redundantie in de btrees, maar echt snel is het idd nog niet. Bij Ubuntu server 11.10, kreeg ik ook teveel vage foutmeldingen.
Erg veel potentieel, maar in zijn huidige implementatie nog niet betrouwbaar genoeg. Zolang fsck nog niet alles kan fixen en vrij beschikbaar is, niet voor mijn server.
Erg veel potentieel, maar in zijn huidige implementatie nog niet betrouwbaar genoeg. Zolang fsck nog niet alles kan fixen en vrij beschikbaar is, niet voor mijn server.
Er af halen? Zonder dataverlies? Hoe krijgen ze dat voor elkaar?Ik vind het een prachtig bestandssysteem, zomaar schijven toevoegen en er vanaf halen
Dat is mogelijk door de integratie van filesystem en RAID. Vroeger was het zo dat de RAID laag geen weet had van wat er eigenlijk op de schijven stond, maar met systemen als Btrfs en ZFS is dat samengevoegd. Als je een schijf wil verwijderen, dan kopieert ie gewoon simpel gezegd de gebruikte blokken van die schijf naar een andere locatie en herschrijft ie de pointers ernaartoe, terwijl er geen nieuwe gegevens meer naar die schijf gaan. Zodra niets meer naar die schijf verwijst kan deze dan veilig verwijderd worden.
Ik hoop dat dat ook nog eens in ZFS gaat komen, daar kan je nu alleen schijven uit een mirror verwijderen of toeviegen, niet uit een RAID-Z set of zelfs een hele RAID set van de pool af halen.
De integratie van filesystem en RAID levert ook andere voordelen op, zoals na het vervangen van een schijf alleen de gebruikte ruimte hoeven te rebuilden. Ook fijn is dat een schijf in principe niet meer volledig gerebuild hoeft te worden als deze even offline is geweest, ZFS resilvert dan gewoon de ontbrekende data i.i.g.
Ik hoop dat dat ook nog eens in ZFS gaat komen, daar kan je nu alleen schijven uit een mirror verwijderen of toeviegen, niet uit een RAID-Z set of zelfs een hele RAID set van de pool af halen.
De integratie van filesystem en RAID levert ook andere voordelen op, zoals na het vervangen van een schijf alleen de gebruikte ruimte hoeven te rebuilden. Ook fijn is dat een schijf in principe niet meer volledig gerebuild hoeft te worden als deze even offline is geweest, ZFS resilvert dan gewoon de ontbrekende data i.i.g.
[Reactie gewijzigd door Sfynx op 14 maart 2012 23:43]
Ik betwijfel of je dit al wel wil gebruiken voor gegevens waar je leven vanaf hangt. Hoe lang zit dit nu pas in de kernel? Zeker bij een filesystem moet je heel conservatief zijn.
Heeft Btrfs trouwens al RAID-5 en RAID-6 sets zoals ZFS de RAID-Z en RAID-Z2 vdevs heeft? Lijkt me essentieel voor goede redundantie op grote servers. Iets wat lijkt op ZFS send/receive zou ook erg aangenaam zijn, zo even een snapshot of de verschillen tussen twee snapshots kopiëren naar een andere machine... ideaal voor recovery doeleinden
ZFS heeft veel langer "gerijpt" op Solaris voordat er ook maar enige claim werd gedaan dat het productieklaar was... en dat is nu op FreeBSD nu zo'n 2 jaar productiewaardig bijvoorbeeld.
Heeft Btrfs trouwens al RAID-5 en RAID-6 sets zoals ZFS de RAID-Z en RAID-Z2 vdevs heeft? Lijkt me essentieel voor goede redundantie op grote servers. Iets wat lijkt op ZFS send/receive zou ook erg aangenaam zijn, zo even een snapshot of de verschillen tussen twee snapshots kopiëren naar een andere machine... ideaal voor recovery doeleinden
ZFS heeft veel langer "gerijpt" op Solaris voordat er ook maar enige claim werd gedaan dat het productieklaar was... en dat is nu op FreeBSD nu zo'n 2 jaar productiewaardig bijvoorbeeld.
[Reactie gewijzigd door Sfynx op 14 maart 2012 23:40]
Veel plezier er mee. Ik wacht nog minstens nog een jaartje terwijl de early adopters hun files de verdoemenis in blazen zodra btrfs het weer eens op zijn heupen heeft.
Ik heb een paar maandjes geleden nog getest en het was wel al een flink stuk beter begin 2011, maar er zijn nog genoeg plooitjes om glad te strijken.
De gedachte er achter is ok, de uitwerking moeten we nog even op wachten.
Ik blijf nog lekker bij ZFS, dat werkt erg goed.
Als btrfs dat niveau weet te halen, dan zou dat prachtig zijn. But it is not this day...
Ik heb een paar maandjes geleden nog getest en het was wel al een flink stuk beter begin 2011, maar er zijn nog genoeg plooitjes om glad te strijken.
De gedachte er achter is ok, de uitwerking moeten we nog even op wachten.
Ik blijf nog lekker bij ZFS, dat werkt erg goed.
Als btrfs dat niveau weet te halen, dan zou dat prachtig zijn. But it is not this day...
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Microsoft Apple Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
