Du er klar over at Archive diskene er meget uegnede til NAS brug? De bruger Shingled Magnetic Recording, og både performer dårligt, og kan ikke holde til at køre i en NAS i et RAID array.
--
Whatever

#1 du tager fejl. Der var en tråd om dette for nogle uger siden.
--
-- Drifter og udvikler 24/7 Datacenter operations om dagen, er supermand om aftenen.

#1 Min nas kører med unRAID ( http://lime-technology.com[...] ) og de er perfekte til det formål.
--
Thomas

#1: Link? Jeg kan ikke finde noget der bekræfter din påstand, hverken på hol elller andre steder. #3: Okay. Jeg kender ikke unRaid. Har lige tjekket linket ud, men kan ikke se noget der retfærdiggør at SHR diske skulle være velegnede til unRaid. Jeg ville bare advare dig for alt hvad jeg har læst om SHR er at de performer forfærdeligt i RAID, og dem der har forsøgt sig er endt op med defekte diske og korrupte data efter kort tid. Når man ser hvordan SHR fungerer, så forstår man også godt hvorfor. Men hvis der er en særlig applikation du anvender, hvor de er egnede, så er det jo fint.
--
Whatever

#4 Min påstand? ørh,... Jeg har brugt diskene i erhvervssammenhæng og har set at de er stabile og leverer ved den rate de er specificeret til, hvad er det for en påstand du læser ind i hvad jeg skriver? Stroyer herinde kan også fortælle dig at du tager fejl. http://www.hardwareonline.dk[...] Mængden af fail i dit indslag er ret højt. Diskene dør ikke af at blive brugt, du må gerne poste noget link til en god stor sample der viser andet. SMR disken har brug for tid til at skrive data i SMR formatet, hvorfor de bliver langsomme når non-smr området er fyldt op og de data skal flyttes til SMR område.
--
-- Drifter og udvikler 24/7 Datacenter operations om dagen, er supermand om aftenen.
--

Sidst redigeret 07-05-2016 15:24

#5: Du skrev blot at jeg tog fejl. Af du udledte jeg at du mener at mine to postulater var forkerte. Altså at de performer dårligt ved skrivning(det medgiver du selv at de gør, så snart SMR området skal skrives til. Og dernæst skrev jeg at de dør tidligt i raid arrays. Det afhænger selvfølgelig af brugsmønsteret. Jeg har ikke set en stor datamængde fra f.eks backblaze der understøtter dette. Men der er en her der har haft problemer i hvert fald: https://www.youtube.com[...] Igen, det giver mening, da skrivning af en lille datamængde til drevets SMR område vil kræve genskrivning af et stort område på disken, hvilket selvfølgelig giver øget slidtage på drevet. Desuden har de ikke TLER support, og alene af den grund ville jeg fravælge dem til RAID. Seagate angiver heller ikke selv at de er egnet til hverken RAID eller NAS brug. Jeg betvivler ikke at de lever op til specifikationerne. Det skal de nok gøre. Men lad os nu ikke mudre tråden mere til, det var egentlig en købstråd. Mit indlæg var kun ment som en hjælp til OP, hvis ikke han kendte til begrænsingerne og ulemperne ved SMR drev. Men det lader han til at gøre, og så er det jo fint.
--
Whatever
--

Sidst redigeret 07-05-2016 15:52

