Versie 6.1.2-15132 is uit

[bronan]

Hmm vreemd Briolet dat het zo lang duurt, het valt mij op dat op btrfs alles nu sneller lijkt te gaan.
Of heb je veel bestanden staan in de home mappen ?

Ik betwijfel of het bij mij komt omdat ik 2 intel 60 MB ssd's als cache gebruik dat het bij mij allemaal zo snel gaat.
De update was ook al zo snel klaar, haast vreemd te noemen.

[Briolet]

Ik vind het ook vreemd dat indexeren zo lang duurt. Vooral als ik naar het CPU gebruik kijk:



Ik zie een hoog CPU gebruik tussen 23:30 en 2:30. De begintijd komt ongeveer overeen met de start van het indexeren. Maar dan moet hij na 3 uur al klaar geweest zijn. In de nas staat echter dat hij nog steeds aan het indexeren is. Ik heb het al een keer gepauzeerd en weer gestart. Volgens mij moet hij klaar zijn, maar hangt op de afrondingsprocedure.

[m4v3r1ck]

Dat indexeren is inderdaad een echte aanslag op de prestaties van mijn DS1812+!

Cheers

[Briolet]

Er zit toch ergens een bug. Ik heb een andere share, waar bijna geen tekst op stond, geïndexeert. Hij was daarmee slechts 1 minuut bezig en gaf dan aan dat hij klaar was. Binnen US zie ik dan twee actieve processen. Toen hij klaar was gingen beide processen in de slaapstand.

Echter, het indexeren van mijn home share is volgens de nas nog steeds bezig. Klopt niet, zeker als er geen cpu meer verbruikt wordt en de processen in slaap staan. De hele nas restarten is ook weer zo'n lapmiddel.

[bronan]

Ja ik heb dit ook even nagekeken op een nas (413j) van een kennis en deze doen extreem lang over het indexeren.
Alhoewel ik de indruk had dat na de eerste grote indexering het daarna wat vlotter leek te gaan.
Vervolgens blijkt ook bij hem op zijn macbook het niet echt goed te werken.
Dus de vraag is of beide problemen gerelateerd zijn.
Het is opvallend dat mijn nas zo snel geworden is na de update met veel zaken. Maar goed niet iedereen wil een dikke rackstation in huis hebben .
Het kan niets anders zijn dan de in raid 1 geplaatste ssd's als cache welke veel beter lijken te werken met BTRFS. Ik zie ze veel vaker gebruikt worden als de gebruikers inloggen en aan de slag gaan. Om even een voorbeeld te geven met EXT4 was de maximale belasting van de ssd's ongeveer 56% tegen 87% met BTRFS. Het zou kunnen betekenen en verklaren waarom mensen BTRFS langzamer ervaren want in mijn visie is er blijkbaar veel meer disk activiteit. Uiteraard moet je niet vergeten dat de meeste oudere modellen een sata 1 controller hebben en er alleen in de dure machines sata2 controller zijn gebruikt. Ik zag dat in de 2017 serie modellen er nog steeds gebruik word gemaakt van sata2. Wat inhoud dat deze 3 Gbps max performance behalen.
Ik zal later nog even uitzoeken of men inmiddels meer machines maakt met sata3 maar ik vrees dat synology nog steeds ver achter loopt op dat gebied. QNAS en de andere merken zijn vaak al veel langer voorzien van sata3 (6 Gbps) controllers. Het moge duidelijk zijn dat de echt professionele nas/san machines allemaal (sas) 12 Gbps zijn. Het is mij onduidelijk waarom synology nog steeds geen sas gebruikt in de duurste modellen want qua prijs van de schijven zit er niet echt schokkend veel verschil meer tussen de sata en de sas.

[Ben(V)]

