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 , , 57 reacties
Bron: SourceForge, submitter: Roodkapje

Szakacsits Szabolcs heeft via de mailinglist van het Linux-NTFS-project bekendgemaakt dat hij een nieuwe read/write-NTFS-driver heeft ontwikkeld. De driver is gebaseerd op ntfsmount van het Linux-NTFS-project, maar is zodanig herschreven dat de performance, kwaliteit en functionaliteit sterk zijn toegenomen, aldus Szabolcs. Dit heeft ertoe geleid dat de nieuwe driver, die ntfs-3g is genoemd, in staat is om een zo goed als onbeperkt aantal bestanden te lezen en te schrijven op NTFS-partities. De driver kan nog niet omgaan met geŽncrypteerde bestanden, het schrijven naar gecomprimeerde bestanden, het wijzigen van de eigenaar van bestanden en het veranderen van toegangsrechten op bestanden. De afgelopen tijd heeft Szabolcs zijn driver grondig getest door ettelijke miljoenen bestanden en directory's aan te maken, te wijzigen en te verwijderen op zijn testpartities. Om de driver uitgebreider te laten testen, heeft Szabolcs de broncode van ntfs-3g openbaar gemaakt onder de GPL.

Tot op heden bestonden er ruwweg drie mogelijkheden om NTFS-partities onder Linux te benaderen. De eerste optie is de NTFS-driver die zich in de kernel bevindt. Deze kan onbeperkt bestanden en directory's lezen, maar is sterk beperkt in zijn mogelijkheden tot het schrijven van bestanden. Verder is er ntfsmount, die beschikt over iets meer mogelijkheden om bestanden en directory's aan te maken, te wijzigen en te verwijderen dan de huidige kerneldriver. De derde optie is gebruikmaken van Captive NTFS. Daarbij wordt ntfs.sys, de NTFS-driver van Windows zelf, ingeladen zodat NTFS-partities volledig gebruikt kunnen worden binnen Linux. Bij deze twee laatste manieren, en ook in het geval van ntfs-3g, bevindt de driver zich niet in kernelspace, maar in userspace via FUSE. Dat betekent onder meer dat problemen in de driver er niet voor zullen zorgen dat het hele Linux-systeem stopt met werken, maar dat de driverservice opnieuw gestart kan worden.

Moderatie-faq Wijzig weergave

Reacties (57)

Als Captive NTFS al bestaat, waarom zou je dan nog dit willen gebruiken?
Omdat Captive NTFS alleen een wrapper om de Windows driver heen is, net als bijvoorbeeld de NDISWrapper. Nadeel is dat er een vertaalslag tussen zit, en dat komt de performance niet ten goede. Daarnaast is ntfs.sys benodigd voor Captive NTFS, welke eigendom is van Microsoft. Deze kan niet met de kernel meegeleverd worden (rechtenkwestie), en moet er dus best wat moeite gedaan worden om dit werkend te krijgen. Een native Linux driver is dus ook gebruiksvriendelijker.

Edit: prachtig hoe iedereen met omdat begint _/-\o_
Hmmjah oke, da's habe ich allemaal nicht gewust und so nah? :P lol
Captive NTFS is erg traag en je hebt officieel een windows licentie nodig om het te gebruiken.
Omdat je met Captive NTFS gebruik maakt van drivers van MS, iets wat inhoudt dat je officieel een licentie moet hebben. Het is natuurlijk veel netter als er een opensource driver is, waar je dus geen drivers uit een OS moet gebruiken waar je geld voor hoeft te betalen.
Omdat Captive ook een redelijke berg problemen heeft/had. Zo zaten er een paar enorme geheugen lekken in (ik hou me nu in om een flame te starten over geheugen lekken in Windows ;))

Zo kreeg Captive het voor elkaar om bij lang draaien en werken met grote bestanden gewoon bijna 1,5 GB geheugen te gebruiken. Beetje veel... :)
Omdat captive niet "free" is.
Omdat, blijkbaar, de performance crap is.
Omdat captive een Windows NT licensie nodig heeft.
a. Omdat captive alleen werkt voor Intel systemen. Linux/UNIX/BSD/MacOS/Solaris kunnen op andere architecturen kan draaien. bijvoorbeeld een usb-harddisk met ntfs die je wilt kunnen beschrijven ;)

