Versie van 23 sep 2019 08:57 bewerken Mattias.Campe (overleg \| bijdragen) 4.100 bewerkingen →‎Voorbeelden ← Vorige wijziging		Versie van 2 okt 2019 09:19 bewerken ongedaan maken Mattias.Campe (overleg \| bijdragen) 4.100 bewerkingen →‎Mogelijkheden Volgende wijziging →
Regel 70: === Mogelijkheden === De verschillende bestandssystemen zijn onderling niet identiek aan elkaar qua mogelijkheden (en: ''features''). We bespreken er enkele: * de '''maximale bestandslengte, maximale bestandsgrootte, maximale partitiegrootte'''. ~~Dit kan~~Denk bv. ~~een~~aan ~~probleem~~het ~~zijn~~willen ~~als~~opslaan ~~een programma~~van een tezodanig groot bestand, ~~wil~~dat ~~opslaan~~het opbestandssysteem ~~een~~er ~~bepaald~~niet ~~bestandssysteem:~~mee overwerg kan (zelfs met voldoende vrije ruimte ~~zal het bestandssysteem hier niet mee overweg kunnen~~). * de '''toegelaten karakters'''. Zo kan je bij een Windows-systeem de melding "''De volgende tekens mogen niet in bestandsnamen voorkomen: \/:?"<>\|''" tegenkomen, waar sommige van die tekens op een Linux-systeem mogelijks wel toegelaten worden. De oorzaak is steeds het onderliggende bestandssysteem. In dit geval kan je niet zomaar bestanden verplaatsen/kopiëren van het ene naar het andere bestandssysteem. het al of niet kunnen '''toekennen van rechten'''. * '''metadata''', zoals eigenaar van een bestand, tijdstip van laatste toegang, checksum,... * '''ingebakken compressie''', transparant voor de eindgebruiker. Zonder ingebakken compressie kan de eindgebruiker ook bepaalde bestanden comprimeren, maar dan moet hij/zij gebruikmaken van een apart programma (bv. WinZip of 7-zip) en zelf instaan voor het decomprimeren (om de data te kunnen bekijken/bewerken) en terug comprimeren. Afhankelijk van de implementatie kan het zijn dat bij deze "ingebakken compressie" niet alles wordt gecomprimeerd, maar bv. enkel bestanden die een lange tijd niet gebruikt zijn geweest. * '''quota''': een beheerder kan een maximum schijfruimte opgeven die door een gebruiker mag ingenomen worden. Stel je een omgeving voor met meerdere gebruikers, waarbij er eigenlijk nog 500 GB vrij is. Dan zou één gebruiker in zijn persoonlijke map 500 GB plaatsen, waardoor iedereen plots een tekort aan schijfruimte heeft. De administrator zou echter a.d.h.v. quota kunnen instellen dat iedere gebruiker maar 200 MB maximaal kan gebruiken. * '''ingebakken ~~encryptie~~compressie''', transparant voor de eindgebruiker. ~~(en:~~Afhankelijk ~~[[w:en:Filesystem-level~~van ~~encryption\|filesystem-level~~de ~~encryption]])~~implementatie kan het zijn dat bij deze "ingebakken compressie" niet alles wordt gecomprimeerd, maar bv. enkel bestanden die een lange tijd niet gebruikt zijn geweest. Zonder ingebakken ~~encryptie~~compressie kan de eindgebruiker ook bepaalde bestanden ~~encrypteren~~comprimeren, maar dan moet hij/zij gebruikmaken van een apart programma (bv. WinZip of 7-zip) en zelf instaan voor het ~~decrypteren~~decomprimeren (om de data te kunnen bekijken/bewerken) en terug ~~encrypteren~~comprimeren. Als dit ingebakken zit in het bestandssysteem, kan het besturingssysteem bv. bij het inloggen (via login+wachtwoord) alles op de achtergrond decrypteren en bij het afmelden terug encrypteren. Bij een gestolen laptop/pc ziet de dief dan enkel de geëncrypteerde data (in de veronderstelling dat je uitgelogd bent). * '''ingebakken encryptie''', transparant voor de eindgebruiker (en: [[w:en:Filesystem-level encryption\|filesystem-level encryption]]). Als dit ingebakken zit in het bestandssysteem, kan het besturingssysteem bv. bij het inloggen (via login+wachtwoord) alles op de achtergrond decrypteren en bij het afmelden terug encrypteren. Bij een gestolen laptop/pc ziet de dief dan enkel de geëncrypteerde data (in de veronderstelling dat je uitgelogd bent). Zonder ingebakken encryptie kan de eindgebruiker ook bepaalde bestanden encrypteren, maar dan moet hij/zij gebruikmaken van een apart programma en zelf instaan voor het decrypteren (om de data te kunnen bekijken/bewerken) en terug encrypteren. * '''journaling''': een bestandssysteem dat dit ondersteunt zorgt voor een soort van log (een ''journal''), die alle wijzigingen bijhoudt, vóórdat ze worden uitgevoerd op het eigenlijk bestandssysteem. In het geval van een systeemcrash of elektriciteitspanne, zullen deze bestandssystemen sneller terug beschikbaar zijn en is er minder kans dat ze corrupt komen. NTFS en ext4 zijn bestandssystemen dit dit ondersteunen, terwijl FAT32 dit niet ondersteunt. * ...<ref>De "next gen" bestandssystemen zoals btfrs en ZFS bieden nog meer mogelijkheden. Zie bv. een diepgaand artikel op Arstechnica: [http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ Bitrot and atomic COWs: Inside “next-gen” filesystems]</ref>

Computersystemen/Opslagbeheer: verschil tussen versies