#4 unRAID er ikke som et traditionelt raid array ( https://lime-technology.com[...] ) Der er mange brugere der har rapporteret at de i et unRAID setup performer på lige fod med f.eks. WD Red. Du kan læse om det her: http://lime-technology.com[...] "The speeds I saw from the Seagate drives were exactly as I had hoped. Personally I saw no difference between the speeds I have obtained using these drives using Unraid and the speeds I have seen using WD Red’s using Unraid. This makes me very happy. I think that whatever Seagate has done to mitigate the SMR technology it has been done excellently and it mitigates any observable write penalty we have been discussing and speculating about. All in all - whether you've got your Unraid Array filled with Large (~5GB to ~40GB), Medium (~400MB to ~4GB) or Small (<=215KB) Files then I have observed and now reasonably expect this Seagate 8TB SMR drive to behave on Par with the WD Red PMR drives I have in my Main Server. Based on my testing and observations I believe these are Excellent Drives which I would recommend for anyone using Unraid in a way that I (and I believe allot of others in the community) do. That goes for use as an Data or Parity Drive. I will certainly be putting these drives in my Main Server as well as my Backup Server now. And will do so without fear. It had been suggested to see the impact of a full persistent cache, disabling the drives write cache with hdparm would be worthwhile BUT I don't see the need to do that now. What I wanted to see is if during real world use I would experience any degraded performance from my WD Red PMR drives in normal use in an Unraid environment and I clearly have NOT experienced any of that."
--
Thomas

Det afhænger selvfølgelig af brugsmønsteret. Præcist. Dvs. hvis manden bare leecher film til en ssd disk, og flytter over på sine archive diske løbende så er der ikke et problem...? Den primære grund til at folk ikke anbefaler dem til raid setups er - correct me if im wrong please - den latterligt lange rebuild tid der er på et array af SMR diske. Jeg har selv 3 af dem kørende i raid5 for at teste lidt. Opbygningen af raidet tog pænt lang tid. Jeg tænker at hvis man bruger dem til raid, så er man også klar til at tage konsekvenserne af det :) -- jeg køber selv red diske fremover i stedet for archive.. men primært fordi det sgu er lidt for spændende under et rebuild :)
--
:)

#7: Nu har jeg læst om unRaid. Det adskiller sig primært fra traditionelle arrays ved at have en cache uden paritet. Det er snedigt nok, da man så kan skrive en fil hurtigt, og så kan unRaid systemet stå og tygge på at beregne paritet når den får tid. Men unRaid er jo underliggende stadig mere eller mindre et traditionelt RAID5 array, med XOR paritet. Det er i hvert fald det jeg får ud af at læse deres beskrivelse. Derfor vil der stadig være stor slidtage på SMR diske, pga genskrivning af store områder. Og de vil stadig være meget længe om at genopbygge et array fra paritet, med dertilhørende høj risiko for at endnu en disk dør imens genopbygningen står på. Og når diskene ikke understøtter TLER, er det i mine øjne helt galt. På trods af brugerrapporter om udmærket performance i unRaid, så ville jeg ikke bruge dem. #8: Lige præcis, og jo længere rebuild tiden er, jo større er risikoen for at disk nr 2 dør, inden arrayet er rekonstrueret. Jeg forstår godt at fysikkens love er ved at presse harddisk producenterne, og at det kræver kreative løsninger fortsat at lave større diske. Men SMR synes jeg er noget skrammel, for at sige det mildt, med mindre det er til helt specifikke opgaver.
--
Whatever

#9 unRaid ændrer sig for tiden: https://lime-technology.com[...]
--
-- Drifter og udvikler 24/7 Datacenter operations om dagen, er supermand om aftenen.

#9: unRAID er IKKE RAID... RAID5 er block level paritet med striping. Med unRAID ligger hvert enkelt fil helt på samme disk. Meget stor forskel, der gør, at diskene fungerer helt som alm. diske - med dertilhørende performance tab ift. RAID.
--
MB: ASUS Z77 Sabertooth | CPU: i7 2600K | GPU: GTX 970 | RAM: 16GB 1866MHz | CASE: Silencio 550 | SSD: Samsung 840

#11 interessant. Havde ikke lige kunne finde den klare forskel på raid5 software mod Unraid, så alt i alt er unraid bare JBOD + parity + cache ( hvilket også kunne opnås med eksempelvis LSI CacheCade )
--

#12 Ja unRaid er jbod + paritet + cache. og til et hjemme setup virker det faktisk ret godt. (LSI's Cachecade kan ikke accelerere et jbod setup hvis jeg husker korrekt, kun et 'rigtigt' array)
--
-- Drifter og udvikler 24/7 Datacenter operations om dagen, er supermand om aftenen.