b. Linux (GNU) is begonnen met focus om een vrij systeem te maken, onafhankelijk van de vercommercialisering en het ontstaan van closed-source software. Zo'n groep neemt geen genoegen met een pragmatische oplossing, maar wil meer.
Captive is ontzettend traag. zo'n 250kb/s overdracht snelheid en daar heb je natuurlijk niet zoveel aan. :Y)
Waarom zou je de volle mep voor windows willen betalen voor 1 drivertje?
edit: *mental note* eerst op F5 rossen alvorens te posten :/
Je zou niet de volle mep hoeven te betalen:
XP Pro bestaat in de i386 directory uit 6588 bestanden. Een OEM licentie kost §150,-
Rekensommetje: §150 / 6588bestanden = 0,02 § per bestand.
Voor 2 cent wil ik best ntfs.sys gebruiken! 8-)
Omdat je nu met een windows driver aan het werken bent. iets waar MS niet blij mee is plus de vertaalslag zorgt ook voor vertraging.

--edit--en dan krijg je 5 gelijkaardige antwoorden op 1 minuut :)
Omdat je voor het gebruik van de Windows versie van ntfs.sys nog altijd een licentie nodig hebt. Nu kan je met puur GPL software op bestaande NTFS partities aan de gang.

[edit] Darn, 5 reacties in 1 minuut en ik ben de traagste.. Mod maar weg.
Het kan natuurlijk ook andersom (handig voor als je grote (>4 GB) files op wilt slaan op een FS dat zowel door Windows als Linux te lezen en schrijven is):

http://www.fs-driver.org/

M.a.w.: Een ext2 driver voor Windows. Ik gebruik het al tijden, en het werkt prima.
Bij mij durft die wel eens dienst weigeren. Hij vind wel altijd de partitie maar soms meld windows wel eens dat deze niet geformateerd is.
Linux is een open systeem, waar de werking wat beter gegarendeerd kan worden.

Je weet maar nooit wanneer Microsoft weer met een of andere update komt, die het je weer onmogelijk maakt een dergelijke oplossing te gebruiken. En dan heb ik het nog niet over het upgraden naar een nieuwere versie van windows.
Fuse is de bom. file systems die fuse gebruiken
Daarbij ik denk dat iedereen die een NTFS FS op zijn hd heeft een ntfs.sys driver heeft. Waarom wil je ntfs op je systeem hebben als je geen windows hebt.
ik zie het probleem niet.

Btw het gaat vrij rap. Ik gebruik het zelf.
Waarom wil je ntfs op je systeem hebben als je geen windows hebt.
Als je een USB-schijf hebt, heb je die meestal gekocht met het idee om hem ook eens mee te kunnen nemen.
Meerdere partities op de schijf gaat lang niet altijd goed bij een USB-device (oudere Windows-versies bijvoorbeeld) en is ook niet praktisch.
FAT32 wil je niet bij >32 GB, omdat dat echt problemen gaat geven. Theoretisch werkt het wel, maar in de praktijk dus niet.
Open bestands-formaten, zoals Ext-2/3, ReiserFS etc werken gewoon niet, of met hele bagger tools onder Windows.
Dus blijft over NTFS.

Kijk als er gewoon een goede plug-en-play mogelijkheid was voor een ander filesysteem, dan zou niemand inderdaad NTFS willen gebruiken op 'sleep-schijven', wanneer je zelf neit tot nauwlijks Windows gebruikt.
Maar helaas, we leven niet in een ideale wereld, wat dat betreft.
FAT32 wil je niet bij >32 GB, omdat dat echt problemen gaat geven. Theoretisch werkt het wel, maar in de praktijk dus niet.

Wat is dan het probleem in de praktijk? Ik heb een externe Hard Disk van 80GB die FAT32 heeft als bestandssysteem. Het enige waar ik problemen mee heb is de limiet van 4GB per bestand.

