concepten als rijen, tabellen en transacties, en had tot doel om zoekopdrachten te versnellen
1. Het belangrijkste voordeel is de mogelijkheid tot sneller zoeken. Met de huidige bestandssystemen moet je meestal sequentieel door alle bestanden, dat is erg inefficient. Is het het je nooit opgevallen dat het
veel langer duurt om iets op je eigen hard disk terug te vinden dan op het hele internet met google? En als je een search accelerator gebruikt zakt de performance van je computer weer in (google desktop was daar berucht om).
2. De rijen en tabellen zijn voornamelijk "nuts and bolts" van een databasemodel, die voegen niet veel toe als je een bestandssysteem wilt emuleren. Alleen dit: probeer het volgende eens in een huidige Windows-versie:
- Ga naar een map met veel foto's, zet de weergave op details
- Zet wat extra kolommen aan, bijvoorbeeld "Date Picture Taken" en "Dimensions"
- Sorteer op een standaardkolom, b.v. "Date Modified", kijk hoe lang dat duurt.
- Probeer dan te sorteren op een van de extra kolommen. Dat duurt
veel langer.
Met een tabelstructuur is de "metadata" van het bestandssysteem beter uitbreidbaar te maken en zullen dingen als die extra kolommen veel soepeler kunnen werken.
3. Transacties: dat maakt recovery bij mislukte (of onbedoelde) acties beter mogelijk. Denk aan undelete.
4. Niet in het artikel genoemd: een databasemodel maakt versiemanagement beter mogelijk. Met versiemanagement wordt het mogelijk om na opslaan van wijzgingen ook nog vorige versies van een bestand terug te halen.
5. Ook niet genoemd: views. Een view is een soort "virtuele tabel" van records die eigenlijk fysiek anders georganiseerd zijn. Bijvoorbeeld je hebt een grote bak mp3's en je kan die ook als mappen per artiest, of per genre bekijken. De libraries in Windows 7 zijn daar een aanzet toe, maar het werkt niet lekker zonder een echte database er achter.
Ik heb geen idee wat er in ReFS moet komen, maar dit zijn zo'n beetje de pluspunten die
in principe mogelijk zijn bij keuze voor database storage.
[Reactie gewijzigd door berend_engelbrecht op donderdag 1 december 2011 21:08]
2. De rijen en tabellen zijn voornamelijk "nuts and bolts" van een databasemodel, die voegen niet veel toe als je een bestandssysteem wilt emuleren. Alleen dit: probeer het volgende eens in een huidige Windows-versie:
- Ga naar een map met veel foto's, zet de weergave op details
- Zet wat extra kolommen aan, bijvoorbeeld "Date Picture Taken" en "Dimensions"
- Sorteer op een standaardkolom, b.v. "Date Modified", kijk hoe lang dat duurt.
- Probeer dan te sorteren op een van de extra kolommen. Dat duurt veel langer.
Met een tabelstructuur is de "metadata" van het bestandssysteem beter uitbreidbaar te maken en zullen dingen als die extra kolommen veel soepeler kunnen werken.
Dat heb ik werkelijk nog nooit hoeven doen. En ik heb al heel wat windows gezien.
3. Transacties: dat maakt recovery bij mislukte (of onbedoelde) acties beter mogelijk. Denk aan undelete.
Dat wil dus zeggen dat je je records bewaart. Moet je ze op een gegeven moment toch opruimen. Hoe is dat anders dan de trashcan?
Wat ik echter gek vindt is dat sinds NTSF undelete ineens een heel stuk moeilijker is geworden. Ik kan me Win95 en dos herinneren waar je het heel bont moest maken wilde je je files, inclusief map, niet meer terug kunnen halen.
4. Niet in het artikel genoemd: een databasemodel maakt versiemanagement beter mogelijk. Met versiemanagement wordt het mogelijk om na opslaan van wijzgingen ook nog vorige versies van een bestand terug te halen.
Niet vernieuwend hoor. VMS heeft dat al heel lang en er zijn ook andere versioning file systems in gebruik.
5. Ook niet genoemd: views. Een view is een soort "virtuele tabel" van records die eigenlijk fysiek anders georganiseerd zijn. Bijvoorbeeld je hebt een grote bak mp3's en je kan die ook als mappen per artiest, of per genre bekijken. De libraries in Windows 7 zijn daar een aanzet toe, maar het werkt niet lekker zonder een echte database er achter.
En daar zie ik het enig voordeel. En gelijk een nadeel, want je moet wel al die tags er aan hangen waar je voorheen er maar een (de folder) aan hoefde te hangen.
Wordt het dan makkelijker? ja, mogelijk,
als je er de extra moeite voor over hebt.
Met wat geluk helpen automatisch gegenereerde tags in bepaalde omstandigheden. De tijd zal het uitwijzen. Ik sta vooralsnog niet te springen.
[Reactie gewijzigd door Durandal op donderdag 1 december 2011 23:01]
Wat ik echter gek vindt is dat sinds NTSF undelete ineens een heel stuk moeilijker is geworden. Ik kan me Win95 en dos herinneren waar je het heel bont moest maken wilde je je files, inclusief map, niet meer terug kunnen halen.
Hoezo moeilijker? Omdat er geen standaard undelete tool wordt geleverd met het OS? Er zijn genoeg tooltjes die voor NTFS / ext2 / ext3 undelete functionaliteit geven. (Zie bijvoorbeeld
UnEraser en
ext3grep. )
Immers is het volgens mij nogsteeds zo dat de file alleen maar uit je partitie tabel wordt weggegooid en dat het niet fysiek verwijderd wordt. Alleen tja, als de blokken vervolgens overschreven worden door andere files heb je niks meer aan die tooltjes ...
Files staan niet in een partitietabel.
Het filesystem maakt er verwijzingen naar (pointers) die hebben overal zo'n beetje hun eigen naam. NTFS heeft de MFT (Main File Table) en ext bijv. inodes. De pointers worden inderdaad verwijdert, het bestand op zich niet.
Echter hoe complexer de filesystems worden, des te moeilijker voor een undelete tool om te achterhalen wat precies bij het bestand hoorde. In FAT had je gewoon een blok van X bytes en werd er (zoveel mogelijk) sequentieel geschreven, derhalve had je een goede kans dat de opvolgende blokken er ook bij hoorde. Als je undelete tool dan enige kennis van bestanden heeft (bijv. weet hoe een jpeg er uit hoort te zien, of een .doc bestand) dan kan dat vrij simpel.
Het wordt een stuk lastiger als je FS halverwege blok 1988414 begint waar ook al een stuk data van een ander bestand in staat en het dan potentieel ook nog hevig gefragmenteerd is.
Het is niet voor niks dat undelete steeds minder ondersteund wordt. Journaling en copy-on-write bijv. in nieuwe filesystems zou e.e.a. beter moeten maken zolang het filesystem consistent is, maar als je filetables / journals zwaar beschadigd zijn kun je weleens een serieus probleem hebben (backups maken is echt geen overbodige luxe, schijven kunnen ook kapot
).
Wat ik bedoelde te zeggen is niet dat dit nieuwe features of nieuwe ideeën zijn, natuurlijk niet. De vraag was: wat is het voordeel van een database als file system en ik wilde uitleggen welke
bestaande functies met zo'n database
beter geimplementeerd kunnen worden dan nu met NTFS.
1. Search spreekt voor zich, dat werkt buitengewoon slecht nu. Database engines (zowel Oracle als SQL Server) hebben vrij goede full text search engines ingebouwd. Overigens is die van Microsoft afgeleid van Index Server - de basis van Windows search, maar via de database kan je krachtiger en preciezere zoekopdrachten geven. Bijvoorbeeld zoeken op datum werkt slecht in stand-alone Index Server en is eenvoudig te maken met datumvelden in de tabel waar de bestanden zitten.
2. Het voorbeeld was bedoeld om te illustreren dat sorteren op custom kenmerken van bestanden nu weliswaar kan, maar slecht werkt. Wat ik beschrijf kan zeker al vanaf Windows 2000 (misschien al eerder, kan me niet herinneren of Windows 9x het kon), maar het werkt duidelijk veel trager dan bij de ingebouwde kolommen. Het punt is dat de properties van NTFS niet uitbreidbaar zijn, daarom moet bij het sorteren op een custom property elk bestand telkens opnieuw geraadpleegd worden. Dat maakt het traag.
3. Met een transaction log (Oracle: undo segment) zou je multi-step undo kunnen maken. Of ze dat ook gaan doen weet ik niet. Dat het log erg groot kan groeien klopt. Multi-step undo heeft nogal wat overlap met versiemanagement [4], dus het zou vrij overbodig kunnen zijn. De
transaction is een concept dat vrijwel elk DBMS gebruikt om de integriteit van gecombineerde updates en parallele wijzigingen door verschillende clients te garanderen, misschien is dat een betere functie om te noemen.
4. VMS had versiemanagement, maar NTFS niet (tenminste niet native). Voor hun programmeertools gebruikt Microsoft
TFS, dat gebruikt SQL Server als data layer. Ik kan me niet voorstellen dat dit niet iets is waar ze niet ook voor hun database file system naar kijken.
5. Libraries zitten al in Windows 7, dus ook een bestaande functie die beter kan. On the fly views maken is ook standaard in een DBMS, zou ik persoonlijk erg handig vinden.
[Reactie gewijzigd door berend_engelbrecht op vrijdag 2 december 2011 07:07]
Ben erg benieuwd naar hoe de search 'altijd' goed zou moeten werken.
Bijv. MP3's hebben in het bestand zelf tags staan. Dit zou betekenen dat het Filesystem hiervan op de hoogte moet zijn en deze tags ook in de database zou moeten opnemen. Dan zit je dus ook met synchronisatie als tags in het bestand gewijzigd worden (deze moeten weer bijgewerkt worden in het filesystem dan).
Voor de meest bekende bestandstypen is dat uiteraard nog wel te regelen. Maar hoe zit het dan met onbekende bestandsformaten?
Voor onbekende formaten kan alleen de naam van het bestand gebruikt worden.
En dan heb je nog geluk dat het lokaal staat. Zoeken op netwerkschijven is helemaal een ramp.
Dergelijke bestandsparsers wil je ook echt niet in je kernel hebben trouwens...
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
18:05
16:40
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
) ontbrekende pakketten kan downloaden. 
. Genoeg tijd gehad om inmiddels de kinderziektes eruit te halen, toch?
