:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
/u/8830/crop5df8eadcd55ca_cropped.png?f=community)
Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.
Ja een stuk of 6 per dag met 2 dagen retentie oid (backups, gaat dus niet verder als 2 dagen terug) en vanaf de op een na goedkoopste VPS ook een permanente snapshot.
Stack lijkt leuk maar bigstorage is de betere oplossing, hierbij valt de data ook zeker buiten het internetverkeer.
Daarnaast is een rsync naar offsite toch ook wel fijn (mochten de dijken breken ofzo
)
Bedankt, hulp kan ik zeker gebruiken. Ik stuur je wel even een PM. Wil de backup doen vanuit een FreeNAS jail.:
[...]
Ik gebruik het met duplicity als off-site backup
Als je hulp nodig hebt met duplicity kan ik je misschien wel helpen.
Echter, denk niet dat er ook support komt voor ZFS send/receive. Stack is onderhuids wel ZFS-backed, maar dat betekent niet dat je als gebruiker ook direct bij die laag kunt. Voor gebruikers is het gewoon WebDav...
In dat geval kun je veel ruimte besparen door de files naar /dev/random te symlinken 
Offtopic:
Zonder gekkigheid, aan wat voor toepassing moet ik denken dat je tig TB aan random ruis op wilt slaan? Astronomie?
Offtopic:
Zonder gekkigheid, aan wat voor toepassing moet ik denken dat je tig TB aan random ruis op wilt slaan? Astronomie?
- = Step Into The Pit | Industrial Strength = -
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT VM_TIER_2 476G 172G 304G - 80% 36% 1.78x ONLINE -
Crap, ik moet hier misschien toch iets mee
Even niets...
1.10x
Dedup van de andere pool is veel leuker
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT VM_TIER_1 119G 9.39G 110G - 9% 7% 4.35x ONLINE -
Mwoh, als ik zie hoe (fucking) veel problemen er zijn met BTRFS' Rebalance functie, ben ik stiekem wel blij dat ZFS dat niet heeft.
Oplossing zou zijn om alle VM's te migreren naar mijn tweede VM pool (2 SSD's in mirror) en dan even het filesystem en de lun opnieuw aanmaken.
Maar meh, tijd enzo... Haal nog steeds ~80.000 IOPS via iSCSI, dus merk er weinig van.
[ Voor 12% gewijzigd door FireDrunk op 22-04-2016 17:06 ]
Even niets...
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Na weer een paar van die mini-pc's gesponserd te hebben gekregen ben ik nu aan het testen of ik mijn Hummingboard Base i2eX (Dual Core) 1GB ($ 100,-) kan vervangen door een Hummingboard Pro i4x4 (Quad Core) 4GB ($ 190,-) voor mijn offsite backup.
Het probleem bij de i2eX was dat hij mijn maandelijkse scrub niet overleefde. Rond de 30% kreeg ik telkens I/O errors. Geheel is via USB aangesloten. Het minimaliseren van het aantal snapshots hielp niet. Uitzetten van deduplicatie en compressie ook niet.
Bij i2eX had ik ook nog wat ZFS dingen getuned om met het weinige geheugen om te gaan. Op de i4x4 draai ik alles met zijn default waarden. Nu aan het testen met mijn locale externe backup schijf waar dezelfde info staat als mijn offsite backup schijf, maar dan niet gelimiteerd in het aantal snapshot dat hij mag opslaan en waarop dedup en compressie aan staat. Dus gelijk een flinke test voor het nieuwe systeem.
Scrub draait nog steeds lekker:
Op de i2eX was de doorvoersnelheid nooit hoger dan 1.5M/s. Een scrub duurt dan erg lang:
De i4x4 vraagt wel een hoop meer stroom waardoor ik hem op de powersave governor moet draaien om hem nog aan een USB poort te kunnen hangen.
Voor het geld kan je overigens beter een Intel NUC kopen
Het probleem bij de i2eX was dat hij mijn maandelijkse scrub niet overleefde. Rond de 30% kreeg ik telkens I/O errors. Geheel is via USB aangesloten. Het minimaliseren van het aantal snapshots hielp niet. Uitzetten van deduplicatie en compressie ook niet.
Bij i2eX had ik ook nog wat ZFS dingen getuned om met het weinige geheugen om te gaan. Op de i4x4 draai ik alles met zijn default waarden. Nu aan het testen met mijn locale externe backup schijf waar dezelfde info staat als mijn offsite backup schijf, maar dan niet gelimiteerd in het aantal snapshot dat hij mag opslaan en waarop dedup en compressie aan staat. Dus gelijk een flinke test voor het nieuwe systeem.
Scrub draait nog steeds lekker:
code:
1
2
3
| . scan: scrub in progress since Sun Apr 24 14:28:19 2016
53.0G scanned out of 727G at 6.07M/s, 31h34m to go
0 repaired, 7.30% done |
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| top - 17:15:34 up 2:53, 2 users, load average: 2.90, 3.04, 3.15 Tasks: 214 total, 1 running, 213 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 27.8 sy, 0.0 ni, 65.1 id, 2.0 wa, 2.4 hi, 2.7 si, 0.0 st %Cpu1 : 0.0 us, 21.6 sy, 0.0 ni, 71.8 id, 5.0 wa, 1.7 hi, 0.0 si, 0.0 st %Cpu2 : 0.0 us, 24.7 sy, 0.0 ni, 72.0 id, 1.7 wa, 0.3 hi, 1.3 si, 0.0 st %Cpu3 : 0.7 us, 39.8 sy, 0.0 ni, 58.2 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st KiB Mem: 3883224 total, 818992 used, 3064232 free, 3836 buffers KiB Swap: 250876 total, 0 used, 250876 free. 197212 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 416 root 0 -20 0 0 0 S 30.0 0.0 20:21.93 spl_kmem_cache 1924 root 0 -20 0 0 0 S 20.5 0.0 30:40.86 z_rd_int_4 1922 root 0 -20 0 0 0 S 19.2 0.0 30:30.89 z_rd_int_2 1927 root 0 -20 0 0 0 S 15.7 0.0 30:30.03 z_rd_int_7 1919 root 0 -20 0 0 0 S 6.2 0.0 4:58.80 z_rd_iss 167 root 20 0 0 0 0 D 4.6 0.0 7:31.66 usb-storage 1967 root 20 0 0 0 0 D 2.3 0.0 4:29.64 txg_sync |
code:
1
2
3
4
| . total used free shared buffers cached Mem: 3792 799 2992 0 3 192 -/+ buffers/cache: 603 3188 Swap: 244 0 244 |
Op de i2eX was de doorvoersnelheid nooit hoger dan 1.5M/s. Een scrub duurt dan erg lang:
code:
1
| scan: scrub repaired 0 in 179h24m with 0 errors on Sun Apr 24 14:24:29 2016 |
De i4x4 vraagt wel een hoop meer stroom waardoor ik hem op de powersave governor moet draaien om hem nog aan een USB poort te kunnen hangen.
Voor het geld kan je overigens beter een Intel NUC kopen
| # | Product | Prijs | Subtotaal |
| 1 | Intel NUC NUC5CPYH | € 127,95 | € 127,95 |
| 1 | Team Group TMD3L8G1333HC9-S01 | € 24,95 | € 24,95 |
| 1 | Transcend HSD370 16GB | € 24,47 | € 24,47 |
| Bekijk collectie Importeer producten | Totaal | € 177,37 | |
[ Voor 53% gewijzigd door CurlyMo op 24-04-2016 17:24 ]
Sinds de 2 dagen regel reageer ik hier niet meer
:strip_icc():strip_exif()/u/101865/crop5e04c97889698_cropped.jpeg?f=community)
Ik begreep dat de -F ervoor zorgde dat de receiver desnoods een rollback doet naar de laatste snapshot als ze niet overeenkomen. Dat lijkt ook goed te werken als ik eens een snapshot op de receiver maak en dan weer van de originele een incremental stuur. De receiver verwijderd zijn eigen gemaakte snapshot en de bol is weer in lijn met elkaar. Aan de hoeveelheid netwerk verkeer te zien stuurt ie niet de hele snapshot over.
Met individuele snapshots moet ik er aan denken dat ik de nieuwe datasets in de backuplijst plaats....en dat vergeet ik nog wel eens ..(ik word ook een dagje ouder )
Met individuele snapshots moet ik er aan denken dat ik de nieuwe datasets in de backuplijst plaats....en dat vergeet ik nog wel eens ..(ik word ook een dagje ouder
)
Ik heb mijn FreeNAS machine na een blikseminslag een tijd niet gebruikt. De machine is een maand geleden ge-upgrade naar FreeNAS 9.3, toen klapte hij eruit tijdens een scrub inmiddels heb ik alle hardware twee x getest en een brakke voeding vervangen.
Nu draait de machine weer ik liep alleen tegen wat zaken aan waar ik toch wat vragen aan over heb gehouden.
De data op deze machine is verder niet van belang maar mijn basic understanding van ZFS is weer een weggezakt dus het weer in de lucht krijgen van deze machine leek me een leuke praktijk oefening.
De oudste en primary pool is een raidz van 3x 2TB WD green power schijven, deze pool gaat al een aantal iteraties van het systeem mee. Na het initieel opstarten van de machine was deze pool niet gemount want er miste een schijf:
Ooit heb ik een 64GB als volgens mij L2ARC gekoppeld aan deze pool en blijkbaar was deze SSD niet beschikbaar waardoor de pool niet gemount kon worden. Alle drie de western digital schijven waren wel present, ik was in de veronderstelling dat een pool met een ontbrekende L2ARC wel te mounten is?
De -m switch bij een import is voor ontbrekende ZIL?
Na het vervangen van een S-ATA kabel was de SSD weer beschikbaar, echter kon ik de pool nog niet mounten. Uiteindelijk heb ik via de FreeNAS Gui een detach gedaan, vervolgens een reboot en toen een zpool import TANK welke wel succesvol was.
Zie ik het goed dat de SSD eigenlijk als single disk vdev is opgenomen in de pool TANK?
Om dit te herstellen moet ik de pool vernietigen en vervolgens opnieuw opbouwen lijkt mij.
Wat is de makkelijkste manier om te achterhalen of de SSD als SLOG of L2ARC is ingezet?
Nu viel mij op dat de SSD via een id gekoppeld is in plaats van een custom label, de labels kan ik natuurlijk meteen rechttrekken als ik een nieuwe pool moet opbouwen maar de vraag is wat is nu de beste methode?
Ik zag dat iemand hier de serienummers van zijn disks opnam in het label, dat wil ik ook gaan doen.
Wat was de reden dat disk voorzien van een GPT label en dan volledig toekennen aan een pool niet verstandig was, partitielabels genieten de voorkeur geloof ik?
Nu draait de machine weer ik liep alleen tegen wat zaken aan waar ik toch wat vragen aan over heb gehouden.
De data op deze machine is verder niet van belang maar mijn basic understanding van ZFS is weer een weggezakt dus het weer in de lucht krijgen van deze machine leek me een leuke praktijk oefening
. De oudste en primary pool is een raidz van 3x 2TB WD green power schijven, deze pool gaat al een aantal iteraties van het systeem mee. Na het initieel opstarten van de machine was deze pool niet gemount want er miste een schijf:
zpool import
pool: TANK
id: 8931747936348276010
state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing
devices and try again.
see: http://illumos.org/msg/ZFS-8000-6X
config:
TANK UNAVAIL missing device
raidz1-0 ONLINE
gpt/2TB-WD03 ONLINE
gpt/2TB-WD02 ONLINE
gpt/2TB-WD01 ONLINE
Additional devices are known to be part of this pool, though their
exact configuration cannot be determined.
Ooit heb ik een 64GB als volgens mij L2ARC gekoppeld aan deze pool en blijkbaar was deze SSD niet beschikbaar waardoor de pool niet gemount kon worden. Alle drie de western digital schijven waren wel present, ik was in de veronderstelling dat een pool met een ontbrekende L2ARC wel te mounten is?
De -m switch bij een import is voor ontbrekende ZIL?
Na het vervangen van een S-ATA kabel was de SSD weer beschikbaar, echter kon ik de pool nog niet mounten. Uiteindelijk heb ik via de FreeNAS Gui een detach gedaan, vervolgens een reboot en toen een zpool import TANK welke wel succesvol was.
# zpool status TANK
pool: TANK
state: ONLINE
status: The pool is formatted using a legacy on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on software that does not support feature
flags.
scan: scrub in progress since Sun Jan 31 11:11:39 2016
2.02T scanned out of 4.18T at 160M/s, 3h55m to go
0 repaired, 48.29% done
config:
NAME STATE READ WRITE CKSUM
TANK ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gpt/2TB-WD03 ONLINE 0 0 0
gpt/2TB-WD02 ONLINE 0 0 0
gpt/2TB-WD01 ONLINE 0 0 0
gptid/23773e95-26f0-11e3-9192-485b3980e661 ONLINE 0 0 0
errors: No known data errors
Zie ik het goed dat de SSD eigenlijk als single disk vdev is opgenomen in de pool TANK?
Om dit te herstellen moet ik de pool vernietigen en vervolgens opnieuw opbouwen lijkt mij.
Wat is de makkelijkste manier om te achterhalen of de SSD als SLOG of L2ARC is ingezet?
Nu viel mij op dat de SSD via een id gekoppeld is in plaats van een custom label, de labels kan ik natuurlijk meteen rechttrekken als ik een nieuwe pool moet opbouwen maar de vraag is wat is nu de beste methode?
Ik zag dat iemand hier de serienummers van zijn disks opnam in het label, dat wil ik ook gaan doen.
Wat was de reden dat disk voorzien van een GPT label en dan volledig toekennen aan een pool niet verstandig was, partitielabels genieten de voorkeur geloof ik?
Oke thanks, ga even kijken naar partitie labels in FreeBSD.
Moet de pool toch opnieuw opbouwen want op dit moment bestaat de pool uit een stripe en een raidz vdev.
Ik heb onder Linux wel eens een zpool gebouwd op basis van /dev/disk/by-partlabel, nu weet ik niet meer precies waarom. Bij FreeBSD kan ik gewoon de disk initialiseren met GPT, daarna een ZFS partitie aanmaken en dan de pool bouwen op basis van /dev/gpt/<gpt-labels>?
Moet de pool toch opnieuw opbouwen want op dit moment bestaat de pool uit een stripe en een raidz vdev
.Ik heb onder Linux wel eens een zpool gebouwd op basis van /dev/disk/by-partlabel, nu weet ik niet meer precies waarom. Bij FreeBSD kan ik gewoon de disk initialiseren met GPT, daarna een ZFS partitie aanmaken en dan de pool bouwen op basis van /dev/gpt/<gpt-labels>?
[ Voor 44% gewijzigd door dutch_warrior op 27-04-2016 15:13 ]
/u/62673/crop56e2e8ee04df2_cropped.png?f=community)
/u/11437/wandcontactdoos.png?f=community)
Je wil de hele pool afbreken en met 2 schijven opnieuw beginnen? Dan zou ik inderdaad een mirror maken
"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock
/u/274737/1424346450_beer_.png?f=community)
FreeNAS overgenomen door een bedrijf? FreeNAS is al jaaaaren van ixSystems? FreeNAS is al jaren een betaald product, alleen heeft dat de naam TrueNAS... Daar is de afgelopen jaren weinig in veranderd.
ixSystems is juist toonaangevend als het gaat om de manier waarop ze Open Source ontwikkelingen stimuleren maar toch hun geld kunnen verdienen door goed support te verkopen.
Nexenta(Stor) en Napp-It zijn leuke ontwikkelingen, maar bedenk wel dat die ten grondslag liggen aan (Open)Solaris. Als je dacht dat FreeBSD exostisch was, berg je dan maar voor Solaris
NAS4Free is net zo open source als FreeNAS, het is een illusie dat het beter is.
Nogmaals: FreeNAS is gratis en Open Source, en wordt echt niet zomaar ongedaan gemaakt, die strategie is al heel lang ongewijzigd.
tl;dr; Gewoon voor FreeNAS gaan, dat is een prima, veilige, en stabiele keuze.
Mocht je de broncode zoeken: staat gewoon hier -> https://github.com/freenas/freenas
ixSystems is juist toonaangevend als het gaat om de manier waarop ze Open Source ontwikkelingen stimuleren maar toch hun geld kunnen verdienen door goed support te verkopen.
Nexenta(Stor) en Napp-It zijn leuke ontwikkelingen, maar bedenk wel dat die ten grondslag liggen aan (Open)Solaris. Als je dacht dat FreeBSD exostisch was, berg je dan maar voor Solaris
NAS4Free is net zo open source als FreeNAS, het is een illusie dat het beter is.
Nogmaals: FreeNAS is gratis en Open Source, en wordt echt niet zomaar ongedaan gemaakt, die strategie is al heel lang ongewijzigd.
tl;dr; Gewoon voor FreeNAS gaan, dat is een prima, veilige, en stabiele keuze.
Mocht je de broncode zoeken: staat gewoon hier -> https://github.com/freenas/freenas
[ Voor 4% gewijzigd door FireDrunk op 17-05-2016 09:59 ]
Even niets...
Helder, dan ga ik toch eens met Freenas spelen.
Eerst mijn M1015 flashen naar IT mode, dat was mij recent nog niet gelukt
Eerst mijn M1015 flashen naar IT mode, dat was mij recent nog niet gelukt
Zit je net te denken om maar LUKS op een ZVOL te zetten (geen zin om mijn hele pool naar een pool op LUKS te migreren), komt er "binnenkort" wellicht native encryptie voor ZFS on Linux:
https://github.com/zfsonlinux/zfs/pull/4329
Zou mooi zijn
https://github.com/zfsonlinux/zfs/pull/4329
Zou mooi zijn
/u/235875/crop5a67acb560b8e_cropped.png?f=community)
Dat kan gewoon. Alleen Windows doet moeilijk bij nieuwe hardware; maar vrijwel alle non-Windows operating systems kun je gewoon aan andere hardware hangen en daarbij wordt de hardware opnieuw gedetecteerd. Dus opnieuw te installeren hoeft niet.
Ook je data is veilig bij ZFS - alle informatie die nodig is om bij je data te kunnen, staat op de disks zelf. Je bent dus niet afhankelijk van specifieke hardware (behalve de schijven zelf, uiteraard).
Bij BSD (inclusief ZFSguru) maakt dat niet uit. Wel bij ZFS-on-Linux wat op dit vlak niet helemaal probleemloos werkt. Bij andere poorten zul je een 'corrupted data' melding krijgen. Dat klinkt ernstiger dan het is: gewoon even opnieuw de pool importeren en het zou weer moeten werken.
Ja, dat kan. Je bent dus niet afhankelijk van het OS.
Dat klopt. Althans, het eerste punt: stel je hebt vier disks van 1TB,2TB, 3TB en 4TB, en je maakt daar een RAID-Z (zeg maar RAID5) van, dan gebruikt ZFS slechts 4x 1TB. Maar je kunt ook striping gebruiken dus zonder redundancy bescherming en dan wordt de capaciteit gewoon opgeteld, dus in totaal 10TB opslag zou bovenstaand voorbeeld opleveren. Maar met 24 disks wil je natuurlijk wel redundancy!
Wat jij arrays noemt, wordt in ZFS jargon 'vdevs' genoemd: virtual devices. Een 'pool' kan vervolgens één of meerdere vdevs bevatten. De pool is datgene waarbij alle beschikbare ruimte als één geheel beschikbaar is. Dus stel je hebt een pool met een vdev van 10x 4TB in RAID-Z2 en een vdev van 14x 6TB in RAID-Z3, ik noem maar wat, dan heb je de beschikbare opslagruimte van beide vdevs bij elkaar opgeteld als één geheel beschikbaar.
De vdevs in dezelfde pool mogen verschillen van disk grootte, disk aantal en redundancy level. Dus je kunt RAID-Z2 en RAID-Z3 combineren als je dat wilt.
Bedenk wel: als één vdev stuk is, zoals drie disks dood in de RAID-Z2 vdev, dan is alle opslag van de pool ontoegankelijk. Dus je kunt niet meer bij de data die op de RAID-Z3 vdev wordt opgeslagen. Sommigen kiezen om deze reden om aparte pools te maken. Nadeel is wel dat de vrije ruimte nu apart wordt gerekend en niet als één geheel beschikbaar is, evenals dat je iets qua snelheid inboet al mag dat het probleem niet zijn. Je kunt wel configureren dat beide pools meetellen voor de juiste combinatie.
Je kiest waarschijnlijk voor 8 en 16 omdat dit vaak het aantal beschikbare poorten per controller is. Maar dat hoeft niet. Je kunt een vdev ook over meerdere controllers uitsmeren. Punt is dat ZFS onder omstandigheden efficiënter werkt met een specifiek aantal disks.
RAID-Z: 3,5,9,17 disks
RAID-Z2: 4,6,10,18 disks
RAID-Z3: 5,7,11,19 disks
Een RAID-Z2 van 10 disks is een beetje de sweet spot; 20% overhead met toch dubbele parity bescherming. Voor heel veel disks is een RAID-Z3 van 19 disks ook te overwegen. Of twee maal RAID-Z2 van elk 10 disks.
Kortom, moet het persé 24 disks zijn of hoe denk je daarover?
Bij ZFS is het ongeveer alles of niets. Of je hebt toegang tot alle data, of je hele pool is ontoegankelijk en je kunt recovery vergeten. Alle recovery die redelijkerwijs mogelijk is, doet ZFS automatisch al. Maar zodra cruciale filesystem metadata corrupt is, is gelijk je hele pool ontoegankelijk. Technisch gezien kun je met 'zdb' nog wat prutsen, maar ik zou je hoop daarop niet vestigen.
Gaat het niet om metadata maar om bad sectors, dan is ZFS daar heel coulant mee. Corruptie op je disks kan ZFS prima mee dealen. In het ergste geval zal een file stuk gaan.
Voor jouw build zou ik wel aanraden om een goede machine met ECC geheugen te overwegen. Een supermicro moederbord bijvoorbeeld. Gezien de prijzen van de disks maakt dat niet zoveel uit op de totaalprijs.
Succes met je build!
Overigens, ben je van plan heel veel posts te maken, kun je ook overwegen een eigen topic te beginnen. Dat mag gewoon, mits je een beetje uitgebreide startpost maakt.
Met 2 schijven kan je geen raid-z(1,2,3) maken daar zijn meer schijven(minimaal 3 dus) voor nodig.
Mirror wel, kan er ook 1 schijf mee stoppen zonder je data kwijt te raken.
De schijf die al in gebruik is kan je er niet meer bij betrekken.
Never mind, verkeerd gelezen.
Mirror wel, kan er ook 1 schijf mee stoppen zonder je data kwijt te raken.
De schijf die al in gebruik is kan je er niet meer bij betrekken.
Never mind, verkeerd gelezen.
[ Voor 8% gewijzigd door tweedebas op 22-05-2016 20:55 ]
:strip_icc():strip_exif()/u/286431/crop680f6b95743ca_cropped.jpg?f=community)
/u/34216/avatar-60x60.png?f=community){kind=avatar}
Met 2 disks kan RAID-Z ook. Heb je niks aan tov mirror, maar 't kan wel
All my posts are provided as-is. They come with NO WARRANTY at all.
Voor RAID-Z1 heb je minimaal 3 schijven nodig toch? Ik kan me niet voorstellen hoe RAID-Z1 zou moeten werken met 2 schijven.:
Met 2 disks kan RAID-Z ook. Heb je niks aan tov mirror, maar 't kan wel
Gewoon een heel grote verzameling snoertjes
Oke hele stomme actie 
Als ik mijn 4 disken toevoeg komen deze automatisch als 2x2 of 4x1 (mirrored of stripe dus).
Aan de rechter kant zie je dan een grafische weergave en als je met dat balkje gaat verschuiven naar een reeks van 4 kan je dus wel raidz instellen.
Stomstomstom.
Als ik mijn 4 disken toevoeg komen deze automatisch als 2x2 of 4x1 (mirrored of stripe dus).
Aan de rechter kant zie je dan een grafische weergave en als je met dat balkje gaat verschuiven naar een reeks van 4 kan je dus wel raidz instellen.
Stomstomstom.
Wauw, ze knutselen nog flink aan BTRFS
Dat zijn een hoooop wijzigingenHi Linus,
My for-linus-4.7 branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.7
Has our merge window series of cleanups and fixes. These target a wide
range of issues, but do include some important fixes for qgroups,
O_DIRECT, and fsync handling. Jeff Mahoney moved around a few
definitions to make them easier for userland to consume.
Also whiteout support is included now that issues with overlayfs have
been cleared up.
I have one more fix pending for page faults during btrfs_copy_from_user,
but I wanted to get this bulk out the door first.
David Sterba (28) commits (+343/-247):
btrfs: introduce raid-type to error-code table, for minimum device constraint (+16/-1)
btrfs: switch to common message helpers in open_ctree, adjust messages (+50/-52)
btrfs: reuse existing variable in scrub_stripe, reduce stack usage (+9/-10)
btrfs: send: use vmalloc only as fallback for clone_sources_tmp (+8/-5)
btrfs: pass number of devices to btrfs_check_raid_min_devices (+20/-15)
btrfs: use dynamic allocation for root item in create_subvol (+37/-28)
btrfs: use existing device constraints table btrfs_raid_array (+9/-14)
btrfs: clone: use vmalloc only as fallback for nodesize bufer (+8/-5)
btrfs: send: use temporary variable to store allocation size (+8/-6)
btrfs: make find_workspace warn if there are no workspaces (+14/-0)
btrfs: rename and document compression workspace members (+19/-16)
btrfs: send: use vmalloc only as fallback for clone_roots (+7/-4)
btrfs: add read-only check to sysfs handler of features (+3/-0)
btrfs: send: use vmalloc only as fallback for read_buf (+7/-4)
btrfs: send: use vmalloc only as fallback for send_buf (+7/-4)
btrfs: ioctl: reorder exclusive op check in RM_DEV (+11/-12)
btrfs: ioctl: reorder exclusive op check in RM_DEV (+11/-12)
btrfs: add write protection to SET_FEATURES ioctl (+13/-3)
btrfs: kill unused writepage_io_hook callback (+16/-24)
btrfs: rename btrfs_find_device_by_user_input (+13/-10)
btrfs: build fixup for qgroup_account_snapshot (+5/-0)
btrfs: sysfs: protect reading label by lock (+7/-1)
btrfs: make find_workspace always succeed (+12/-8)
btrfs: preallocate compression workspaces (+16/-0)
btrfs: add check to sysfs handler of label (+3/-0)
btrfs: rename __check_raid_min_devices (+2/-2)
btrfs: GFP_NOFS does not GFP_HIGHMEM (+4/-4)
btrfs: rename flags for vol args v2 (+8/-7)
Anand Jain (20) commits (+449/-381):
btrfs: fix lock dep warning, move scratch dev out of device_list_mutex and uuid_mutex (+12/-5)
btrfs: fix lock dep warning move scratch super outside of chunk_mutex (+5/-4)
btrfs: make use of btrfs_scratch_superblocks() in btrfs_rm_device() (+13/-64)
btrfs: enhance btrfs_find_device_by_user_input() to check device path (+3/-4)
btrfs: cleanup assigning next active device with a check (+48/-22)
btrfs: create helper function __check_raid_min_devices() (+32/-19)
btrfs: create helper btrfs_find_device_by_user_input() (+23/-23)
btrfs: clean up and optimize __check_raid_min_device() (+19/-24)
btrfs: create a helper function to read the disk super (+52/-35)
btrfs: rename btrfs_std_error to btrfs_handle_fs_error (+31/-31)
btrfs: pass the right error code to the btrfs_std_error (+2/-2)
btrfs: make use of btrfs_find_device_by_user_input() (+37/-63)
btrfs: move error handling code together in ctree.h (+40/-38)
btrfs: refactor btrfs_dev_replace_start for reuse (+41/-23)
btrfs: s_bdev is not null after missing replace (+6/-3)
btrfs: remove unused function btrfs_assert() (+0/-1)
btrfs: introduce device delete by devid (+73/-5)
btrfs: optimize check for stale device (+2/-1)
btrfs: remove save_error_info() (+6/-10)
btrfs: use fs_info directly (+4/-4)
Filipe Manana (13) commits (+404/-180):
Btrfs: fix race between fsync and direct IO writes for prealloc extents (+37/-6)
Btrfs: fix empty symlink after creating symlink and fsync parent dir (+1/-1)
Btrfs: add semaphore to synchronize direct IO writes with fsync (+77/-118)
Btrfs: fix inode leak on failure to setup whiteout inode in rename (+6/-6)
Btrfs: fix for incorrect directory entries after fsync log replay (+8/-5)
Btrfs: fix race between block group relocation and nocow writes (+81/-1)
Btrfs: fix number of transaction units for renames with whiteout (+8/-1)
Btrfs: don't wait for unrelated IO to finish before relocation (+38/-19)
Btrfs: pin logs earlier when doing a rename exchange operation (+4/-4)
Btrfs: don't do unnecessary delalloc flushes when relocating (+79/-7)
Btrfs: unpin logs if rename exchange operation fails (+36/-2)
Btrfs: unpin log if rename operation fails (+27/-1)
Btrfs: pin log earlier when renaming (+2/-9)
Jeff Mahoney (commits (+1161/-1090):
btrfs: uapi/linux/btrfs.h migration, move struct btrfs_ioctl_defrag_range_args (+37/-32)
btrfs: uapi/linux/btrfs_tree.h migration, item types and defines (+967/-948)
btrfs: uapi/linux/btrfs.h migration, document subvol flags (+14/-3)
btrfs: uapi/linux/btrfs.h migration, move BTRFS_LABEL_SIZE (+1/-1)
btrfs: uapi/linux/btrfs.h migration, move balance flags (+64/-46)
btrfs: uapi/linux/btrfs.h migration, move feature flags (+31/-25)
btrfs: uapi/linux/btrfs.h migration, qgroup limit flags (+21/-9)
btrfs: uapi/linux/btrfs_tree.h, use __u8 and __u64 (+26/-26)
Liu Bo (4) commits (+39/-15):
Btrfs: make mapping->writeback_index point to the last written page (+26/-6)
Btrfs: do not create empty block group if we have allocated data (+8/-1)
Btrfs: cleanup error handling in extent_write_cached_pages (+2/-5)
Btrfs: fix divide error upon chunk's stripe_len (+3/-3)
Luis de Bethencourt (3) commits (+25/-11):
btrfs: fix mixed block count of available space (+13/-3)
btrfs: avoid overflowing f_bfree (+5/-1)
btrfs: fix typos in comments (+7/-7)
Scott Talbert (1) commits (+2/-0):
btrfs: fix memory leak during RAID 5/6 device replacement
Adam Borowski (1) commits (+1/-1):
btrfs: fix int32 overflow in shrink_delalloc().
Luke Dashjr (1) commits (+24/-2):
btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl
Satoru Takeuchi (1) commits (+3/-3):
btrfs: Simplify conditions about compress while mapping btrfs flags to inode flags
Ashish Samant (1) commits (+1/-1):
btrfs: Fix BUG_ON condition in scrub_setup_recheck_block()
Zygo Blaxell (1) commits (+15/-3):
btrfs: don't force mounts to wait for cleaner_kthread to delete one or more subvolumes
Vincent Stehlé (1) commits (+1/-1):
Btrfs: fix fspath error deallocation
Qu Wenruo (1) commits (+105/-24):
btrfs: qgroup: Fix qgroup accounting when creating snapshot
Dan Carpenter (1) commits (+6/-0):
btrfs: send: silence an integer overflow warning
Geert Uytterhoeven (1) commits (+20/-21):
Btrfs: Refactor btrfs_lock_cluster() to kill compiler warning
Josef Bacik (1) commits (+16/-2):
Btrfs: remove BUG_ON()'s in btrfs_map_block
Chandan Rajendra (1) commits (+3/-1):
Btrfs: __btrfs_buffered_write: Pass valid file offset when releasing delalloc space
Dan Fuhry (1) commits (+257/-7):
btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT
Austin S. Hemmelgarn (1) commits (+2/-4):
btrfs: allow balancing to dup with multi-device
Total: (90) commits (+2877/-1994)
fs/btrfs/backref.c | 2 +-
fs/btrfs/btrfs_inode.h | 10 +
fs/btrfs/compression.c | 85 ++-
fs/btrfs/ctree.c | 6 +-
fs/btrfs/ctree.h | 1123 +++------------------------------------
fs/btrfs/delayed-inode.c | 2 +-
fs/btrfs/dev-replace.c | 101 ++--
fs/btrfs/dev-replace.h | 4 +-
fs/btrfs/disk-io.c | 130 ++---
fs/btrfs/extent-tree.c | 167 +++++-
fs/btrfs/extent_io.c | 82 +--
fs/btrfs/extent_io.h | 1 -
fs/btrfs/file.c | 6 +-
fs/btrfs/inode-item.c | 2 +-
fs/btrfs/inode.c | 466 +++++++++++++---
fs/btrfs/ioctl.c | 198 +++++--
fs/btrfs/ordered-data.c | 26 +-
fs/btrfs/ordered-data.h | 6 +-
fs/btrfs/relocation.c | 13 +-
fs/btrfs/root-tree.c | 4 +-
fs/btrfs/scrub.c | 25 +-
fs/btrfs/send.c | 62 ++-
fs/btrfs/super.c | 60 ++-
fs/btrfs/sysfs.c | 14 +-
fs/btrfs/transaction.c | 138 ++++-
fs/btrfs/tree-log.c | 74 +--
fs/btrfs/volumes.c | 454 +++++++++-------
fs/btrfs/volumes.h | 57 +-
include/uapi/linux/btrfs.h | 188 ++++++-
include/uapi/linux/btrfs_tree.h | 966 +++++++++++++++++++++++++++++++++
30 files changed, 2678 insertions(+), 1794 deletions(-)
Even niets...
Au Contraire Mon Capitan!
/u/1176/crop635f8931b2b68_cropped.png?f=community)
Tja. Zou willen dat BTRFS een een keertje stabiel wordt. Waarom moet dit zo lang duren?:
Wauw, ze knutselen nog flink aan BTRFS
Dat zijn een hoooop wijzigingen
Dat is interessant om te lezen. Ik wist niet van het bestaan van deze opties in Oracle's ZFS. Als ik mijn snelle google-zoektocht moet geloven zitten deze opties ook (nog) niet in FreeBSD's ZFS.
Ik zal eens met canmount spelen. Voorlopig even wachten tot de laatste grote ZFS snapshot gesynct is voor ik kan rebooten. Opeens is 50 Mb downstream niet meer zo veel...
Hmm dat doet mij inderdaad weer twijfelen
Ik had namelijk net het plan opgevat om een Nas te bouwen op basis van BTRFS via Rockstor.
Any job you can do in your pajamas is not the hardest job in the world.
Au Contraire Mon Capitan!
https://btrfs.wiki.kernel...hp/FAQ#Is_btrfs_stable.3F:
[...]
Hmm dat doet mij inderdaad weer twijfelen
Short answer: Maybe.
Daar doe ik het niet voor. Als je je eigen product nog niet vertrouwd, toedels!
Au Contraire Mon Capitan!
Daar staat niets relevants. Ze staan niet voor hun eigen product, de laffaards.:
[...]
Je moet ook wel de vervolg tekst lezen onder de maybe
Iemand een idee hoe Ubuntu 16.04 eigenlijk standaard ZFS ondersteund? Ik probeerde laatst een recentere kernel te compileren en installeren, maar na daarmee geboot te zijn werkte ZFS niet meer. Wel nadat ik zfs-dkms installeerde, maar dat zou niet nodig moeten zijn lijkt me.
Afijn blijf wel even bij de default Ubuntu 16.04 kernel dan. Doet het eigenlijk ook al voldoende
Afijn blijf wel even bij de default Ubuntu 16.04 kernel dan. Doet het eigenlijk ook al voldoende
:strip_icc():strip_exif()/u/191401/crop5db452b67938e_cropped.jpeg?f=community)
Gewoon doen, niks mis mee. Ik heb zelf een 16-bay setup met 64TB raw storage over BtrFS en heb er echt van alles en nog wat mee gedaan. Disks eruit trekken om recovery te testen, Raid levels converten van raid1 naar raid0 en weer terug (draai nu raid6) en files verwijderd om via snapshots dingen weer terug te halen. Is niet kapot te krijgen en gezien de hoeveel data die eruit draait (dataset van ongeveer 20TB) super snel.:
[...]
Hmm dat doet mij inderdaad weer twijfelen
De enige disclaimer is dat je niet schuw moet zijn voor de CLI want bijvoorbeeld recovery maar ook veel andere zaken zit nog niet in de Rockstor Webui, dus daarvoor moet je echt verbinding maken met de terminal om commands uit te voeren.
Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.
/u/116403/crop64cfe7aeafeb6_cropped.png?f=community)
i9 12900K | MSI Meg CoreLiquid S360 | ASUS ROG STRIX Z690-A GAMING WIFI D4 | G.Skill Trident Z Royal Elite 2x32GB 4266Mhz Gold | AORUS RTX 4090 MASTER | Dark Power 13 1300W | Samsung 980/860/970/990 Pro | Logitech Z-906 | Phanteks Evolv X | Dell AW3821DW
In zekere zin wel: een (mogelijk) onderliggende RAID controller zou ook write-cache operaties op die schijven kunnen uitvoeren. En ook Windows zou zich er mee kunnen bemoeien (flushen en zo). Het is dus vitaal dat in zo'n pass-thru situatie *niemand* zich verder met die schijven bemoeit, behalve FreeNAS.:
[...]
Heb je dan ook 90% pass-thru
i9 12900K | MSI Meg CoreLiquid S360 | ASUS ROG STRIX Z690-A GAMING WIFI D4 | G.Skill Trident Z Royal Elite 2x32GB 4266Mhz Gold | AORUS RTX 4090 MASTER | Dark Power 13 1300W | Samsung 980/860/970/990 Pro | Logitech Z-906 | Phanteks Evolv X | Dell AW3821DW
Ja, dat klinkt als een goede oplossing.
Dan blijft Windows er in ieder geval van af.
i9 12900K | MSI Meg CoreLiquid S360 | ASUS ROG STRIX Z690-A GAMING WIFI D4 | G.Skill Trident Z Royal Elite 2x32GB 4266Mhz Gold | AORUS RTX 4090 MASTER | Dark Power 13 1300W | Samsung 980/860/970/990 Pro | Logitech Z-906 | Phanteks Evolv X | Dell AW3821DW
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
i9 12900K | MSI Meg CoreLiquid S360 | ASUS ROG STRIX Z690-A GAMING WIFI D4 | G.Skill Trident Z Royal Elite 2x32GB 4266Mhz Gold | AORUS RTX 4090 MASTER | Dark Power 13 1300W | Samsung 980/860/970/990 Pro | Logitech Z-906 | Phanteks Evolv X | Dell AW3821DW
Ik lees in het DIY NAS forum dat een AMD C70 niet echt de beste keus is voor een NAS. Maar voor een offsite backup zal het toch wel prima zijn? Nu kom ik van een Raspberry Pi achtige oplossing
Sinds de 2 dagen regel reageer ik hier niet meer
Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.
C70 is wel echt *heel* oud. Kan je niet beter een nieuwe Celeron nemen? (N3150 ofzo).:
Ik lees in het DIY NAS forum dat een AMD C70 niet echt de beste keus is voor een NAS. Maar voor een offsite backup zal het toch wel prima zijn? Nu kom ik van een Raspberry Pi achtige oplossing
Even niets...
Ik heb freenas draaien op een ESX bak met een IBM 1015 hba gepassthrought.
Nu moet ik alleen alles ombouwen in een andere kast.
Ik weet niet 100% zeker of het iets uitmaakt dat ik alle kabels van de disken los ga maken, natuurlijk zorg ik er wel voor dat elke disk de zelfde kabel heeft op de HBA.
Normaal gesproken met een normale computer maakt dit niets uit maar met Freenas/ESX/HBA combo weet ik dit niet zeker
Kan iemand dit verifieren?
Nu moet ik alleen alles ombouwen in een andere kast.
Ik weet niet 100% zeker of het iets uitmaakt dat ik alle kabels van de disken los ga maken, natuurlijk zorg ik er wel voor dat elke disk de zelfde kabel heeft op de HBA.
Normaal gesproken met een normale computer maakt dit niets uit maar met Freenas/ESX/HBA combo weet ik dit niet zeker
Kan iemand dit verifieren?