Ontopic: Iedereen wil graag in Linux NTFS kunnen lezen/schrijven. Maar ik vraag me eerder af hoe je door middel van cygwin Linux partities kan lezen/schrijven in Windows.
Wat is dan het probleem in de praktijk?
Probeer maar eens een directory met veel files (paar 1000) te verwijderen.
Buiten dat dat erg veel tijd kost, loop je ook nog eens een zeer grote kans dat bij de volgende keer je schijf aansluiten ineens je FAT corrupt blijkt te zijn.
Externe schijven gebruik je meestal om dingen op te archiveren of als MP3-speler ofzo. Geen dagelijks zwaar lees/schrijf gebruik in ieder geval. FAT32 is daar prima geschikt voor, ook voor schijven van honderden gigabytes.

Om corruptie tegen te gaan kun je het ontkoppel-dingetje gebruik dat ieder modern OS tegenwoordig heeft. Daarbij lijkt het mee geen grote moeite te controleren over er op dit moment naar geschreven/van gelezen wordt.

Overigens werken ext2/3 tools voor Windows hier prima. Kan ermee schrijven en lezen, en doet dat zonder corrupties.
<i>Daarbij ik denk dat iedereen die een NTFS FS op zijn hd heeft een ntfs.sys driver heeft. Waarom wil je ntfs op je systeem hebben als je geen windows hebt.</i>

Maar het is not steeds neit toegestaan ntfs.sys te distibueren, wat weer tot gevolg heeft dat als je een live-cd linux hebt dat je eerst moet gaan gogelen om de ntfs.sys van je (wellicht corrupte?) windows drive te halen en die te gebuiken. Waarbij je nog maar moet afwachten of dat nog compabible in toekomstiege windows OS. het staat MS uiteraaard vrij de interface naar ntfs.sys te veranderen, terwijl de strukturen de disk gelijk blijven.
Hoe kun je volledige NTFS ondersteuning claimen als je daarna post:
De driver kan nog niet omgaan met geŽncrypteerde bestanden, het schrijven naar gecomprimeerde bestanden, het wijzigen van de eigenaar van bestanden en het veranderen van toegangsrechten op bestanden.
Daarnaast is toegenomen "kwaliteit" een erg ruim begrip dat moeilijk objectief te meten is.

Eigenlijk is deze nieuwe NTFS driver gewoon een op een ander project gebaseerde driver die betere performance bied en her en der een paar functies meer. Volledige NTFS ondersteuning word nog lang niet geboden.
Volledige NTFS ondersteuning word nog lang niet geboden.
ntfs is gewoon een mooi voorbeeld van waarom incompatible filesystemen (want dat is ntfs aangezien het niet open is) niet wenselijk zijn..
Volledige native schrijf/lees NTFS v1.2 (NT4 NTFS) ondersteuning zou een betere omschrijving zijn.

Waarbij ik moet opmerken dat dit een significante verbetering is tov vorige projecten en NTFS drivers. Die hadden beperkingen zoals je kan wel/geen directories aanmaken maar dan weer wel/niet verwijderen van bestanden of alleen bestanden vervangen maar niet aanmaken.. een heel kluwen van beperkingen die het niet "bruikbaar" maakten.

Dit systeem biedt gratis en open source de basic filesystem mogelijkheden toegankelijk. Dat je de exotische functies van latere NTFS versies (encryption/compression) nog niet ondersteunt vind ik louter bijzaak. De meesten willen zoals TommelMOD al aanhaalde gewoon kunnen lezen/schrijven op hun Windows NTFS partitie en niet onder linux gaan frullen met NTFS compressed files enz ;)

En dat het wijzigen van eigenaarsrechten er nog niet in zit vindt ik vrij evident omdat men daar nog een compatibiliteitlayer met de POSIX ACL's wil voorzien (wat veel vťťl tijd opslorpt, maar hier kan men hopelijk bij Samba leen-tje-buur spelen, die hebben daar reeds ervaring in)
De bron zegt ook niets over volledige NTFS ondersteuning, dit wordt alleen beweerd door de nieuwsposter :)

