F2fs-bestandssysteem wordt opgenomen in Linux-kernel 3.8
De aankomende Linux-kernelversie 3.8 zal voorzien worden van ondersteuning voor f2fs, een door Samsung ontwikkeld bestandssysteem dat is geoptimaliseerd voor het lezen en wegschrijven van data naar flashgeheugen.
F2fs, ofwel flash-friendly file system, is volgens de ontwikkelaars bedoeld voor flashopslagmedia die gebruik maken van een flash transaction layer, zoals usb-sticks, sd-kaarten en flashchips die met name in mobiele apparaten zijn te vinden. Het bestandssysteem schrijft data sequentieel weg, waarbij nieuwe data steeds achter het vorige blok wordt weggeschreven. Als het medium vol is, begint f2fs weer aan het begin. Door dit schrijfmechanisme te hanteren naar flashopslag, zou f2fs beter samenwerken met de onderliggende flash transaction layer en moeten writes naar het flashgeheugen zo efficiënt mogelijk worden verdeeld.
Samsung gaf al bij de aankondiging van het f2fs-bestandssysteem aan dat de code in de Linux-kernel kan worden opgenomen. Dat is inmiddels gebeurd: de code en de bijbehorende f2fs-beheertools zijn opgenomen in de bouwplannen voor kernel 3.8, zo meldt The H Open.
Door het opnemen van het bestandssysteem biedt de Linux-kernel een extra optie voor software die data wegschrijven naar flashmedia, al is de keuze aan verschillende bestandssystemen voor het opensource-besturingssysteem groot te noemen. Linux-kernel 3.8 zal naar verwachting in februari beschikbaar komen.
Samsungs nieuwe bestandssysteem zou mogelijk toegepast kunnen gaan worden in Android-apparaten die veelal draaien vanaf flashopslag. Of f2fs een succes zal worden, moet worden afgewacht; Samsung poogde eerder zijn robust file system te implementeren op onder andere de Galaxy S-smartphone, maar de prestaties van rfs bleken in de praktijk ondermaats. Bij de introductie van de Galaxy S II koos Samsung uiteindelijk voor het beproefde ext4-bestandssysteem.
Reacties (50)
Ik neem aan dat dit wel vrije ruimte vanaf het begin betekent. Anders moet je flink oppassen dat je niet je vrije ruimte volmaakt, omdat je dan ook het risico loopt de data die aan het begin staat kwijt te raken omdat het overschreven kan worden. Dan krijg je net zoiets als een ouderwets wachtwoordinvoerveld waarin je na een beperkt aantal tekens steeds het laatste teken overschrijft wanneer je een wachtwoord invoert dat langer is dan is toegestaan. (En dus weet je ineens je wachtwoord niet meer...)
Je krijgt op deze manier toch wel een heleboel gefragmenteerde bestanden, denk ik.
[Reactie gewijzigd door Jorgen op dinsdag 25 december 2012 23:29]
hetgeen er nu het dichts bij in de buurt komt windows search, en indexing van je drive.
met winfs zou je je mail gewoon op winfs kunnen opslaan en er in zoeken. lijkt me handig voor projecten e.d.
maar ja
hoe verkoop je dan nog sql server, en exchange......
ik vind het nog altijd jammer dat r niets meer mee is gedaan.
ik meende bijvoorbeeld dat er ook opensource ontwikkelingen waren die ook zoiets als winFS deden.
ik heb zelf het idee dat winfs een te radicale wijziging in werken zou zijn geweest die zo enorm veel op zou kunnen leveren, dat wanneer je daar een kostprijs aan zou koppelen, men dat niet zou kunnen betalen. ook was het geloof ik best resource intensief. maar dat is tegenwoordig denk ik geen issue meer.'
dan is het voor MS lucratiever om "gewoon" ntfs te blijven gebruiken, en iets verder uit te breiden. op een manier die wat overeenkomt met de concurrentie, zodat ze niet teveel voorop gaan lopen en daarvoor bestraft worden , of het idee te snel "gestolen" zou worden"
Volgens mij levert het sequentieel maken van een random access volume niet veel tijdwinst op. Vooral niet als het apparaat toch al volledig elektronisch is zonder bewegende delen.Het bestandssysteem schrijft data sequentieel weg, waarbij nieuwe data steeds achter het vorige blok wordt weggeschreven. Als het medium vol is, begint f2fs weer aan het begin. Door dit schrijfmechanisme te hanteren naar flashopslag, zou f2fs beter samenwerken met de onderliggende flash transaction layer en moeten writes naar het flashgeheugen zo efficiënt mogelijk worden verdeeld.
Zoiezo vraag ik me af hoe erg sequentieel het echt is, aangezien je ook ergens een index oid moet plaatsen. (Ik neem aan dat je niet het hele ding van begin tot eind wil doorlopen als je een bestand zoekt. En hoe zit het met de fragmentatie? Als je alle weg te schrijven data geforceerd achter elkaar plaats betekent dat dat je je bestanden meestal in stukken moet knippen/herstellen bij het schijven/lezen en mogelijk meer blokken moet benaderen dan nodig is. Ook niet echt bevorderlijk de snelheid lijkt me.
Het lijkt me niet mogelijk de snelheid van een USB-stick beter te krijgen dan wanneer je hem in zo groot mogelijke blokken volschrijft. Als je computer 16 GB heeft kan je dus een 8GB stick in een keer vol trappen op de maximaal haalbare snelheid.
[Reactie gewijzigd door blorf op maandag 24 december 2012 12:37]
Ik kan je dus maar aanraden om zelf even op zoek te gaan naar informatie over het filesystem.
http://lwn.net/Articles/518988/ is bijvoorbeeld een zeer goeie intro en beantwoordt al je vragen.
[Reactie gewijzigd door H!GHGuY op maandag 24 december 2012 12:37]
Maar ze zullen wel een compelling argument gehad hebben, zo snel wordt je code niet opgenomen.
Edit: en inderdaad, een NAND device presenteert zich blijkbaar als een eenvoudige lijst met blokken. Dan moet je het wel in je filesystem implementeren.
[Reactie gewijzigd door mekkieboek op maandag 24 december 2012 11:59]
Al moet ik zeggen dat er nog heel wat werk te verrichten valt bij de Exynos SOC,
blijft de open source tendens toch min of meer aanhouden in het bedrijf.
Echt vergelijken kun je dus niet, hoewel UBIFS mogelijk wel zou kunnen aangepast worden om inplaats van bovenop UBI te werken, ook bovenop een FTL te kunnen werken.
Zie trouwens http://lwn.net/Articles/528617/ en voorgaande artikels. Die belichten de achtergrond van F2FS en de andere filesystems.
Alle nodes moeten gescanned worden bij het mounten.. fijn als je een 32 of 64 GB SD gebruikt.
Veel overhead bij kleine writes
Geen goede methode om te zien hoeveel vrije ruimte er is op een device.
Dit werkt toch ook door middel van flash geheugen?
Dus moet je voor NAND devices meer doen in de laag erboven, je filesystem.Bare NAND is presented as a block device. NAND SSDs are also presented as block devices. That does not imply that they are equal. SSDs have a controller that does remapping on the fly, in many cases on the fly compression, bad block handlling and much more. Bare NAND does not have that layer.
Daar zit dus simpel gezegd een soortement van shift register op (in de vorm van de ssd controller die natuurlijk wel wat meer uitspookt dan alleen dat.)
Eigenlijk moet je hier kijken:
http://lkml.indiana.edu/h.../kernel/1210.2/00005.html
Samenvattting:
Mounten duurt langer, de rest is sneller.
[Reactie gewijzigd door Dreeke fixed op maandag 24 december 2012 17:24]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