BTFRS is een COW(Copy On Write) file system, wat wil zeggen dat bij mutaties van bestanden er alleen de delta wordt weggeschreven en het orgineel blijft bestaan.
Dit levert vooral bij het gebruik van veel kleine bestanden een aanzienlijke extra disk io op en dus zal het effect van een ssd cache veel groter zijn dan een ext filesystem.

Indexeren met een btrfs filesysteem zal veel extra io opleveren want al die indexes moeten opgeslagen worden.

Btfrs veroorzaakt in omgevingen met veel kleine bestanden en veel mutaties slechtere performance op dan ext4 en veroorzaakt ook nog eens extreem veel defragmentatie.
Ook moeten we nog afwachten wat dit voor de levensduur van een ssd gaat betekenen, want zoals je weet kan een ssd een beperkt aantal keren beschreven worden.

Wat betreft de SATA 3, dat is voor de meeste NAS systemen volkomen onzinnig is want alleen een ssd kan daar van profiteren.
Een harddisk systeem kan nooit een SATA 2 controller tot z'n maximum belasten.

En dit alles wordt alleen gebruikt voor zaken die binnen de NAS blijven, want voor alles dat naar buiten moet is het netwerk de bottleneck en het blijft een beetje onzinnig om veel geld voor dure ssd's en sata 3 controllers uit te geven terwijl het doel van een NAS netwerk storage is.
Door de veelzijdigheid van DSM worden ze steeds meer ingezet als een centrale server maar het is natuurlijk gewoon een NAS.

[m4v3r1ck]

Ik heb WD REDs, die zijn wel degelijk SATA-3, dus ik snap niet helemaal waarom alleen een SSD daarvan zou profiteren?


edit: tat reclame weggehaald!

[Robert Koopman]

De schijven misschien wel maar de controller in de NAS ook?

[m4v3r1ck]

In mijn DS1812+ is dat SATA-2, maar mijn vraag was of het juist is dat alleen een SSD kan profiteren van SATA-3?

Cheers

[Ben(V)]

Ze kunnen wel Sata 3 zijn maar de disken zelf hebben een maximale snelheid van iets tussen de 150 en 200 MB/s en Sata 2 is gespecificeerd voor 300MB/s dus meer dan voldoende om een harddisk bij te houden.

Er is geen enkele harddisk die 600 MB/s haalt en alleen SAS schijven zullen misschien die 300MB/s halen maar zelfs dat betwijfel ik.

Alleen ssd's zijn sneller en daar zou een SATA 3 controller zin hebben.

[Robert Koopman]

MB/s bedoel je?

[Ben(V)]

Goed gezien Robert.

Ik heb het aangepast, zit te veel met netwerk snelheden in m'n hoofd die altijd in Mb/s gespecificeerd worden.

[m4v3r1ck]

Oke, helder verhaal @Ben(V)!

Wel raar dat o.a. WD toch SATA-3 controllers in hun REDs stoppen, als deze niet eens de maximale SATA-3 snelheden kunnen halen?

Cheers

[Briolet]

Misschien dat het prijsverschil erg klein is en 3 klinkt beter dan 2 in de marketing. Maar het kan zijn dat de 3 nog andere features, naast snelheid heeft? Ik lees in elk geval iets over NCQ commands voor een betere steaming van video.

[Ben(V)]

NCQ (Native Command Queing) heeft alleen zin in multi user/multi tasking omgevingen en heeft geen tot nauwelijks nut voor video streaming.

Het is een feature waarin het device de command queue in z'n geheel bekijkt en probeert commandos in die queue samen te voegen.
Als bijvoorbeeld een block data nodig voor het eerste commando in de queue en dezelfde data (of deel ervan) voor een ander commando in de queue dan worden die twee commandos gelijktijdig geserviced.

Voor video streaming is dit nauwelijks nuttig lijkt mij.

Verder is willen diskfabrikanten natuurlijk het liefst voor al hun disken dezelfde interface gebruiken want dat is kosten besparend, dus zijn de meeste huidige disken uitgevoerd met een SATA-3 interface.