edit: ik zie dat de titel aangepast is, zo klinkt het inderdaad beter
Weer eem typische tweakers telegraaf kop. Dit vind ik altijd zo jammer!
ik heb er niets op tegen... zolang ik de mp3's vanaf mijn windows installatie maar kan afspelen, en nog een beetje data kan overdragen van de linux-partitie naar de ntfs-partitie, ben ik blij :)

echter vindt ik het wel fijn dat het nu allemaal sneller gaat... t is idd kwalitatief moeilijk te meten, maar het is wel te bewijzen dat het sneller is... en daar gaat het tenslotte om...
Ik ken de andere ntfs programma's niet, maar hiermee kan je echt veel informatie van een bestand achterhalen. Zo geeft ntfsinfo 60 regels aan informatie over een bestand (eigenlijk de complete inode). Met onder andere 12 verschillende (MAC)tijden.
Probleem is dat als je een beetje pech hebt en de driver doet net ff niet wat Microsoft in gedachte had je zo je hele NTFS partitie kunt afschrijven (of op z'n minst er wat corruptie is, al dan niet te redden).

Captive NTFS is voor de meeste situaties wel goed genoeg, maar de performance is inderdaad om te huilen.

Goed initiatief dit, helaas zal Microsoft wel weer met een nieuwe revisie van het filesystem komen en krijgen de Linux programmeurs weer extra werk.
Interessante bonnie++ benchmarks in het originele artikel. Het schrijven van nieuwe bestanden gaat ruim anderhalf keer zo snel in dit ntfs-3g als in ext3... Bij de lees-testen staan helaas geen waarden voor ext3.

Zou wel grappig zijn als mensen ntfs als default format gingen gebruiken in linux omdat het sneller is :D
Dat wordt lastig zolang deze driver in userspace draait. Het gevolg is dat je geen kernel kan booten van NTFS. Als deze driver in kernelspace zou draaien zou dat wel kunnen. :)
Als er behoefte aan is hacked iemand vast wel een kerneldriver in elkaar. Op zich is het in de *NIX-wereld nog nieteens zo apart om een FS van een "ander" te draaien. Denk aan XFS, een zeer goed FS, van SGI of zelfs UMSDOS, van Microsoft. :)

Dit is overigens een beta-versie van die driver, dus de vraag is nog maar net of je kritische zaken WIL afhandelen met deze driver, laat staan je hele Linuxsysteem er afhankelijk van maken. Geef mijn portie maar aan Fikkie vooralsnog en deze driver lijkt me voorlopig voornamelijk handig om op LiveCD's te zetten, zodat je data op je overleden Windowspartities kunt redden. :+
Dat wordt lastig zolang deze driver in userspace draait. Het gevolg is dat je geen kernel kan booten van NTFS. Als deze driver in kernelspace zou draaien zou dat wel kunnen.
Mits je bootloader (zoals GRUB) ook een kernel image van NTFS kan lezen, anders wordt er helemaal geen kernel geboot, of deze nu NTFS in kernel space heeft of niet ;)

Ik kan zonder problemen een kernel zonder ReiserFS support booten vanaf een ReiserFS filesystem omdat GRUB ermee om kan gaan... (dat ie aan t eind van de kernel boot de / niet kan mounten laten we er even buiten :P)
erg interessant dit :) en zeker een goede ontwikkeling... maar ik snap iets in die benchmark niet..

Bij die benchmark staat voor ext3 met 16k bestanden dit:

ext3 16k 1862 en 1862 is hier het aantal seconde..
bij ntfg-3g staat dit:
ntfs-3g 16k 3021 en 3021 is weer het aantal seconde.. hier is ntfs-3g toch juist 2x zo langzaam in plaats van bijna 2x zo snel als ext3?

Hoe werken die stats eigenlijk? ik snap t effe niet dat meer seconde sneller is dan minder..
@ markg 85 (waarom kan ik hemelsnaam niet op zijn subtrhear reageren maar goed)