#12: Pretty much. Cachen er dog en write-cache i unRAID. Jeg ved ikke hvor meget, der er at vinde ved at have en read cache på et JBOD array. Det kræver jo ligesom, at man tilgår det samme data mere end én gang. Altså ikke så brugbart hvis man serverer film til sin Plex*. *Medmindre man har børn, der vil se Frozen 14 gange om dagen
--
MB: ASUS Z77 Sabertooth | CPU: i7 2600K | GPU: GTX 970 | RAM: 16GB 1866MHz | CASE: Silencio 550 | SSD: Samsung 840

#10: Dobbelt paritetsdisk? Det læste jeg godt tidligere. Men, det kan man jo også opnå med RAID6 (distribueret dobbelt paritet). #11: Well, ja. Men problematikken er nu stadig den samme, selv om data ligger isoleret på de enkelte diske, og en enkelt (evt to) diske dedikeret til paritet. SMR diske er stadig lige så uegnede til unRaid, som de er til alle andre former for Raid (og jo, unRaid er raid - Et redundant disk array). unRaid kan kun kompensere i nogen grad for SMRs dårlige performance for skrivning, i tilfælde af rebuild af arrays, og den generelle øgede mekaniske slidtage ved skrivning pga SMR, der kan jeg ikke se at unRaid har nogen fordele frem for traditionel Raid. Jeg mener stadig at SMR kun bør anvendes til det de markedsføres til af producenten. Altså cold storage, enkel sekventiel skrivning af ikke kritiske data, og derefter hovedsagligt læsning.
--
Whatever

#15 Nej... bit'sene til en data disk i unraid bliver skrevet ligesom data til en hvilkensom helst anden 'normal' disk og er derfor ikke plaget af det 'raid write hole' som du formentligt har læst om. Der hvor en SMR disk i et unRaid setup kan være uhensigstmæssig, er hvis du skal rebuilde en paritets disk, her vil du skulle skrive en hel disk i éen køre og der vil den så gå ned i hastighed. Disken hverken dør, går i stå eller oplever andre end-of-life events. De SMR drev har en workload rating, den dækker både read and write. De er ikke WORM drev by any stretch of the imagination. De har 20 GB normal plads at gøre med, så længe de ikke skriver mere data til drevet af gangen end det og herefter accepterer at de skal køre mirgrere data ud til SMR delen, med tilhørende tab i performance. Så kan du bruge de drev som du vil. I et SOHO NAS vil de fungere absolut fremragende (indsæt selv use-case klausul her). Jeg tror ikke jeg forstår hvorfor du holder fast ved at de ikke kan bruges i et RAID setup. I've done it, others have done it. og hvis man kender fordele og begrænsningerne ved de drev... Jeg kan ikke se problemet ? Og ja, unRaid har dobbelt paritet på vej... hvis ellers de så kunne lave read cache på noget spejlet SSD så var de pludseligt helt rå i min bog :) Det er korrekt at du kan opnå 'det samme' på RAID6.. except. mend unraid kan jeg tage en disk ud af mit array og rent faktisk læse data. good luck with that on raid 6. unraid koster 400 kroner. en RAID6 controller koster 4000,-
--
-- Drifter og udvikler 24/7 Datacenter operations om dagen, er supermand om aftenen.

#15: Jeg er både enig og uenig. unRAID er ikke RAID. Hver enkelt disk er uafhængig af de andre. Der er meget store forskelle på block level striping og bare at smide nogle filer på diske i JBOD. Men ja, SMR diske er ikke gode til høj IO. Men i kraft af at man har en SSD write cache og nok næppe skriver ret meget til en hjemme-NAS, ser jeg det ikke som et kæmpe problem. Hvis man ville have høj throughput, ville man nok ikke vælge unRAID til at starte med. Forstå mig ret, jeg ville aldrig selv vælge unRAID, men jeg kan godt se, hvorfor nogle vælger denne løsning.
--
MB: ASUS Z77 Sabertooth | CPU: i7 2600K | GPU: GTX 970 | RAM: 16GB 1866MHz | CASE: Silencio 550 | SSD: Samsung 840