Bericht door: Pistole op 04 januari 2017, 20:52:21
Nu geeft Synology aan dat in 6.1 beta en RC er diverse verbeteringen zijn doorgevoerd in BTRFS.
Kan iemand mij zeggen of BTRFS nu beter presteert. Als dit zo is wil ik namelijk opnieuw overstappen naar BTRFS.
Bericht door: aliazzz op 04 januari 2017, 22:52:26
Ik heb ooit EXT4 gedraaid, maar maar gebruik in sinds het vroege begin BTRFS. Een early adopter dus.
Ik moet zeggen dat ik op mijn NAS nagenoeg geen snelheidsvertraging heb opgemerkt.
Wel is het zo dat de effectieve opslag bij BTRFS gebruik iets lager ligt;
12TB Raid5 SHR2 EXT4 => 9TB maar ongeveer 8,2 effectief!
12TB Raid5 SHR2 BTRFS => 9TB maar ongeveer 7,8 effectief!
BTRFS geeft dus iets minder schijfruimte effectief, MAAR...
Backups en schaduwkopieen of clones van directories kosten in EXT4 exorbitant meer schijfruimte dan met BTRFS.
Dit komt doordat EXT4 per file een 1 op 1 kopie moet bijhouden in een database, terwijl bij BTRFS alleen de metadata en de wijziging wordt opgeslagen.
Dit resulteert bij gebruik van BTRFS in combinatie met elk synology backup pakket, zoals cloudstation en hyper backup tot zeer fijne voordelen!Ten eerste staat je NAS niet elke file 1 op 1 op te slaan, en in mij mijn geval ook niet over het extranet heen te pompen.
BTRFS snijd in die gevallen heel fijn. Ik heb met interne backups maken van mijn LUN'S nooit snelheids problemen gezien. Of de NAS nou 200MByte/s of 220MByte/s wegschrijft is helemaal niet interessant gezien de "compressie" die gehaald wordt bij het wegschrijven van de files middels BTRFS.
Zowiezo gebruik ik mijn NAS voor backup doeleinden en die 1 Gb netwerkverkeer (of 2 bij bonding) is niet interessant. Die NAS houdt dat met of zonder BTRFS echt wel bij. Ofwel, BTRFS is interessant vanuit het oogpunt van backups en kan geen kwaad bij bijvoorbeeld multimedia opslag.
Bericht door: Lampje op 05 januari 2017, 19:59:20
Zeker na het lezen van het volgende bericht op Hardware.info
https://nl.hardware.info/nieuws/48883/btrfs-onveilig-dataverlies-mogelijk-bij-nasen-netgear-synology-en-thecus
Bericht door: Pistole op 05 januari 2017, 20:04:04
Ik heb er gelukkig wel een ups tussen zitten en maak regelmatig backups.
Bericht door: aliazzz op 05 januari 2017, 21:01:10
Dat bericht is eerder afgedaan als komkommertijd kwatsch, je moet alle info van hardwareinfo.nl met een pallet zout nemen zoals velen op dit forum inmiddels al weten. Heb je uberhaupt de comentaren eronder gelezen? Die maken ook gehakt van het artikel en terecht!
Niets aan de hand en gewoon BTRFS gebruiken, synology heeft immers een naam hoog te houden en heeft BTRFS inmiddels als standaard filesystem keuze gemaakt. Dat komt NIET uit de lucht vallen. Nogmaals, ik gebruik zelf dagelijk met veel plezier en profijt BTRFS en kan het je aanbevelen!
Bericht door: Pistole op 06 januari 2017, 12:26:10
Vanmorgen was het geheugengebruik normaal en de restore klaar.
Ik constateerde gelijk al in Surveillance Station dat BTRFS nu wel gewoon snel was en zag geen performance verschil met EXt4. Dit was wel zo toen ik het in Firmware 6.0 ging gebruiken en ook de reden dat ik terug was gegaan naar EXT4.
Ook het kopiëren van bestanden gaat nu veel sneller als toen.
Ik denk dus te constateren (misschien nog wat vroeg) dat BTRFS een stuk sneller is geworden.
Bericht door: aliazzz op 06 januari 2017, 13:21:27
De echte tijdswinst zit hem in pas in backup nr 2 t/m n. Immers de allereerste backup bestaat uit zeer veel metadata.
Tevens is het te bacckuppen deel ook afhankelijk van alle tussentijdse mutaties tussen de twee tijdstippen in, meer wijzigingen is meer opslaan!
Veel belangrijker is de grote van je backup ( de wijzigingen tussen snapshot a en b) en daarme afhankelijk van waar je de file wilt opslaan, lokaal, via netwerk andere NAs of remote via WAN daaruit voortvloeiend als afgeleide de snelheid.
Maak anders zo nog een 1 of meerdere backups via backup now in hyperbackup. Kijk daarna, als je meerdere restorepoints hebt, maar eens via de backup explorer en dan zie ja wat ik bedoel, laat je bevindingen anders even weten.
Bericht door: Pistole op 06 januari 2017, 13:28:09
In de eerste BTRFS versie in firmware 6.0 merkte ik bv in SS dat als een camera moest gaan schrijven of als je de beelden terug wilde kijken er de eerste seconden niks gebeurde. Hij schreef dan de beelden ook niet weg. Beetje vervelend als je datgene wat de trigger voor de bewegingsdetectie veroorzaakte niet kan zien. Dat is nu weg.
Bericht door: aliazzz op 06 januari 2017, 13:37:56
Ik had veel films op mijn NAS staan, en van de ene op de andere dag gooide ik 30 films weg.
Gevolg? het eerstvolgende snapshot was alsnog dik 60GB extra t.o.v. het vorige snapshot...
Als eerste reactie had ik zoiets van pardon? Ik gooi die films toch weg? Dus instinctief denk je dat de data verdwijnt. Niets is minder waar natuurlijk. De backup wijzigt ook + 60GB. Ik kan de weggegooide films dus nog restoren uit het desbetreffende snapshot. De snapshot van de dag erop was nog geen gigabyte groot. Ofwel, de grote van de backup is gekoppeld aan de grootte van de wijzigingen. Deleten veroorzaakt een grotere opslag wijziging dan een file aanpassing, hier ontkom je ook met BTRFS niet aan natuurlijk. Maar hoe vaak gooi je files weg t.o.v. Het aanpassen ervan? Tsja dat is afhankelijk van het gebruik.
Bericht door: Pistole op 08 januari 2017, 10:22:33
Ik ben nu dik tevreden over BTRFS. Systeem voelt net zo snel als met Ext4. Blijkbaar heeft Synology BTRFS een stuk sneller weten te krijgen sinds Firmware 6.0.
Bericht door: aliazzz op 08 januari 2017, 10:55:33
Bovendien... Snelheid is een afgeleide van bandbreedte en filesize. Maarrr ik ben blij dat je de voordelen (er zijn er nog een paar, maar dat ga je vanzelf wel ontdekken ;-) ) ziet.
Bericht door: wopper op 09 januari 2017, 13:42:32
Daarmee lijkt het "ratelen" van de disken weer meer onderdrukt te worden.
Bericht door: Pistole op 09 januari 2017, 13:57:25
Bericht door: Birdy op 09 januari 2017, 14:07:40
Eh...waarom Engels ?
Bericht door: Pistole op 09 januari 2017, 14:12:35
Bericht door: Birdy op 09 januari 2017, 14:42:29
In 6.1RC kan je onder volume beheer ook nog een "record file timestamp moment" (oid) uitschakelen voor meer performance. 6.1 feature zat er mijn weten nog niet.OID ? Bijna goed :lol:
Nederlands: Bestandstoegangstijd registreren.
Engels: Record File Access Time.
Maar goed, wat zijn de consequenties en, wat doet het:
Citaat
De inschakeling van de optie Bestandstoegangstijd registreren is equivalent aan de relatime koppelen-optie op Linux-systemen. De bestandstoegangstijd wordt alleen bijgewerkt wanneer de laatste toegangstijd (atime) voor de actueel gewijzigde (mtime) of wijzigingstijd (ctime) ligt.
De toegangstijd wordt ook bijgewerkt wanneer de laatste toegangstijd ouder is dan een dag.
De uitschakeling van de optie Bestandstoegangstijd registreren is equivalent aan de noatime koppelen-optie op Linux-systemen.
De toegangstijd van bestanden en mappen worden niet bijgewerkt waardoor het bestandssysteemgebruik wordt beperkt.
Denk eraan dat bepaalde toepassingen afhankelijk zijn van de correcte werking van de bestandstoegangstijd.
Bron: DSM Help. ;)
Bericht door: Pistole op 09 januari 2017, 14:48:00
Bericht door: Birdy op 09 januari 2017, 15:17:15
Bericht door: Ben(V) op 09 januari 2017, 20:34:24
Lekker filesysteem dat een optie heeft om dat uit te zetten.
Kun je niet meer zien wanneer een bestand voor het laatst gewijzigd is.
Bericht door: wopper op 09 januari 2017, 23:12:44
ivm performance winst. Ik zie mijn ESXi hosts(Linux) nog gewoon de tijden bij de bestanden staan. Dus het zal zo'n vaart niet lopen.
Het zal misschien in een heel specifiek geval niet meer werken? Tot die tijd neem ik deze performance tip van synology over en zullen er meer IOPS van de disken af komen neem ik aan. En dat is altijd handig met een ESXi omgeving erop.
Verzonden vanaf mijn iPhone met Tapatalk
Bericht door: Birdy op 09 januari 2017, 23:15:46
Bericht door: Basalt op 10 januari 2017, 00:20:15
Dat is iha minder interessant maar komt toch vaker voor.
Erik.
Bericht door: Ben(V) op 10 januari 2017, 06:27:41
Bericht door: Basalt op 10 januari 2017, 20:15:38
Zie deze link wat het probleem is met atime en brtfs
https://lwn.net/Articles/499293/
Bericht door: Basalt op 12 januari 2017, 23:18:20
Graag gedaan jongens.
Bericht door: Birdy op 12 januari 2017, 23:25:26
Bericht door: Basalt op 13 januari 2017, 08:48:29
Bericht door: Pistole op 13 januari 2017, 08:53:56
Mij gaat dit technische verhaal een beetje boven de pet, kunnen jullie op basis van dit document een advies geven over het wel dan niet uitzetten van deze optie?
Bericht door: Birdy op 13 januari 2017, 09:07:00
Bericht door: Pistole op 13 januari 2017, 09:14:25
Bericht door: Basalt op 13 januari 2017, 09:32:00
Als ik het goed begrijp wordt na het uitschakelen van deze optie niet meer bijgehouden wanneer een bestand voor het laatst gelezen is.
Dat is meestal ook helemaal niet interessant, als je zelf kijkt dan wil je iha weten wanneer een bestand voor het laatst gewijzigd is.
Als je de optie wel inschakelt dat wordt "relatime" gebruikt, dat wil zeggen dat maximaal 1x per dag de tijd wordt geregistreerd.
Synology waarschuwt
Citaat
Denk eraan dat bepaalde toepassingen afhankelijk zijn van de correcte werking van de bestandstoegangstijd
Er worden in het door mij aangegeven artikel 2 voorbeelden genoemd:
1) Een bepaalde mail client die hiermee bepaalt of een mail gelezen is
-> Hiervoor zou volgens mij een registratie van 1x per dag (relatime) ook al ongeschikt zijn, dus ik neem aan dat dit niet het geval is
2) Een opruimfunctie die hiermee bepaalt of een tijdelijk bestand opgeruimd kan worden
-> Ik zou verwachten dat Synology deze optie niet zou aanbieden als het gevolg is dat je disk daardoor langzaam volloopt.
Maar wellicht zijn er andere voorbeelden die wel van invloed zijn op het Synology systeem of geïnstalleerde pakketten.
Aan de andere kant: het voordeel van het uitschakelen is dat het simpelweg lezen van (zeer veel) bestanden sneller gaat en niet leidt tot nodeloze backups van de bestand administratie. Zolang je daar geen last van hebt is de veiliger om de optie ingeschakeld te laten.
Als iemand aanvullingen/correcties heeft: Graag.
Bericht door: Birdy op 13 januari 2017, 09:44:55
Daarbij, mijn stelling is altijd, heb je geen issues, b.v. performance, waarom zou je dan iets wijzigen en.....eerst meten (is weten), voordat je, zeker m.b.t. performance issues, iets gaat wijzigen en daarna weer meten natuurlijk.