miss is het het schrijven van 16k files per seconden

dus meer schrijven is beter :)
het zal wel aan mij liggen, maar ik snap de logica echt niet.. zoals het daar staat lijkt het mij juist langzamer dan sneller.. hier is het hele lijstje:

Below are the averaged file creation, deletion and access performance
numbers got by running 'bonnie++ -s0' using several filesystems (the
benchmark used 16,000 files per directory in each sessions):

edit.. grafiekje weggehaald omdat het erg lelijk is.. kijk hier maar: http://sourceforge.net/ma...id=23836054&forum_id=2697

Zou iemand hier misschien een duidelijke oplossing voor kunnen geven?
@therat10430 volgens jou is het dus 16k files per seconde (in de lijst staat 3021 seconden dus dat betekend dat ie in die tijd 48336k bestanden heeft geschreven en dat de rest alsnog sneller is..) ik snap er de ballen van :P
Hier staat de man-page van Bonnie++
For performance results higher numbers are better, for CPU usage lower are better (NB a configuration scoring a performance result of 2000 and a CPU result of 90% is better in terms of CPU use than a configuration delivering performance of 1000 and CPU usage of 60%)
Kortom, de eerste waarde geeft aan hoe vaak je een bepaalde actie per seconde kunt doen, dus hoe hoger hoe beter.

edit:
De N.B. in de quote van mijzelf uit de bonnie++ manpage moest ik zonet even 2x lezen voor ik 'm zelf ook door had...
Wat ze dus willen zeggen is dat 2000 acties per sec met een CPU-use van 90% efficienter CPU-gebruik is dan 1000 operaties met 60% CPU-use. (2x zoveel operaties met maar 1,5x zoveel CPU-gebruik.)
(waarom kan ik hemelsnaam niet op zijn subtrhear reageren maar goed)
Bekende bug tussen het beeldscherm en de stoel ;)
Iets off-topic misschien:

Het geeft ook goed aan hoe de policy van Micro$oft is.
Iets meer openheid wat dit betreft lijkt me best op z'n plaats.

Tenslotte zijn het wel jouw gegevens. Hoe die opgeslagen zijn op jouw harde schijf, blijft een van de best bewaarde geheimen van deze planeet.

Dat pik je met andere zaken toch ook niet?

Als ik een bedrijf zou hebben (ongeacht wat ik zou maken) zo ik voor een zo groot mogelijke compatibiliteit met andere systemen gaan.

Helaas kan Micro$oft grenzeloos bouwen op z'n (bijna) monopoliepositie.
Banken hebben geen monopolie maar die vertellen jouw ook niet de details hoe jouw geld electronisch word verstuurd.
tuurlijk wel, andere banken moeten het geldtransport ook kunnen begrijpen...
Even een algemene opmerking. Ik stel voor om de nieuwsitems voortaan gewoon weer in normaal Nederlands te schrijven. Neem bijvoorbeeld "geŽncrypteerde bestanden". Waarom niet gewoon "versleutelde bestanden"? Of desnoods "encrypted files". Maar alsjeblieft niet "geŽncrypteerd". Dat slaat echt nergens op...
Encryptie, encrypteren, geŽncrypteerd. Ik denk dat je een neerlandicus er wel van kan overtuigen dat dat mag.
Zie http://www.vandale.nl/opz...ek/?zoekwoord=encrypteren. Encrypteren is dus een Belgisch woord. Bovendien: versleutelen of coderen is toch gewoon veel duidelijker?
Encrypteren is dus een Belgisch woord. Bovendien: versleutelen of coderen is toch gewoon veel duidelijker?
Maar het is algemeen bekend dat Belgisch Nederlands meer Nederlands is dan 'ABN'. Wij hebben onze taal een beetje laten verwateren, de Belgen juist niet. (Daarom scoren ze bij dat ene spelprogramma ook altijd zo goed)
Buitenlandse woorden verbuigen is altijd een heet hangijzer. Een beetje normale Neerlandicus zal dus adviseren het Nederlandse woord (versleuteld) te gebruiken.

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