Om te beginnen: Ik heb er vooralsnog geen ervaring mee, dus voor echte praktijkervaring zou je in het vrij karige
BTRFS topic kunnen kijken/vragen.
(voor praktijkervaring wat betreft BTRFS in het algemeen dan, gezien Synology het pas sinds kort in een Beta versie en enkele onlangs geïntroduceerde modellen heeft toegevoegd.)
Ik heb me er onlangs een beetje in verdiept door onder andere wat Fora/Wiki pagina's/Youtube filmpjes te bekijken, en ben tot de conclusie gekomen dat het toch wel een vereiste is voor mijn volgende NAS. Hierbij moet ik wel gelijk zeggen dat ik me na het lezen van berichten op het Synology forum wat zorgen maak over de implementatie ervan, maar daarover onderaan de post meer..
Een van de voordelen van BTRFS is de snapshot feature, die het mogelijk maakt om behoorlijk snel en efficiënt snapshots van je data te maken.
(simpel gezegd een soort van incrementele backups)
Maar het belangrijkste van BTRFS is imho de fout detectie/correctie; hier heeft CiPHER onlangs nog een duidelijke post over geschreven:
Verwijderd schreef op zaterdag 12 december 2015 @ 16:46:
[...]
Mijn kijk op deze kwestie is dat je twee zaken moet onderscheiden:
- Detectie van corruptie
- Correctie van corruptie
Dit zijn twee heel afzonderlijke zaken die we gescheiden van elkaar moeten beoordelen:
Detectie van corruptie wil zeggen dat de integriteit van alle data en metadata wordt bewaakt door checksums. Als bepaalde (meta)data niet is wat het zou moeten zijn, gaat er een alarmbel rinkelen. Ouderwetse bestandssystemen zoals NTFS, Ext4, HFS en UFS zoals vrijwel alle computersystemen gebruiken bieden totaal geen bescherming tegen corruptie. Ze kunnen geen eens weten als er corruptie optreedt. Ze zullen doodleuk corrupte data aan applicaties leveren en het gemis van detectie van corruptie is simpelweg niet acceptabel. Ik zie dit als lemmings die van een berg aflopen en het ravijn instorten.
Correctie van corruptie wil zeggen dat naast het detecteren dat er corruptie heeft plaatsgevonden, deze ook kan worden hersteld. Bij moderne bestandssystemen van de 3e generatie gebeurt dit volledig automatisch - hier hoef je zelf niets voor te doen. ZFS en Btrfs zullen automatisch schade repareren. Maar om te kunnen repareren moet er wel redundancy beschikbaar zijn - dat wil zeggen dat er meerdere bronnen beschikbaar zijn van de data. Als bron A corrupt is, kan bron B worden gebruikt om naar de applicatie te sturen alsmede bron A te herstellen naar de corruptievrije versie van bron B. Echter, als er geen redundancy beschikbaar is, dus enkel bron A, dan is het niet mogelijk om de corruptie te herstellen. Er is dan enkel detectie mogelijk - dus je weet dat data corrupt is maar je kunt die niet herstellen.
Iedereen focust zich op de mogelijkheden van correctie van corruptie, maar slechts weinigen eerbiedigen de kracht van detectie van corruptie. Mijns inziens is de detectie juist de killer feature van 3e generatie filesystems zoals ZFS en Btrfs. Het begint allemaal met de mogelijkheid te wéten dat er iets mis is. Hoe het opgelost gaat worden is een 2e zaak.
Stel je hebt een niet-redundante opslagpool van een enkele disk of twee disks in RAID0. Dan heb je geen redundancy. Bij ZFS betekent dit dat de metadata nog extra bescherming geniet middels 'ditto blocks' - dat wil zeggen dat ook met een enkele disk of RAID0 - dus zonder redundancy- de metadata nog steeds beschermd is en corruptie niet alleen gedetecteerd maar ook gecorrigeerd kan worden. Dit omdat de metadata dubbel wordt opgeslagen. Dit wordt in ZFS jargon 'ditto blocks' oftewel 'copies=2' genoemd. Dit kan ook voor data ingeschakeld worden, maar dan neemt deze ook twee keer zoveel opslagruimte in beslag. Metadata wordt minimaal twee keer opgeslagen dat is standaard. Metadata is alle gegevens die geen bestanden zijn, dus data van het filesystem zelf. Denk aan directory-structuren, checksums, namen van bestanden, modificatiedata, instellingen, enzovoorts. Als de metadata corrupt is, kunnen hele delen van je filesystem afsterven, dus het is cruciaal om deze extra te beschermen. Gelukkig is dit standaard het geval.
Als je een niet-redundante pool hebt zoals een enkele disk of RAID0, dan heb je dus standaard geen mogelijkheid om de opgeslagen gegevens te herstellen indien corruptie zich voordoet, maar wel de mogelijkheid te wéten dat bestand X corrupt is. Bovendien is het filesystem zelf - de metadata - al extra beveiligd. Dat betekent dat je wel degelijk al veel voordelen hebt boven een legacy filesystem. Zeker als je ook backups gebruikt, betekent dit dat je kunt zien/merken/ervaren dat bestand X corrupt is geworden en dat je als gevolg hiervan je backup aanspreekt en zodoende een oudere versie van het bestand terugzet. Als je goede backups hebt, is detectie het allerbelangrijkst.
Heb je geen backup of is uptime/availability dus de beschikbaarheid van data het meest belangrijk - meestal voor bedrijven - dan is redundancy is een must. Voor Enterprise wordt High Availability veelal ingezet om het falen van een hele pool op te kunnen vangen. Ik focus me meer op de thuisgebruiker, en dan is het equivalent van RAID5 en RAID6 het meest interessant zodra je met meerdere disks werkt.
[...]
* Lang leve autofold 
*
TLDR: Detecteren en melding maken van mogelijke datacorruptie, en het (eventueel) herstellen ervan indien mogelijk.
Onderstaand een paar quotes van een
BTRFS topic van het Synology Forum:
LET OP: Sommige quotes zijn al enkele maanden oud, en bovendien niet gepost door medewerkers van Synology!Bron
We need to ask Support if bitrot can be corrected. If not, this is a major issue, especially since they advertise bitrot correction as one of the main new features!
Send a ticket to Synology, asking them about it!
EDIT: Well here comes the killer news, officially from support: Bitrot-correction is NEITHER PLANNED NOR AVAILABLE RIGHT NOW! What the hell?? Then why advertise it at all? This ist THE thing we need BTRFS for!!
Wat dus zou betekenen dat tijdens de lauch alleen de bitrot DETECTIE maar zou werken, en de correctie dus op zich laat wachten, of helemaal niet geimplementeerd wordt.. De
BTRFS pagina van de Synology website zelf heeft het, als je het goed leest, alleen over metadata correctie, dus ik gok dat data correctie nog niet gelijk ondersteund wordt.
Bron
If you have a volume with btrfs filesystem, the metadata in the filesystem will have two copies and checksum, so that metadata will be corrected if a checksum error happens. Files will have checksum if the option [data integrity protection] is checked, and checksum errors will be logged and reported if they happen.
Information on our website will be corrected soon. Correction of corrupted files is being planned however we cannot have a confirmed schedule yet.
De quote hieronder vat het eigenlijk wel mooi samen, omdat ondanks dat de data
correctie mogelijk zou missen (alleen metadata), de
detectie van fouten toch echt al een groot voordeel is gezien je de getroffen bestanden, indien je een goed backup schema hebt, dan gewoon terug kunt zetten. Dit terwijl je hier zonder BTRFS/ZFS altijd te laat achter komt..
Bron
I've read closely, and a data integrity check is better than no check at all. I'd much rather know that a file was rotten, so that I can restore it from another saved copy, than let bitrot go undetected. Sure it would be great if the Synology could autorepair the damage, and I really hope that comes soon, but as with most problems, early detection is the key. This is an important first step, and a great improvement upon the zero visibility we had before, and therefore something I'll welcome even with the understanding that it's not enough by itself.
Even if the Synology can't recover a good copy of the file, I can. And if I can't, that tells me I need more copies of my data.
Mocht er meer duidelijkheid over komen (door een post van Synology in het topic) dan zal ik het hier wel posten.
Delidded 4770K 4.7GHz @ H220 || Gigabyte Z87X-UD4H || 16GB @ 2400MHz || Gigabyte GTX 760 || 2x128GB Samsung 830 @ RAID-0 & WD 3 TB || Iiyama XB2483HSU-B1 || Synology DS916+ 3x6TB + 120GB SSD Cache || Synology DS213+ 6TB backup
/u/197564/crop6072aa9bcdaaf.png?f=community)
:strip_icc():strip_exif()/u/281581/icon.jpg?f=community){kind=icon}
/u/113293/ferrariavatar2.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/2189/baby.jpg?f=community)
.:strip_icc():strip_exif()/u/856/crop58b5845e39c29_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/68028/crop5c0ef8207f712_cropped.jpeg?f=community)
/u/125712/crop5c1f5b4ca0045_cropped.png?f=community)
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
/u/267531/gta.png?f=community)
:strip_icc():strip_exif()/u/241948/crop58dd1b1aa2aef.jpeg?f=community)
:strip_icc():strip_exif()/u/232052/avatar.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/54764/Ferrari_GoT.jpg?f=community)
:strip_icc():strip_exif()/u/5326/crop5ff8e3fc691c6_cropped.jpeg?f=community)
/u/514575/crop6821ecedd61de_cropped.png?f=community)
:strip_icc():strip_exif()/u/64065/009-60x60.jpg?f=community)
:strip_exif()/u/154471/crop5e09176a82484.gif?f=community)
:strip_icc():strip_exif()/u/6406/Image3.jpg?f=community)
:strip_icc():strip_exif()/u/36753/ironman%25202_close_face60x60.jpg?f=community)
:strip_icc():strip_exif()/u/212073/crop5790930e15fe8_cropped.jpeg?f=community)
:strip_exif()/u/1839/avatar_drome.gif?f=community){kind=avatar}
Dit topic is gesloten.
