Het grote ZFS topic

[CurlyMo]

Op de vraag hoe het dan zit / zat met de CDDL vs GPLv2 licentie problemen:
http://blog.dustinkirklan...-licensing-and-linux.html

[Verwijderd]

Niet zo heel veel informatie in dat artikeltje... wat ik zelf had begrepen is dat het obstakel vooral was dat ZFS code niet in de Linux kernel terecht kon komen vanwege de sign-off statement die moet worden afgegeven door contributors, zoals vereist door Linus Torvalds. Maar het fijne weet ik er ook niet van. Maar zoals ik begrepen had, was het niet zozeer een issue tussen de CDDL en GPLv2 licenties.

[A1AD]

*knip* probeer de systemd discussie dan ook elders te voeren, dank!

[ Voor 88% gewijzigd door Verwijderd op 21-02-2016 10:08 ]

[CurlyMo]

Verwijderd schreef op zondag 21 februari 2016 @ 02:44:
Niet zo heel veel informatie in dat artikeltje... wat ik zelf had begrepen is dat het obstakel vooral was dat ZFS code niet in de Linux kernel terecht kon komen vanwege de sign-off statement die moet worden afgegeven door contributors, zoals vereist door Linus Torvalds. Maar het fijne weet ik er ook niet van. Maar zoals ik begrepen had, was het niet zozeer een issue tussen de CDDL en GPLv2 licenties.

Wat ze dus zeggen is dat zodra je een ZFS als kernel module meeneemt in je OS je niet tegen die licentieproblemen aanloopt. Zouden ze ZFS mee gecompileerd hebben wel als geïntegreerde driver. Dat is dus ook precies wat alle distro's deden. Bij het installeren van de ZFS modules werd hij gecompileerd voor je kernel en als module beschikbaar gemaakt.

[Verwijderd]

Ja zelf compileren kan altijd. Maar volgens mij staat CDDL en GPL ook toe dat je de code als kernel module apart houdt maar wel in de sourcetree hebt en ook binary meelevert (als aparte .ko module). Kortom, dan hoef je niet meer te compileren maar kun je een LiveCD / USB stick direct met Linux en ZFS werkend maken. Mij is verteld dat dit (het opnemen van de CDDL code binnen de Linux kernel als aparte module) niet kan omdat Linus eisen stelt aan het tekenen van een verklaring, niet zozeer een incompatibility tussen CDDL en GPLv2. Immers, FreeBSD heeft ook GPL code en CDDL code samen met de eigen BSD code in de sourcecode, en die wordt ook binary meegeleverd via disk images zoals de USB stick image.

[FireDrunk]

Linus kan eisen wat hij wil, hij is nog steeds niet de eigenaar van Linux, hooguit degene met het meeste respect in de community. Je kan prima de kernel forken en zelf meuk meeleveren.

De vraag is dan alleen of anderen jou gaan zien als upstream kernel provider

Maar je kan out of the box nu ook al een werkende ZFS meeleveren, gewoon de source code meeleveren en live compilen tijdens installatie. Werkt prima, doet Gentoo al jaren op zijn Live DVD.

[Verwijderd]

Uiteraard dat je kunt forken. Maar het zou wel verklaren waarom ZFS niet direct net zoals bij BSD in de kernel opgenomen kan worden (als kernel module weliswaar) terwijl dat niet direct aan CDDL/GPL licentie te wijten is. Ook zou het verklaren waarom Ubuntu het nu toch gewoon gaat doen, omdat zij volgens mij niet 1:1 de Linux kernel overnemen; al zeg ik nu dingen waar ik weinig van weet. Maar ik meen me te herinneren dat sommige Linux distro's zoals Slackware exact dezelfde 'officiële' Linux kernel gebruiken die door Linus Torvalds wordt vrijgegeven, terwijl andere distro's zelf wat aanpassingen doen, in feite forks/derivatives van de Linux kernel. Klopt dat ongeveer?

Live compileren tijdens installatie vind ik niet helemaal out-of-the-box. Daarmee bedoel ik dat het al voorgecompileerd en dus binair wordt meegeleverd, zoals ook BSD doet. Dat gaat Ubuntu nu ook doen toch? Of heb ik het artikeltje verkeerd begrepen?

[FireDrunk]

Mwoh, genoeg bedrijven houden inderdaad hun eigen repo bij, die ze weer bijmergen vanaf andere locaties, maar dat zegt weinig. Ik denk dat gewoon niemand zin heeft in de ZFS CDDL vs GPL discussie in de rechtzaal. Zolang er geen nood aan de man is, who cares... Het werkt zo toch?

[FutureCow]

Komt ZFS ooit als package voor debian? Een tijdje geleden kon ik nog wel iets vinden in de package tracker van debain, maar vindt nu niets meer terug. spl-linux zit al wel een tijdje in testing.

https://qa.debian.org/dev...40lists.alioth.debian.org

Hier vond ik eerder dus ook zfs-linux package, nu niet meer.

[H!GHGuY]

Verwijderd schreef op zondag 21 februari 2016 @ 11:19:
... niet kan omdat Linus eisen stelt aan het tekenen van een verklaring, niet zozeer een incompatibility tussen CDDL en GPLv2.

Niet juist. Erger nog: Sun heeft ooit de CDDL in het leven geroepen en expliciet incompatible gemaakt met GPL zodat ZFS nooit in Linux zou kunnen terecht komen. Zo konden ze een Unique Selling Point houden op hun Solaris. Or so I was told.
CDDL en GPL zijn dus wel degelijk incompatible.

Immers, FreeBSD heeft ook GPL code en CDDL code samen met de eigen BSD code in de sourcecode, en die wordt ook binary meegeleverd via disk images zoals de USB stick image.

Dit lijkt me sterk. De BSD is compatible met GPL, maar slechts in 1 richting: BSD -> GPL.
De kans is dus klein dat ze GPL code en BSD code in 1 executable stoppen voor hun FreeBSD.

Wellicht bedoel je dat ze een aantal GPL tools meeleveren? Hoe de code in een sourcetree zit is irrelevant. Het is hoe je ze combineert tijdens compilatie die belangrijk is.

Sowieso is dit een gedurfde zet van Canonical en het lijkt me dat, los van of er een aanklacht komt, het legal dept. bij Oracle op dit moment een field day beleeft.

Met mijn beperkte legal kennis lijkt het me waarschijnlijk dat er een case te maken is, maar of ze dit zullen doen is ook een goeie vraag.

[ Voor 5% gewijzigd door H!GHGuY op 21-02-2016 17:41 ]

[the_cyberspace]

Even een vraagje van een beginneling op Linux / ZFS gebied. Hebben jullie nog een stukje cache gereserveerd als partitie zijnde voor ZFS? Of hebben jullie dit anders gedaan?

Ik heb nu een Ubuntu installatie draaien op een singel ssd-tje van 64GB (pricewatch: Crucial m4 CT064M4SSD2 64GB) en heb de beschikking over 2 120GB intel SSD (pricewatch: Intel 510 Retail 120GB) en kan eventueel rekening houden met een stukje cache voor ZFS of is dit overkill / niet nodig? De 64Gb ssd is bedoeld voor een andere pc namelijk

[FireDrunk]

Wat is de reden dat je de speciale caching features van ZFS gebruikt? Het is namelijk helemaal niet verplicht ofzo, en de SSD's die jij noemt zijn niet echt gemaakt voor die belasting.

Theoretisch gezien kan het wel, maar nodig is het niet

[the_cyberspace]

Ik heb dat nu ook niet in gebruik, vandaar m`n vraag of het zinnig is ja of nee.

[FireDrunk]

Dat ligt er aan wat je met de array doet
Als je er veel vm's op draait kan het helpen, maar ik zou het niet doen met die SSDs.

[narotic]

Heb je wel een pool met traditionele harde schijven? Het heeft immers geen zin om L2ARC op een SSD in te zetten voor een pool met alleen maar SSD's (exotische uitzonderingen daargelaten).

[CyBeR]

The_Cyberspace schreef op zondag 21 februari 2016 @ 20:31:
Ik heb dat nu ook niet in gebruik, vandaar m`n vraag of het zinnig is ja of nee.

Een L2ARC is maar vrij zeldzaam zinnig. En zeker niet als je pool zelf al op SSD's staat.

[ Voor 9% gewijzigd door CyBeR op 21-02-2016 22:42 ]

[the_cyberspace]

Ik heb een pool met harde schijven inderdaad, die 2 intel ssd`s zijn bedoeld voor het OS en aangezien ik de boel opnieuw ga installeren kan ik nog alle kanten op.

[narotic]

En wil je een L2ARC (lees cache) of ZIL (write cache)?

Persoonlijk zou ik in jouw situatie sowieso een deel vrijhouden op beide SSD's voor L2ARC. Hoe groot hangt af van hoe groot je pool en de typische working set is, hoeveel ruimte je nodig hebt voor het OS, swap etc. en in mindere mate van hoeveel RAM je hebt.

Er zijn blijkbaar genoeg verschillende meningen over L2ARC hier, maar het ergste wat je kan overkomen is dat je er simpelweg geen profijt van hebt. Een standaard argument is dat je het geld voor een L2ARC beter aan RAM kunt besteden, maar als je de SSDs toch al hebt liggen gaat dat niet op.

Wat mij betreft kun je het argument negeren dat je SSD binnen een maand de prullenbak in kan door de verhoogde schrijfactiveit. Standaard beperkt in ieder geval FreeBSD het schrijven naar de cache op 8MB/s (sysctl vfs.zfs.l2arc_write_max) en de Intel 510 is gespecificeerd op 5000 p/e cycles. In het meest extreme geval van continu schrijven naar de cache haal je dus 5000 * 120GB / 8MB/s = ongeveer 889 dagen. In de praktijk zul je echter nooit continu naar de cache schrijven (helemaal niet als de cache groter is dan je working set), dus je kunt zelfs de cache throughput gerust verhogen.

[ Voor 8% gewijzigd door narotic op 22-02-2016 22:35 ]

[the_cyberspace]

Ik moet me nog verder verdiepen/inlezen hoe ik de boel ga indelen. Als het zinvol is om een deel of een ssd te gebruiken als cache dan kan ik hier rekening mee houden. Ik kan eventueel ook nog schuiven met de ssd`s mocht dit nodig zijn of beter zijn. Maar daar is dit topic niet echt voor bedoeld, wel over als het om ZFS gaat lijkt me zo, dus vandaar m`n vraag.
Geheugen is niet echt een probleem, heb er in totaal 32GB ddr3 ECC inzitten (is in de loop der tijd steeds uitgebreid en qua kosten was het te overzien)

Het is overigens wel voor thuis gebruik en de boel zal niet erg zwaar belast worden.

[Q]

The_Cyberspace schreef op dinsdag 23 februari 2016 @ 19:07:
Het is overigens wel voor thuis gebruik en de boel zal niet erg zwaar belast worden.

Dan heb je waarschijnlijk niets aan een SSD als L2ARC read cache. Je hebt al zoveel RAM.
Ik heb ook 2 SSDs in RAID1 voor het OS. Ik had op mijn 71 TB server een tijdje L2ARC aangezet, maar ik heb er niets aan en daarom - om de levensduur van mijn SSDs te verlengen - L2ARC uitgezet.

[ Voor 24% gewijzigd door Q op 23-02-2016 19:30 ]

[Neptunus]

Aan de hand van de post van narotic ben ik eens gaan nadenken. Zelf heb ik een server met totaal 32GB ddr3 ECC. Ik gebruik twee (pricewatch: Intel 320 Series 2.5" 120GB SATA II MLC)
Welke ik gebruik voor L2ACR (second level adaptive replacement cache), ZIl (ZFS Intent Log) en een stukje data (data is eigenlijk niet in gebruik). Nu trek ik in twijvel of deze configuratie wel nuttig is voor mij (voegt het iets toe?).

De server wordt thuis gebruikt. Er zijn drie gebruikers die op moment 3 keer een GB verbinding dicht trekken. Daarom heb ik met mijn SG300-10 en de machine een 3 poorts Link aggregation (LAG) opgezet. Hierdoor kunnen de drie gebruikers de volle potentie van de server gebruiken.

De Intel 320 kunnen lezen 270 MB/s en schrijven 220 MB/s. Mean Time Between Failures (MTBF) is 1,200,000 uur. Opmerking uit de spec:
The SSD will have a minimum of five years of useful life under
typical client workloads with up to 20 GB of host writes per day

code:

zpool iostat -v
                     capacity     operations    bandwidth
pool              alloc   free   read  write   read  write
----------------  -----  -----  -----  -----  -----  -----
zssddata          74.5M  63.4G      0      0    101    482
  mirror          74.5M  63.4G      0      0    101    482
    gpt/ssddata1      -      -      0      0     79    491
    gpt/ssddata2      -      -      0      0     42    491
----------------  -----  -----  -----  -----  -----  -----
zstore            11.4T  6.73T      3     10   330K   493K
  raidz2          11.4T  6.73T      3     10   330K   468K
    gpt/disk1         -      -      0      1  39.2K  65.9K
    gpt/disk2         -      -      0      1  39.3K  65.9K
    gpt/disk3         -      -      0      1  39.2K  65.9K
    gpt/disk4         -      -      0      1  39.2K  65.9K
    gpt/disk5         -      -      0      1  39.2K  65.9K
    gpt/disk6         -      -      0      1  39.2K  65.9K
    gpt/disk7         -      -      0      1  39.2K  65.9K
    gpt/disk8         -      -      0      1  39.2K  65.9K
    gpt/disk9         -      -      0      1  39.2K  65.9K
    gpt/disk10        -      -      0      1  39.2K  65.9K
logs                  -      -      -      -      -      -
  mirror           564K  7.94G      0      0      0  24.9K
    gpt/log1          -      -      0      0      7  24.9K
    gpt/log2          -      -      0      0      7  24.9K
cache                 -      -      -      -      -      -
  gpt/cache1      20.4G  3.63G      0      0  1.06K   109K
  gpt/cache2      21.0G  2.95G      0      0   1010   113K
----------------  -----  -----  -----  -----  -----  -----

Hieronder hoe ik de twee SSD voor L2ACR, ZIl en data heb aangemaakt.

code:

# Create the gpt structure on the drives.
# Data drives:
gpart create -s gpt da1
gpart create -s gpt da2
gpart create -s gpt da3
gpart create -s gpt da4
gpart create -s gpt da5
gpart create -s gpt da6
gpart create -s gpt da7
gpart create -s gpt da8
gpart create -s gpt da9
gpart create -s gpt da10
gpart create -s gpt da11
gpart create -s gpt da12

# Create partitions on data drives
gpart add -t freebsd-zfs -a 1m -l disk1 da1
gpart add -t freebsd-zfs -a 1m -l disk2 da2
gpart add -t freebsd-zfs -a 1m -l disk3 da3
gpart add -t freebsd-zfs -a 1m -l disk4 da4
gpart add -t freebsd-zfs -a 1m -l disk5 da5
gpart add -t freebsd-zfs -a 1m -l disk6 da6
gpart add -t freebsd-zfs -a 1m -l disk7 da7
gpart add -t freebsd-zfs -a 1m -l disk8 da8
gpart add -t freebsd-zfs -a 1m -l disk9 da9
gpart add -t freebsd-zfs -a 1m -l disk10 da10

gpart add -t freebsd-zfs -a 1m -l log1 -s 8G da11
gpart add -t freebsd-zfs -a 1m -l cache1 -s 24G da11
gpart add -t freebsd-zfs -a 1m -l ssddata1 -s 64G da11

gpart add -t freebsd-zfs -a 1m -l log2 -s 8G da12
gpart add -t freebsd-zfs -a 1m -l cache2 -s 24G da12
gpart add -t freebsd-zfs -a 1m -l ssddata2 -s 64G da12

# Create virtual devices which define 4K sector size
gnop create -S 4k gpt/disk1
gnop create -S 4k gpt/disk2
gnop create -S 4k gpt/disk3
gnop create -S 4k gpt/disk4
gnop create -S 4k gpt/disk5
gnop create -S 4k gpt/disk6
gnop create -S 4k gpt/disk7
gnop create -S 4k gpt/disk8
gnop create -S 4k gpt/disk9
gnop create -S 4k gpt/disk10

gnop create -S 4k gpt/log1
gnop create -S 4k gpt/cache1
gnop create -S 4k gpt/ssddata1

gnop create -S 4k gpt/log2
gnop create -S 4k gpt/cache2
gnop create -S 4k gpt/ssddata2

# Create the pool and define some general settings:
zpool create zstore raidz2 gpt/disk1.nop gpt/disk2.nop gpt/disk3.nop gpt/disk4.nop gpt/disk5.nop gpt/disk6.nop gpt/disk7.nop gpt/disk8.nop gpt/disk9.nop gpt/disk10.nop
zpool add zstore log mirror gpt/log1.nop gpt/log2.nop
zpool add zstore cache gpt/cache1.nop
zpool add zstore cache gpt/cache2.nop

zpool create zssddata mirror gpt/ssddata1.nop gpt/ssddata2.nop

# Export pool and remove virtual devices
zpool export zstore
zpool export zssddata

gnop destroy gpt/disk1.nop
gnop destroy gpt/disk2.nop
gnop destroy gpt/disk3.nop
gnop destroy gpt/disk4.nop
gnop destroy gpt/disk5.nop
gnop destroy gpt/disk6.nop
gnop destroy gpt/disk7.nop
gnop destroy gpt/disk8.nop
gnop destroy gpt/disk9.nop
gnop destroy gpt/disk10.nop

gnop destroy gpt/log1.nop
gnop destroy gpt/cache1.nop
gnop destroy gpt/ssddata1.nop

gnop destroy gpt/log2.nop
gnop destroy gpt/cache2.nop
gnop destroy gpt/ssddata2.nop

# Import pool. Tell zpool to look for devices in /dev/gpt, in order to keep labels.
zpool import -d /dev/gpt zstore
zfs set atime=off zstore
zfs set checksum=fletcher4 zstore
zfs set compression=lzjb zstore
zpool set autoexpand=on zstore
zpool set autoreplace=on zstore

zpool import -d /dev/gpt zssddata
zfs set atime=off zssddata
zfs set checksum=fletcher4 zssddata
zfs set compression=lzjb zssddata
zpool set autoexpand=on zssddata
zpool set autoreplace=on zssddata

Beide SSD's zijn al wel even in gebruik. Bedrijfsuren 23948 = 2.7 jaar.
Schrijven ~567797 * 32MiB = 17.32 TiB
Lezen ~124432 * 32MiB = 3.79 TiB

SMART info van beide SSD's

code:

$ smartctl -ai /dev/da11
smartctl 6.4 2015-06-04 r4109 [FreeBSD 10.2-RELEASE-p9 amd64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Intel 320 Series SSDs
Device Model:     INTEL SSDSA2CW120G3
Serial Number:    xxxxxxxxxxxxxxxxxxxxxxx
LU WWN Device Id: 5 001517 a6be7410b
Firmware Version: 4PC10362
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Wed Feb 24 21:22:41 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)    Offline data collection activity
                    was never started.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (  17)    The self-test routine was aborted by
                    the host.
Total time to complete Offline
data collection:         (    1) seconds.
Offline data collection
capabilities:              (0x75) SMART execute Offline immediate.
                    No Auto Offline data collection support.
                    Abort Offline collection upon new
                    command.
                    No Offline surface scan supported.
                    Self-test supported.
                    Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003)    Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01)    Error logging supported.
                    General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   1) minutes.
Extended self-test routine
recommended polling time:      (   1) minutes.
Conveyance self-test routine
recommended polling time:      (   1) minutes.
SCT capabilities:            (0x003d)    SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0020   100   100   000    Old_age   Offline      -       0
  4 Start_Stop_Count        0x0030   100   100   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       23948
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       67
170 Reserve_Block_Count     0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
183 SATA_Downshift_Count    0x0030   100   100   000    Old_age   Offline      -       0
184 End-to-End_Error        0x0032   100   100   090    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       65
199 CRC_Error_Count         0x0030   100   100   000    Old_age   Offline      -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       567797
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       171108
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       17
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       1436912
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   097   097   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       567797
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       124432

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

code:

$ smartctl -ai /dev/da12
smartctl 6.4 2015-06-04 r4109 [FreeBSD 10.2-RELEASE-p9 amd64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Intel 320 Series SSDs
Device Model:     INTEL SSDSA2CW120G3
Serial Number:    xxxxxxxxxxxxxxxxxxxxxxx
LU WWN Device Id: 5 001517 95967256e
Firmware Version: 4PC10362
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Wed Feb 24 21:23:24 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)    Offline data collection activity
                    was never started.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (  17)    The self-test routine was aborted by
                    the host.
Total time to complete Offline
data collection:         (    1) seconds.
Offline data collection
capabilities:              (0x75) SMART execute Offline immediate.
                    No Auto Offline data collection support.
                    Abort Offline collection upon new
                    command.
                    No Offline surface scan supported.
                    Self-test supported.
                    Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003)    Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01)    Error logging supported.
                    General Purpose Logging supported.
Short self-test routine
recommended polling time:      (   1) minutes.
Extended self-test routine
recommended polling time:      (   1) minutes.
Conveyance self-test routine
recommended polling time:      (   1) minutes.
SCT capabilities:            (0x003d)    SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  3 Spin_Up_Time            0x0020   100   100   000    Old_age   Offline      -       0
  4 Start_Stop_Count        0x0030   100   100   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       23948
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       67
170 Reserve_Block_Count     0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
183 SATA_Downshift_Count    0x0030   100   100   000    Old_age   Offline      -       0
184 End-to-End_Error        0x0032   100   100   090    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       65
199 CRC_Error_Count         0x0030   100   100   000    Old_age   Offline      -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       567803
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       8501
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       0
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       1436913
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   097   097   000    Old_age   Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       567803
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       124386

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 0
Note: revision number not 1 implies that no selective self-test has ever been run
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Als ik dit zo allemaal bekijk dan twijvel ik of ik de SSD's niet beter anders kan inzetten. Wat denken jullie? Ben benieuwd naar jullie meningen.

[narotic]

Je post bevat juist geen statistieken over de L2ARC, dus is het moeilijk om te zeggen of je er voordeel aan hebt. Zoals je zegt heb je 567803 * 32MiB = ruim 17TiB geschreven. Dat is gemiddeld zo'n 760MiB per uur en dus niet bepaald zorgwekkend. Ook in absoluut zin is 17TiB nog ver onder de levelsduur van de SSD: vermoedelijk is Media_Wearout_Indicator de resterende levensduur (97%), wat in zou houden dat de SSD's bij je huidige gebruik nog zo'n 80 jaar door blijven pruttelen.

Om daadwerkelijk te bepalen of je voordeel hebt aan de L2ARC zul je meerdere statistieken moeten raadplegen. Zelf gebruik ik hiervoor sysutils/zfs-stats (BSD only, maar dat gebruik je zo te zien), welke min of meer de ARC/L2ARC statistieken in de verschillende sysctl's handig weergeeft. Ik ben verre van een expert, maar zelf gebruik ik zfs-stats -AEL en ik let op:

• ARC Cache Hit Ratio/Actual Hit Ratio: Hit ratio (met en zonder anonymous buffers) van de ARC in je RAM. Des te dichter deze bij de 100% zit, des te minder voordeel je kunt hebben van een extra L2ARC omdat je ARC het al goed alleen af kan.
• L2ARC Header Size: Dit is de ruimte die je in je RAM kwijt bent aan datastructuren voor je L2ARC, waardoor dus ook de grootte en effectiviteit van de ARC afneemt. Zo uit mijn hoofd is de formule ongeveer 200 * L2ARCSize / recordsize. Met andere woorden, dit is voornamelijk een risico bij kleine recordsizes (bijvoorbeeld 4KiB) in combinatie met een grote L2ARC. In dergelijke situaties kan een L2ARC meer kwaad dan goed doen.
• L2 ARC Hit Ratio: Dit is de hit ratio van requests die niet in de ARC stonden maar wel in de L2ARC. Als deze nagenoeg 0% is dan heb je dus in de praktijk erg weinig aan je L2ARC.

Dit helpt je waarschijnlijk op start, maar je kunt nog meer te weten komen door goed naar het onderscheid in Data Demand/Prefetch en non-ghost/ghost te kijken (zie hier of hier voor meer uitleg). Kort door de bocht kun je aan ghost ratios zien hoeveel voordeel je kunt hebben door je ARC/L2ARC uit te breiden.

Je moet je echter beseffen dat dit gemiddelden zijn sinds boot. Zelfs een 0.1% die uit de L2ARC komt kan op het juiste moment zelfs de moeite waard zijn. Ter voorbeeld, ik heb een L2ARC op een 16GB USB stick. Vaak heb ik er geen voordeel van, maar bij bepaalde commando's die veel random IO veroorzaken zoals svn up /usr/ports of find / (NB: metadata!) is er wel degelijk een verschil te merken. In die gevallen haalt zelfs een USB stick relatief makkelijk 500-1000 read IOPS, wat de 4 schijven in mijn root pool niet zouden halen. Aangezien ik als gebruiker zit te wachten tot deze commando's klaar zijn is het voor mij de moeite waard, ondanks dat dat waarschijnlijk niet uit de gemiddelde statistieken zou blijken. Zelf hou ik af en toe in de gaten hoeveel uit de L2ARC komt d.m.v. zpool iostat -v 1, maar een script als arcstat.pl geeft je misschien meer informatie.

Je zegt verder dat de 3 gebruikers ieder 1Gbit/s voltrekken. Het lijkt erop dat je hiermee op streaming reads doelt. Standaard worden deze niet door de L2ARC afgehandeld maar direct doorgestuurd naar de storage zelf. L2ARC is in primaire zin bedoeld om random I/O te versnellen en daarmee in te spelen op de sterke kant van SSD's t.o.v. harde schijven. Als je ook je throughput wilt versnellen, dan zul je prefetch expliciet moeten aanzetten voor de L2ARC (vfs.zfs.l2arc_noprefetch=0). Pin me er niet op vast, maar dat levert vermoedelijk wel veel hogere schrijfactiviteit richting de L2ARC op.

Verder wil ik nog even een laatste voordeel van L2ARC aanstippen wat hier eerder door HyperBart ook al genoemd werd: met een slimme configuratie kan een L2ARC ervoor zorgen dat je schijven veel vaker in idle kunnen blijven. Dit voordeel is juist interessant voor thuisservers die grote delen van de dag niets staan te doen.

[ Voor 1% gewijzigd door narotic op 25-02-2016 11:02 . Reden: paar correcties ]

[Keiichi]

narotic schreef op woensdag 24 februari 2016 @ 23:43:


Verder wil ik nog even een laatste voordeel van L2ARC aanstippen wat hier eerder door HyperBart ook al genoemd werd: met een slimme configuratie kan een L2ARC ervoor zorgen dat je schijven veel vaker in idle kunnen blijven. Dit voordeel is juist interessant voor thuisservers die grote delen van de dag niets staan te doen.

Als een sequential read doe, dan zie ik wel dat de L2ARC gevuld wordt

[CurlyMo]

Ik heb op zich wel oor naar een zuinigere NAS volgens de HyperBart methode, maar vraag me af of ik wel genoeg winst kan halen bij een 4 HDD / 2 SSD NAS en een huiselijk idle verbruik van 30Wh

[narotic]

Keiichi schreef op donderdag 25 februari 2016 @ 09:00:
[...]


Als een sequential read doe, dan zie ik wel dat de L2ARC gevuld wordt

Maar wordt er dan ook van gelezen?

Hier gebeurt hetzelfde trouwens. Helaas kan ik het niet met 100% zekerheid zeggen, maar een logische verklaring is dat dit schrijven een indirect gevolg is van de streaming read. Een belangrijk punt is dat data alleen via de ARC in de L2ARC terecht kan komen. Stel dat je prefetch gebruik voor je ARC (vfs.zfs.prefetch_disable=0, default op FreeBSD met >4GB RAM), dan komen streaming reads wel in je ARC terecht (zie ook Prefetch stats in zfs-stats). Om ruimte vrij te maken voor deze prefetch blocks zullen andere dingen uit de ARC gegooid moeten worden. De L2ARC merkt dat er evictions aan zitten te komen en begint dus met kopieren. Dit zouden dan blocks moeten zijn die eigenlijk niets met de streaming read te maken hebben.

Edit: Ik lees net dat streaming data wel in de L2ARC terecht zal komen, maar dat het simpelweg niet gebruikt wordt voor leesacties:

vfs.zfs.l2arc_noprefetch
This controls if the zfs prefetcher (zfetch) should read data from the l2 arc when prefetching. It does not control if prefetched data is cached into l2. It only controls if the prefetcher uses the l2 arc to read from.

(bron)

Als dit klopt, dan zal prefetch aanzetten op een L2ARC ook niet tot hogere schrijfactiviteit leiden.

[ Voor 21% gewijzigd door narotic op 25-02-2016 10:35 ]

[Q]

CurlyMo schreef op donderdag 25 februari 2016 @ 09:28:
Ik heb op zich wel oor naar een zuinigere NAS volgens de HyperBart methode, maar vraag me af of ik wel genoeg winst kan halen bij een 4 HDD / 2 SSD NAS en een huiselijk idle verbruik van 30Wh

2 euro per watt, dus als je naar 20 watt kunt dan bespaar je op jaarbasis 20 euro? Is het je dat waard?

[Keiichi]

narotic schreef op donderdag 25 februari 2016 @ 10:09:
[...]


Maar wordt er dan ook van gelezen?

Nee er wordt niets van gelezen (tenzij sysctl vfs.zfs.l2arc_noprefetch=0 gedaan is).

[CurlyMo]

Q schreef op donderdag 25 februari 2016 @ 10:32:
[...]


2 euro per watt, dus als je naar 20 watt kunt dan bespaar je op jaarbasis 20 euro? Is het je dat waard?

De vraag daarbij is dus impliciet of 4 HDD's idlen wel 10watt bespaart?

[dcm360]

Een (iewat gekleurde) uiteenzetting over of het combineren van ZFS met Linux kan: GPL Violations Related to Combining ZFS and Linux

[CurlyMo]

De kern van het hele verhaal zit hem in de statische en dynamische verbondenheid tussen code. Een ingebakken linux kernel module is een statisch verbonden module. Een externe module is een dynamische verbonden module. In GPLv2 vereisen beide een GPLv2 licentie aangezien de kernel ook GPLv2 is.

De kern is hier - en zoals het in het verleden is opgelost - wie de licentie voorwaarden schendt.
1. Door het client-side compileren van de module tegen de kernel broncode is een schending van GPLv2, maar deze wordt niet gepleegd door de distributeur, maar door de gebruiker. Die zet immers de compilatie in gang. (Het zou wel netjes zijn om de gebruiker van de schending op de hoogte te stellen bij het installeren van ZFS).
2. Door het server-side compileren van de module tegen de kernel broncode is een schending van GPLv2, maar dan gepleegd door de distributeur. Voor het compileren van de module op zichzelf is het al nodig om dynamisch te kunnen linken met de GPLv2 kernel broncode.

Beiden staan los van het al ingeladen zijn van de kernel module bij de installatie of door de gebruiker, aangezien er voor het maken van de module op zichzelf al een schending is gepleegd.

[Verwijderd]

'ietwat gekleurd' ?! Dat artikel is best wel flink geopinieerd en spreekt van 'we' versus 'they' en stellingen als 'GPL-incompatible licenses are the root of all GPL violations'. Nog steeds geen echte bron over compatibility tussen CDDL en GPL wat mij betreft.

Ook zoiets:

we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license.

Gewoon doen wat 'wij' Linux copyright fans willen dus, onder onze license. Dat BSD door zo'n move er sterk op achteruit gaat, zal ze natuurlijk weinig uitmaken. Alleen hun belangen telt want hun mening is de juiste. Dat is althans wat ik proef in uitspraken als deze.

Punt is ook, nu zijn de rollen eens omgedraaid. BSD door zijn permissive license heeft er geen enkel probleem mee. Maar als Linux een keer iets niet kan overnemen door de restricties die hun eigen licentie oplegt, dan zijn ze boos. Als er iemand reden heeft om boos te zijn, lijkt het me wel het andere kamp, waar het vaak eenrichtingsverkeer is: code van BSD kan wel naar Linux maar andersom niet. Toch hoor je vooral het Linux kamp klagen.

H!GHGuY schreef op zondag 21 februari 2016 @ 17:40:
Niet juist. Erger nog: Sun heeft ooit de CDDL in het leven geroepen en expliciet incompatible gemaakt met GPL zodat ZFS nooit in Linux zou kunnen terecht komen. Zo konden ze een Unique Selling Point houden op hun Solaris. Or so I was told.

Dat soort dingen lees ik ook, bijvoorbeeld op Phoronix forums waar toch aardig agressief volk zit en waar BSD regelmatig belachelijk wordt gemaakt. Of het ook echt zo is, betwijfel ik. Sun zit in het UNIX kamp en daar worden andere licenties gebruikt dan in het Linux/GNU kamp. Dat laatste is copyleft om vrijheid 'af te dwingen' - een contradictie in terminis wat mij betreft. Dat is zoiets als 'Peace through superior firepower'.

CDDL en GPL zijn dus wel degelijk incompatible.

Ik denk dat een dergelijke conclusie pas gemaakt kan worden, als er iets neutraler en objectiever naar de kwestie wordt gekeken door iemand die een sterke juridische achtergrond heeft. Ubuntu heeft een vrij groot bedrijf Canonical achter zich en die zal toch zeker hun eigen juridische afdeling er naar hebben laten kijken. Dus of het echt problemen voor ze gaat opleveren, betwijfel ik.

Dit lijkt me sterk. De BSD is compatible met GPL, maar slechts in 1 richting: BSD -> GPL.
De kans is dus klein dat ze GPL code en BSD code in 1 executable stoppen voor hun FreeBSD.

Ik zei niet in één executable, ik zei dat ze binary (compiled) code GPL en BSD in één pakket leveren. Dus niet in de vorm van sourcecode maar al gecompileerd. Overigens is BSD hard bezig zich hiervan te ontdoen en base helemaal vrij van GPL code te houden. GCC is al vervangen door Clang en hier zie je de resterende zaken waar ze vervanging voor aan het zoeken zijn: https://wiki.freebsd.org/GPLinBase.

[Paul]

Verwijderd schreef op vrijdag 26 februari 2016 @ 11:16:
'GPL-incompatible licenses are the root of all GPL violations'

GPL-aanhangers doen alsof ze zo open en vrij zijn, maar zelf (als [voormalig] developer) vind ik de GPL juist erg gesloten en eerder een virus dan wat anders. "Ja hoor, je mag dit wonderschone mooie stukje software best gebruiken, geen probleem, nou ja, als je maar wel eventjes al je rechten op je eigen software en alles in een straal van 100m er omheen opgeeft..."

Nou ja, dat is wel een klein beetje overdreven, maar dat is wel de indruk die je er bij krijgt. Natuurlijk zien de open source aanhangers graag dat ik mijn software ook open source maak, maar mijn bedrijfsmodel is nu eenmaal het in licentie geven ("verkopen") van software. Je kunt als "open source"-club wel aangeven dat je graag hebt dat ik het gratis weggeef en geld vraag voor support, maar dan vraag ik me af wat de kwaliteit van je software is als je kunt leven van het oplossen van de problemen die er in zitten, want zoveel support aanvragen kreeg ik echt niet.

En ik wil best compenseren voor het gebruik van andermans werk, maar de prijs die men er bij de GPL voor vraagt is voor een closed source-bedrijf wel erg hoog...

[CyBeR]

While there are complexities that we must address, in this context, Oracle could make everyone's life easier by waving their magic relicensing wand.

Ja, of Linux kan ophouden met die GPL-onzin en overschakelen naar iets beters. Waarom moet 't altijd de niet-GPL-software zijn?

[CurlyMo]

CyBeR schreef op vrijdag 26 februari 2016 @ 12:01:
[...]


Ja, of Linux kan ophouden met die GPL-onzin en overschakelen naar iets beters. Waarom moet 't altijd de niet-GPL-software zijn?

Dat is simpelweg onmogelijk. Linux heeft een GPL "vendor lock-in". De enige manier om dat te bereiken is vanaf 0 opnieuw beginnen.

[CyBeR]

CurlyMo schreef op vrijdag 26 februari 2016 @ 12:04:
[...]

Dat is simpelweg onmogelijk. Linux heeft een GPL "vendor lock-in".

Hoe bedoel je dat?

[CurlyMo]

CyBeR schreef op vrijdag 26 februari 2016 @ 12:05:
[...]


Hoe bedoel je dat?

Iedere individuele ontwikkelaar die ooit heeft bijgedragen heeft aan Linux daarmee moet instemmen. Het auteursrecht van een ontwikkelaar vervalt niet bij GPL.

De enige optie is het langzaam omzetten van code naar bijv. MPL door de ontwikkelaars die daarmee instemmen, waarmee je dus een dual licensed kernel krijgt met als hoofdlicentie GPL. Pas als alles MPL is, kan GPL verdwijnen (in de kernel).

[ Voor 27% gewijzigd door CurlyMo op 26-02-2016 12:11 ]

[CyBeR]

Oh bah, hebben ze geen copyright assignment verplicht daar? Dan krijg je dat soort shit idd.

[CurlyMo]

Moet je nagaan hoe evil GPL zou zijn geweest als ontwikkelaars hun auteursrecht zou verliezen

[Verwijderd]

CurlyMo schreef op vrijdag 26 februari 2016 @ 12:04:
Dat is simpelweg onmogelijk. Linux heeft een GPL "vendor lock-in". De enige manier om dat te bereiken is vanaf 0 opnieuw beginnen.

Dit probleem is niet nieuw en komt ook bij BSD voor. Zoals je misschien weet is bij BSD van een 3-clause license naar een 2-clause license gegaan. Daarbij zijn huidige copyright holders benaderd voor toestemming en zijn sommige delen herschreven van mensen waarvan geen toestemming ontvangen kon worden, zoals mensen die niet meer bereikbaar zijn.

Kortom, helemaal plotsklaps opnieuw beginnen is denk ik niet nodig. Je kunt beginnen met een meer permissive license en langzaam de bestaande code vervangen danwel de bestaande code de nieuwe license geven door de auteur te benaderen. Dit gebeurt wel vaker en is doorgaans geen heel groot probleem.

BSD op dit moment heeft ook nog steeds GPL code waar we nu pas in het stadium zijn dat de laatste restjes GPL code verwijderd/vervangen kan worden. Kortom, het gebeurt ook met zeer grote projecten zoals een heel operating system.

Interessant vind ik zelf dat waar BSD juist in een richting gaat van minder restricties (van 3 naar 2 restricties), Linux met GPLv3 en AGPL juist naar méér restricties beweegt. Dus het gat wordt alleen maar groter. BSD komt ook meer uit de academische wereld en daar is het fijn dat iets vrijwel 'public domain' is en je er dus alles mee kunt doen wat je wilt, behalve claimen dat jij de auteur bent. Dat is in feite waar de BSD 2-clause licentie op neer komt. En het standaard riedeltje van disclaimers dat je auteur niet verantwoordelijk zult houden als je hond in de fik vliegt door jouw code.

[CurlyMo]

Verwijderd schreef op vrijdag 26 februari 2016 @ 12:45:
[...]

Dit probleem is niet nieuw en komt ook bij BSD voor. Zoals je misschien weet is bij BSD van een 3-clause license naar een 2-clause license gegaan. Daarbij zijn huidige copyright holders benaderd voor toestemming en zijn sommige delen herschreven van mensen waarvan geen toestemming ontvangen kon worden, zoals mensen die niet meer bereikbaar zijn.

Kortom, helemaal plotsklaps opnieuw beginnen is denk ik niet nodig. Je kunt beginnen met een meer permissive license en langzaam de bestaande code vervangen danwel de bestaande code de nieuwe license geven door de auteur te benaderen. Dit gebeurt wel vaker en is doorgaans geen heel groot probleem.

Precies wat ik ook zeg in mijn later antwoord.

Mijn ideale licentie is op dit moment MPL. Je code mag opgenomen worden in closed source projecten, zelfs delen van je code, maar alle aanpassingen aan de code zelf moet open source blijven. MPL infecteert dus niet maar geeft ook niet al je code gewoon weg.

Binnenkort pilight maar eens dual licensed maken Eerder al wiringX omgezet van GPL naar MPL.

[CyBeR]

CurlyMo schreef op vrijdag 26 februari 2016 @ 12:44:
Moet je nagaan hoe evil GPL zou zijn geweest als ontwikkelaars hun auteursrecht zou verliezen

Dat zou geen GPL-verhaal zijn maar linux kernel policy. Je kunt prima van ontwikkelaars verwachten dat ze copyright overgeven aan het project bij een contributie, of in ieder geval dat ze er mee akkoord gaan dat de licentie zou kunnen veranderen.

Zonder dat is 't inderdaad compleet onmogelijk om een wijziging te doen.

[ Voor 22% gewijzigd door CyBeR op 26-02-2016 13:35 ]

[revox862]

Net een SSD toegevoegd als cache aan mijn ZFS pool. De export duurt heel lang nu. Klopt dat?

[Compizfox]

CurlyMo schreef op vrijdag 26 februari 2016 @ 10:52:
1. Door het client-side compileren van de module tegen de kernel broncode is een schending van GPLv2, maar deze wordt niet gepleegd door de distributeur, maar door de gebruiker. Die zet immers de compilatie in gang. (Het zou wel netjes zijn om de gebruiker van de schending op de hoogte te stellen bij het installeren van ZFS).

Het door de user linken van ZFS tegen Linux is geen GPL-schending. Het resultaat wordt immers niet uitgegeven.

Je mag gewoon 'thuis' van alles doen met je GPL-licensed code. De restricties zijn allemaal op het uitgeven ervan, dat mag alleen onder de GPL.

---

Paul schreef op vrijdag 26 februari 2016 @ 11:42:
[...]
Natuurlijk zien de open source aanhangers graag dat ik mijn software ook open source maak, maar mijn bedrijfsmodel is nu eenmaal het in licentie geven ("verkopen") van software. Je kunt als "open source"-club wel aangeven dat je graag hebt dat ik het gratis weggeef en geld vraag voor support, maar dan vraag ik me af wat de kwaliteit van je software is als je kunt leven van het oplossen van de problemen die er in zitten, want zoveel support aanvragen kreeg ik echt niet.

En ik wil best compenseren voor het gebruik van andermans werk, maar de prijs die men er bij de GPL voor vraagt is voor een closed source-bedrijf wel erg hoog...

Tja, dat is eigenlijk beetje het idee van de GPL: dat bedrijven die code niet zomaar kunnen 'jatten' en in hun proprietary software kunnen gebruiken. In dat opzicht doet de GPL dus precies waar het bedoeld voor is.

---

CyBeR schreef op vrijdag 26 februari 2016 @ 13:34:
[...]


Dat zou geen GPL-verhaal zijn maar linux kernel policy. Je kunt prima van ontwikkelaars verwachten dat ze copyright overgeven aan het project bij een contributie, of in ieder geval dat ze er mee akkoord gaan dat de licentie zou kunnen veranderen.

Zonder dat is 't inderdaad compleet onmogelijk om een wijziging te doen.

Jep, volgens mij doen ze dat bij GNU ook zo. Het versimpelt de boel enorm bij dit soort zaken.

[ Voor 61% gewijzigd door Compizfox op 27-02-2016 21:51 ]

[Paul]

Compizfox schreef op zaterdag 27 februari 2016 @ 21:44:
Tja, dat is eigenlijk beetje het idee van de GPL: dat bedrijven die code niet zomaar kunnen 'jatten'

Beetje jammer dat je het zo omschrijft. Je hebt zelfs het stuk waarin ik aangeef dat er iets tegenover mag staan niet weggeknipt uit je quote...

[Compizfox]

Paul schreef op zaterdag 27 februari 2016 @ 21:55:
[...]
Beetje jammer dat je het zo omschrijft. Je hebt zelfs het stuk waarin ik aangeef dat er iets tegenover mag staan niet weggeknipt uit je quote...

Ik leg alleen uit hoe het "FSF-kamp" het ziet. Meer niet.

Bovendien gaat het helemaal niet om een compensatie (ik ga er even van uit dat je een financiële compensatie bedoelt? ). Het gaat echt om het principe dat de GPL-licensed code alleen in vrije software gebruikt mag worden.

En lees ik het nou goed dat je het me kwalijk neemt dat ik je quote niet buiten context neem?

[ Voor 21% gewijzigd door Compizfox op 28-02-2016 00:05 ]

[Paul]

Je hebt de quote inderdaad niet verqloot, maar de inhoud wel Je had net zo goed die laatste zin niet mee hoeven quoten zo

Ik ben verre van tegen open source, maar het virale (en de mindset die er aan vastzit) aan GPL zit me wel dwars; het is vaak helemaal niet aan mij om de licentievorm van de software waar ik aan ontwikkelde te bepalen, maar ik mocht wel het probleem oplossen. Doe dan maar de LGPL... En natuurlijk is er dan iets als http://www.gnu.org/licenses/why-not-lgpl.html

Twee dingen vallen daarin al direct op:

Proprietary software developers have the advantage of money

Euhm, dat valt erg tegen... Wil je de jaarrekeningen zien? Niet iedereen is een Google of Facebook

There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.

Ik kom vaak juist op een open source iets uit wanneer die "alternative libraries" juist niet bestaan of achterlijk duur zijn. Als een licentie net zo duur is als het zelf ontwikkelen [waarbij ik alle uren tegen commercieel tarief wegzet] dan is je library achterlijk duur... En natuurlijk is "hun" doel zorgen dat er meer "vrije software" komt, maar daar heb ik in die situatie niks aan En dan is het erg frustrerend dat je daar een hele mooie oplossing ziet voor het probleem waar je niet uit komt, maar die oplossing is net zo onbereikbaar als wanneer deze zich op de maan had bevonden. En het is technisch zoooo simpel om 'even' die include toe te voegen en het toch te gebruiken. Maar ja, dat is tegen de licentie en dus doe je dat niet

Gelukkig maar twee keer in zo'n situatie gezeten, maar nooit als 'eigenaar' van de code. Zelfs al zou ik willen dan nog mocht ik het niet publiceren. En ook al waren we strict genomen zelf de eigenaar van de code, de klant was er ook niet blij mee geweest als de code van hun maatwerk 'op straat' zou liggen. Probleem dus ook maar op het bordje van mijn leidinggevende geschoven Volgens mij hebben we een keer zelf iets ontwikkeld en de andere keer toch iets gekocht.

Maar goed, dat gaat wel erg ver van het onderwerp "ZFS" af Ik ben overigens ook al een jaar of 7 geen programmeur meer

[Compizfox]

Paul schreef op zaterdag 27 februari 2016 @ 22:20:
[...]
Ik kom vaak juist op een open source iets uit wanneer die "alternative libraries" juist niet bestaan of achterlijk duur zijn. Als een licentie net zo duur is als het zelf ontwikkelen [waarbij ik alle uren tegen commercieel tarief wegzet] dan is je library achterlijk duur...

Dat is ook precies wat dat artikel duidelijk probeert te maken. Volgens de FSF is het alleen een beter idee om de LGPL te gebruiken voor een library (in plaats van de GPL) als er 'concurrenten' zijn die de populariteit van library in kwestie kunnen hinderen. Met andere woorden: library A is in GPL, maar er is een alternatieve library B die hetzelfde doet maar onder een permissive license staat. Developers van proprietary software die zo'n library zoeken pakken dan gewoon library B. In zo'n geval raadt de FSF aan om de LGPL te gebruiken, zodat library A niet teveel lijdt onder de concurrentie van library B.

In gevallen dat die alternatieven er niet zijn, is er geen concurrentie voor de library en kan dus het beste gewoon de GPL gebruikt worden.

Begrijp wel dat het motief achter dit alles allemaal het zoveel mogelijk verspreiden van vrije software is.

Paul schreef op zaterdag 27 februari 2016 @ 22:20:
En natuurlijk is "hun" doel zorgen dat er meer "vrije software" komt, maar daar heb ik in die situatie niks aan

Dit is precies waar het hem zit. De FSF wil graag dat er zoveel mogelijk vrije software komt. Het liefst alles eigenlijk. Vanuit dat oogpunt doet de GPL precies wat het moet doen, dat is wat ik probeer uit te leggen

[ Voor 60% gewijzigd door Compizfox op 28-02-2016 00:12 ]

[Paul]

Dat zeg ik toch?

[revox862]

revox862 schreef op zaterdag 27 februari 2016 @ 21:14:
Net een SSD toegevoegd als cache aan mijn ZFS pool. De export duurt heel lang nu. Klopt dat?

Voor de mensen die in spanning aan het meeleven zijn. De export is nog steeds niet klaar.

[Verwijderd]

revox862 schreef op zondag 28 februari 2016 @ 20:53:
[...]

Voor de mensen die in spanning aan het meeleven zijn. De export is nog steeds niet klaar.

Welk OS, heb je disk activiteit? Welke staat bevindt het export commando zich - is dat toevallig KMEM ARENA?

[revox862]

Alleen activiteit op de cache.

code:

FreeBSD zfsfractal.local 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 UTC 2016     [e-mail]:/usr/obj/usr/src/sys/GENERIC  amd64

  pool: uber
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 0 in 0h0m with 0 errors on Wed Dec 16 15:55:38 2015
config:

        NAME                    STATE     READ WRITE CKSUM
        uber                    ONLINE       0     0     0
          raidz2-0              ONLINE       0     0     0
            gpt/W1F234YT        ONLINE       0     0     0
            gpt/W1F21ZGX        ONLINE       0     0     0
            gpt/W1F236V8        ONLINE       0     0     0
            gpt/W1F1YSQY        ONLINE       0     0     0
            gpt/W1F1V3PK        ONLINE       0     0     0
            gpt/W500QVFJ        ONLINE       0     0     0
        cache
          gpt/1533105F8611.nop  ONLINE       0 11.7M     0

errors: No known data errors

                           capacity     operations    bandwidth
pool                    alloc   free   read  write   read  write
----------------------  -----  -----  -----  -----  -----  -----
uber                    11.7T  4.53T      0      0      0      0
  raidz2                11.7T  4.53T      0      0      0      0
    gpt/W1F234YT            -      -      0      0      0      0
    gpt/W1F21ZGX            -      -      0      0      0      0
    gpt/W1F236V8            -      -      0      0      0      0
    gpt/W1F1YSQY            -      -      0      0      0      0
    gpt/W1F1V3PK            -      -      0      0      0      0
    gpt/W500QVFJ            -      -      0      0      0      0
cache                       -      -      -      -      -      -
  gpt/1533105F8611.nop  3.25G  96.7G     11     30  94.3K  1.77M
----------------------  -----  -----  -----  -----  -----  -----

root   71277   0.0  0.0  40176  2836  1  D+   Sat07PM     0:00.12 zpool export uber

# procstat -kk 71277
  PID    TID COMM             TDNAME           KSTACK
71277 100655 zpool            -                mi_switch+0xe1 sleepq_wait+0x3a _sleep+0x287 clnt_vc_create+0x1bd clnt_reconnect_call+0x2af newnfs_request+0xa8c nfscl_request+0x72 nfsrpc_statfs+0x1f3 nfs_statfs+0x1a4 __vfs_statfs+0x1e kern_getfsstat+0x308 amd64_syscall+0x357 Xfast_syscall+0xfb

D+ is dat KMEM ARENA waar je het over hebt?

Edit1: Kan het te maken hebben met twee niet umounted NFS volumes die niet meer bestaan?

Edit2: Antwoord op mijn eigen vraag is ja. Toen de NFS volumes terug kwamen was alles unstuck.

Edit3: zpool export geeft nu een device busy. Heeft dit met de nieuwe cache te maken?

Edit4: Na een zpool export -f, zpool import en zpool clear was alles weer normaal.
Echter nu heb ik een kernel panic gehad omdat ik die gnop heb verwijdert. Gaat lekker
Na de reboot een zpool import gedaan en alles is weer goed.

Bedankt CiPHER

[ Voor 15% gewijzigd door revox862 op 28-02-2016 22:35 ]

[Compizfox]

revox862 schreef op zondag 28 februari 2016 @ 21:49:
D+ is dat KMEM ARENA waar je het over hebt?

Edit1: Kan het te maken hebben met twee niet umounted NFS volumes die niet meer bestaan?

Edit2: Antwoord op mijn eigen vraag is ja. Toen de NFS volumes terug kwamen was alles unstuck.

D betekent uninterruptable sleep, en dat wil inderdaad nog wel eens gebeuren door onbereikbare NFS-mounts.

[revox862]

Compizfox schreef op zondag 28 februari 2016 @ 23:44:
[...]

D betekent uninterruptable sleep, en dat wil inderdaad nog wel eens gebeuren door onbereikbare NFS-mounts.

Weer wat geleerd

[FireDrunk]

Goed, maar eens een update over mijn Fibre Channel icm ZFS avontuur.

Na begin van de week getest te hebben dat een ZFS Snapshot verplaatsen over een Block Device gaat,
gister eindelijk eens proberen een daadwerkelijke backup te maken.

Eerst maar een extra ZVOL gemaakt op mijn SSD array en geprobeerd daar een backup naar te maken.
Blijkbaar als je van de ene naar de andere ZVOL backupped, moet je opletten met de REFRESERVED waardes. Anders ga je dus nat.

Na dat uitgezet te hebben, kon ik de backup starten. Na een uur liep deze toch vast met de melding dat er te weinig ruimte was, terwijl er op beide ZVOL's (en de pool) nog 100G vrij was... Vreemd verhaal.

Dan maar een backup naar mijn Disk array. Dus een LUN gemaakt op mijn array en daar de backup naartoe geplempt. Dit werkte prima (beetje traag, maar oke ).

Daarna de LUN op mijn disk array geshared via Fibre Channel en aan de slag met het restoren op de tweede machine.

Eerste restore poging: 122MB/s... Hmm dat is traag, de Fibre Channel link trekt toch echt > 400MB/s
mbuffer er tussen gepropt, 11MB/s
dd er tussen, 11-22MB/s

Wat blijkt, de Celeron G1610T die er in zit, en de 3GB geheugen spelen de restore toch wel parten...
Ik zag af en toe een load van ~4 (op een dual core), en het geheugen zat relatief vol.

Blijkbaar is Fibre Channel, ZFS en Snapshots terugzetten naar een nieuwe array toch een beetje teveel van het goede voor een MicroServer Gen8
De eerste restore poging was welliswaar 120MB/s maar had wel ernstig last van breathing.

[narotic]

Vreemd, die Celeron G1610T is zo traag ook weer niet en ik zou verwachten dat ie toch makkelijk een paar Gbit/s zou kunnen trekken. Ik heb geen ervaring met FC, maar het lijkt me dat het niet veel belastender voor de CPU zou moeten zijn dan ethernet.

Hoe stuur je de data over het netwerk: ssh, iscsi, nfs, smb? En wat is de configuratie van de destination pool wat betreft compressie en dedup?

[Q]

Haal je die 400 MB/s ook echt tussen je Gen8 en je storage array? Wat doet een kale dd naar je FC lun zoals gemount op de Gen8?

[BCC]

Wordt er niet heel veel geoffload op de CPU door een goedkope netwerkkaart of raid kaart?

[Bigs]

Ik heb wel eens gelezen dat FC target mode in FreeBSD veel meer CPU gebruikt dan in initiator mode (2-3x zoveel interrupts). Volgens mij kun je daar niet veel aan doen. Gebruik van MSI-X of MSI zou moeten schelen als je hardware dat ondersteunt.

[Compizfox]

BCC schreef op maandag 29 februari 2016 @ 13:30:
Wordt er niet heel veel geoffload op de CPU door een goedkope netwerkkaart of raid kaart?

Dit is ZFS, dus het "RAID" draait sowieso in software. En hij gebruikt Fibre Channel in plaats van Ethernet

[BCC]

Compizfox schreef op maandag 29 februari 2016 @ 15:11:
[...]
Dit is ZFS, dus het "RAID" draait sowieso in software. En hij gebruikt Fibre Channel in plaats van Ethernet

Ok ok: wordt de CPU niet onnodig belast door een SATA/SCSI controller / Fibre Channel kaart die al het werk offload op de CPU?

[FireDrunk]

Goed, na een avond vol frustratie om mijn setup weer terug te krijgen hoe hij was krijg ik dit:

http://www.spinics.net/lists/target-devel/msg11960.html

(Niet mijn thread, wel hetzelfde probleem, vage TASK canceled meldingen...)

Ineens ziet mijn client maar 2 LUN's over 2 FC verbindingen, terwijl hij dus eigenlijk 2x2 zou moeten zien (er zijn immers twee poorten die dezelfde lun presenteren).

Al diverse malen gereboot en vanalles herstart, maar het ding blijft moeilijk doen....

Twijfel of de kaartjes zelf wel in orde (lijken te) zijn...

De Fibre Channel kaartjes kosten zelf amper CPU (het zijn Emulex LPE11000's als client, en QLogic 2462 als Host mocht je het willen weten ).

De CPU load zat vooral in DD en mbuffer zelf. Daarnaast veel zio_txg groepen door ZFS die (waarschijnlijk) niet snel genoeg naar disk kan flushen.

EDIT: Hmm, ik verwissel een keer een glaskabeltje met een andere, ziet het ding wel ineens lun's, en dat terwijl hij via /sys (via de driver) gewoon aan gaf dat de link online was... vage shit...

[ Voor 11% gewijzigd door FireDrunk op 29-02-2016 20:19 ]

[F-Tim]

Kan iemand me helpen met de Samba configuratie en de koppeling met Mac OSX?

Ik heb heel eenvoudig een groep aangemaakt (Thuis), met daarin 2 gebruikers (Hij en Zij), de gebruikers zijn beiden lid van de groep.

Vervolgens 3 file systems (Data, Media, Memories) aangemaakt, met daar tegenaan een directe Samba share. Op 2 van de 3 shares (Data en Memories) heeft alleen de groep read/write rechten op, verder géén guest access. Op 1 van de 3 shares (Media) is public met zelfs guest read/write.

Op Windows kan ik prima inloggen met gebruikers Hij en Zij, en ook in alle 3 de shares de bestanden lezen en schrijven.

Op OSX kan ik wél inloggen op de NAS met de gebruiker (cq. de authenticatie wordt geaccepteerd, verkeerde wachtwoorden worden geweigerd), maar vervolgens wordt de inhoud van de Private shares geweigerd en krijg ik de foutmelding dat het pad niet kan worden gevonden.
De Public share met guest R/W wordt wél gewoon geopend. Het werkt identiek als ik niet inlog met een account en dus gebruik maak van een guest account.

Verbinding met de server is gemaakt door middel van in Finder de NAS aan te klikken in de zijbalk én door middel van "Verbind met server" in de menu's en dan de smb://NAS als URL in te vullen, vervolgens worden na inloggen ook netjes de diverse shares getoond. Echter bij het kiezen van de private share's wederom de foutmelding dat het pad niet kan worden gevonden.

Na wat googlen kwam ik erachter dat sinds nieuwere OSX versies automatisch gebruikt maakt van het SMB2 protocol en de oplossing was door cifs://NAS te gebruiken in het Verbinden met server menu, echter werkt dit ook niet.

Ik heb het al proberen op te lossen door de Authentication back-end aan te passen aan de kant van de NAS, van standaard TDB SAM naar LDAP SAM en smbpasswd (legacy).
De switch naar smbpasswd levert overigens een bug op in de UI waarbij de dropdown gevuld wordt met TDB SAM, terwijl in de smb.conf wél de setting op smbpasswd staat

Maar zodra ik de authenticatie backend wijzig kan ik bij LDAP SAM helemaal niet meer inloggen (óók niet vanaf een Windows machine), en bij smbpasswd werkt op Windows ook enkel de public share.

Waar doe ik iets fout? En nog veel belangrijker, hoe kan ik het fixen voor alle aangesloten devices? Ik gok namelijk dat zodra het goed werkt op Windows én OSX dat het ook automatisch werkt op diverse iOS apps én de Asus AiCloud app.

[FireDrunk]

Als je de backend naar smbpasswd zet, moet je voor elke user een smb password aanmaken dmv commando:

smbpasswd -a Hij
smbpasswd -a Zij

Daarna kan je waarschijnlijk wel inloggen.

Goede kans dat het niet werkt omdat Mac OS X andere User ID's heeft voor dezelfde users als je op je share hebt. Lokale ID's moeten op POSIX systemen matchen als ze over SMB communiceren volgens mij(of je moet het via mount opties rechttrekken). Onder Windows is dat niet zo.

[ Voor 5% gewijzigd door FireDrunk op 01-03-2016 08:27 ]

[CyBeR]

Nee dat is niet zo met smb, dat geldt alleen voor NFS3 en lager.

[FireDrunk]

Ik heb toch wel echt meegemaakt dat mijn Gnome shell weigerde files te openen omdat de rechten op de share gehandhaafd werden...

[CyBeR]

De rechten op de share worden ook gehandhaafd. Door de server. Met je server-local uid/gid.

[idef1x]

Ik heb laatst vanuit een snapshot een file gerestored, door simpel naar de hidden .zfs directory te gaan, maar zie nu dat deze snapshot gemount is. Een zfs unmount werkt niet, maar een unmount <mountdir> wel.
Doch na een reboot komen ze weer vrolijk gemount terug:

$ cat /proc/mounts
data/HOME@2016.02.04-Thursday /data/HOME/.zfs/snapshot/2016.02.04-Thursday zfs ro,relatime,xattr,noacl 0 0
data/HOME@2016.02.05-Friday /data/HOME/.zfs/snapshot/2016.02.05-Friday zfs ro,relatime,xattr,noacl 0 0

Enig idee hoe ze permanent te unmounten? Het is met zfsonlinux op Ubuntu 14.04

[FireDrunk]

Is dat niet een zfs property? iets met snapdir?

[narotic]

De snapshot zou automatisch gemount en geunmount moeten worden. Heb je gecontrolleerd of er niet toevallig nog een programma iets in de snapshot dir open heeft staan? Bijvoorbeeld

lsof | grep snapshot

[CurlyMo]

De .zfs is geen feitelijke directory, maar een speciale directory om de snapshots te "zien". Het OS ziet het dus ook niet zo. De snapdir property zoals aangedragen door FireDrunk is hier de oplossing.

Onafhankelijk van die property kan je nog steeds handmatig naar de .zfs folder gaan als je dat forceert, bijv.:

code:

cd /data/.zfs

Echter, bij invisible zie je de folder niet meer bij een ls -Al

[idef1x]

De zfs property staat op hidden (default) en zie hem inderdaad niet met ls -Al.

lsof |grep snapshot levert geen resultaat, dus dat zou het ook niet kunnen zijn (en dan zou het na een reboot toch weg moeten zijn?)

Misschien komt het omdat ik naar de hidden .zfs directory ben gegaan ipv de snapshot mounten en dan de file restoren?

Heb net even het github issue gelezen en daaruit maak ik op dat er toch nog ergens een process moet zijn die van tijd tot tijd er gebruik van maakt, want ik zag net even geleden dat 1 snapshot van de 2 wel geunmount was (de expiry van 300 seconden gok ik), maar nu weer gemount is...Hmmm vaag...dat wordt puzzelen wie dat veroorzaakt...

Bedankt voor de tips in ieder geval

[narotic]

Voor zover ik weet is naar de .zfs directory gaan juist de aangeraden manier om files te restoren bij ZFS. Voor mij is het in ieder geval een van de redenen dat ik ZFS verkies boven BTRFS.

[CurlyMo]

Zoals eerder in het topic vermeld herstructureer ik de .zfs snapshots via symlinks zodat ze netjes worden gepresenteerd voor eindgebruiker. Dan kan die zelf bestanden uit de snapshots terughalen of er doorheen bladeren. Andere presenteren die folder weer via "previous versions" in windows.

[idef1x]

narotic schreef op dinsdag 01 maart 2016 @ 13:59:
Voor zover ik weet is naar de .zfs directory gaan juist de aangeraden manier om files te restoren bij ZFS. Voor mij is het in ieder geval een van de redenen dat ik ZFS verkies boven BTRFS.

Wat is het verschil met BTRFS dan? Daarbij mount ik de root ook en maak snapshots vanuit die root die je ook "gewoon" kan doorbladeren als je dat wilt?

[FireDrunk]

Je *kan* volgens mij een snapshot ook expliciet mounten als je dat zou willen.

Denk bijvoorbeeld aan het volgende:

Je hebt een /pool/users filesystem, je maakt van het hele filesystem snapshots.
Deze zouden dan te zien zijn in /pool/users/.zfs/

Dat is onhandig als beheerder, want als 1 user een file terug wil, moet jij als beheerder naar die directory gaan.

Beter is dan te doen:

/pool/users/user_a/.zfs -> ../.zfs/@latest/user_a

Dan kan user_a in zijn eigen directory de contents zien van het snapshot/user_a

[narotic]

idef1x schreef op dinsdag 01 maart 2016 @ 14:09:
[...]

Wat is het verschil met BTRFS dan? Daarbij mount ik de root ook en maak snapshots vanuit die root die je ook "gewoon" kan doorbladeren als je dat wilt?

Dus je houdt de root volume altijd ergens gemount? Dat helpt, maar is helaas niet default.

Het zal grotendeels zijn omdat ik ZFS langer en beter ken dan BTRFS, maar ik vind het natuurlijker dat de snapshots toegankelijk zijn relatief aan het pad waar je bent. Dus een restore kan compact als:

cp {.zfs/snapshot/somesnapshot/,}somepath/somefile

@FireDrunk
In dat scenario lijkt het me makkelijker om per user een filesystem te maken. Op die manier kun je ook quota's e.d. fatsoenlijk regelen en kunnen users bij alle snapshots.

[ Voor 14% gewijzigd door narotic op 01-03-2016 15:05 ]

[idef1x]

narotic schreef op dinsdag 01 maart 2016 @ 14:58:
[...]

Dus je houdt de root volume altijd ergens gemount? Dat helpt, maar is helaas niet default.

Inderdaad is niet de default, maar de default is minder mooi om snapshots te maken want die komen dat onder je root dataset te hangen (bijvoorbeeld /tank/MyHome/.snapshots/latest oid).
Vandaar dat ik de root btrfs gemount hou.

Het zal grotendeels zijn omdat ik ZFS langer en beter ken dan BTRFS, maar ik vind het natuurlijker dat de snapshots toegankelijk zijn relatief aan het pad waar je bent. Dus een restore kan compact als:

cp {.zfs/snapshot/somesnapshot/,}somepath/somefile

mee eens

FireDrunk schreef op dinsdag 01 maart 2016 @ 14:55:
Je *kan* volgens mij een snapshot ook expliciet mounten als je dat zou willen.

Bottom line: als het kan hoeft het niet, dus mijn gemounte snapshots komen niet doordat ik gewoon door de hidden snapshot dir bladerde

[FireDrunk]

Er is een zfs-mount service tegenwoordig, je zou eens kunnen kijken of daar niet toevallig dingen in zitten die automatisch snapshots mounten.

EDIT: Ik lees veel over Automount support, ik gok dus dat de Linux ZFS implementatie dit dus inderdaad automagisch doet

https://github.com/zfsonlinux/zfs/issues/3963

Ah, er zijn meer mensen die die optie willen

[ Voor 15% gewijzigd door FireDrunk op 01-03-2016 15:52 ]

[FireDrunk]

Zojuist een extra PC gepakt waar wel 2 FC kaartjes in kunnen om zo eens 4 links tegelijk te gebruiken.
ESXi op geinstalleerd, en eens kijken. Zie maar op 1 van de 4 poorten LUN's ipv op 2 (want de andere 2 hadden nog geen ACL's).

Andere WWID's toegevoegd aan de FC Host, en ineens zie ik dus op 3/4 kaartjes LUN's.

Raar, maar afijn, eerst maar eens testen. Round Robin policy aangezet, IOPS=1 op de LUN, en een VM gedeployed vanuit VC.

En dan zie je ineens dit:

[84436.132676]  [<ffffffff810bedf8>] kthread+0xd8/0xf0
[84436.132677]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132679]  [<ffffffff81782b5f>] ret_from_fork+0x3f/0x70
[84436.132681]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132683] Bit_5 already set for cmd = ffff880914ba3c40.
[84436.132750] CPU: 0 PID: 7157 Comm: kworker/0:10 Tainted: P           OE   4.3.6-201.fc22.x86_64 #1
[84436.132751] Hardware name: Supermicro Super Server/X10SRH-CLN4F, BIOS 1.0c 09/14/2015
[84436.132756] Workqueue: events target_qf_do_work [target_core_mod]
[84436.132757]  0000000000000000 00000000361fbc5a ffff88091007bdb0 ffffffff813a6caf
[84436.132758]  ffff880914ba3c40 ffff88091007bdc8 ffffffffa0697927 ffff88091007bd80
[84436.132760]  ffff88091007be18 ffffffffa08ae400 ffff88091007bdd8 ffff88091007bdd8
[84436.132761] Call Trace:
[84436.132763]  [<ffffffff813a6caf>] dump_stack+0x44/0x55
[84436.132765]  [<ffffffffa0697927>] tcm_qla2xxx_queue_status+0xf7/0x110 [tcm_qla2xxx]
[84436.132770]  [<ffffffffa08ae400>] target_qf_do_work+0x1f0/0x2d0 [target_core_mod]
[84436.132771]  [<ffffffff810b8cee>] process_one_work+0x19e/0x3f0
[84436.132773]  [<ffffffff810b8f8e>] worker_thread+0x4e/0x450
[84436.132774]  [<ffffffff810b8f40>] ? process_one_work+0x3f0/0x3f0
[84436.132776]  [<ffffffff810bedf8>] kthread+0xd8/0xf0
[84436.132778]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132779]  [<ffffffff81782b5f>] ret_from_fork+0x3f/0x70
[84436.132781]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132784] Bit_5 already set for cmd = ffff880914ba3c40.
[84436.132850] CPU: 0 PID: 7157 Comm: kworker/0:10 Tainted: P           OE   4.3.6-201.fc22.x86_64 #1
[84436.132851] Hardware name: Supermicro Super Server/X10SRH-CLN4F, BIOS 1.0c 09/14/2015
[84436.132856] Workqueue: events target_qf_do_work [target_core_mod]
[84436.132857]  0000000000000000 00000000361fbc5a ffff88091007bdb0 ffffffff813a6caf
[84436.132859]  ffff880914ba3c40 ffff88091007bdc8 ffffffffa0697927 ffff88091007bd80
[84436.132860]  ffff88091007be18 ffffffffa08ae400 ffff88091007bdd8 ffff88091007bdd8
[84436.132862] Call Trace:
[84436.132863]  [<ffffffff813a6caf>] dump_stack+0x44/0x55
[84436.132865]  [<ffffffffa0697927>] tcm_qla2xxx_queue_status+0xf7/0x110 [tcm_qla2xxx]
[84436.132870]  [<ffffffffa08ae400>] target_qf_do_work+0x1f0/0x2d0 [target_core_mod]
[84436.132872]  [<ffffffff810b8cee>] process_one_work+0x19e/0x3f0
[84436.132873]  [<ffffffff810b8f8e>] worker_thread+0x4e/0x450
[84436.132875]  [<ffffffff810b8f40>] ? process_one_work+0x3f0/0x3f0
[84436.132877]  [<ffffffff810bedf8>] kthread+0xd8/0xf0
[84436.132878]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132880]  [<ffffffff81782b5f>] ret_from_fork+0x3f/0x70
[84436.132881]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132884] Bit_5 already set for cmd = ffff880914ba3c40.
[84436.132951] CPU: 0 PID: 7157 Comm: kworker/0:10 Tainted: P           OE   4.3.6-201.fc22.x86_64 #1
[84436.132952] Hardware name: Supermicro Super Server/X10SRH-CLN4F, BIOS 1.0c 09/14/2015
[84436.132957] Workqueue: events target_qf_do_work [target_core_mod]
[84436.132958]  0000000000000000 00000000361fbc5a ffff88091007bdb0 ffffffff813a6caf
[84436.132959]  ffff880914ba3c40 ffff88091007bdc8 ffffffffa0697927 ffff88091007bd80
[84436.132961]  ffff88091007be18 ffffffffa08ae400 ffff88091007bdd8 ffff88091007bdd8
[84436.132962] Call Trace:
[84436.132964]  [<ffffffff813a6caf>] dump_stack+0x44/0x55
[84436.132966]  [<ffffffffa0697927>] tcm_qla2xxx_queue_status+0xf7/0x110 [tcm_qla2xxx]
[84436.132971]  [<ffffffffa08ae400>] target_qf_do_work+0x1f0/0x2d0 [target_core_mod]
[84436.132972]  [<ffffffff810b8cee>] process_one_work+0x19e/0x3f0
[84436.132974]  [<ffffffff810b8f8e>] worker_thread+0x4e/0x450
[84436.132975]  [<ffffffff810b8f40>] ? process_one_work+0x3f0/0x3f0
[84436.132977]  [<ffffffff810bedf8>] kthread+0xd8/0xf0
[84436.132979]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132980]  [<ffffffff81782b5f>] ret_from_fork+0x3f/0x70
[84436.132982]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.132985] Bit_5 already set for cmd = ffff880914ba3c40.
[84436.133051] CPU: 0 PID: 7157 Comm: kworker/0:10 Tainted: P           OE   4.3.6-201.fc22.x86_64 #1
[84436.133052] Hardware name: Supermicro Super Server/X10SRH-CLN4F, BIOS 1.0c 09/14/2015
[84436.133057] Workqueue: events target_qf_do_work [target_core_mod]
[84436.133058]  0000000000000000 00000000361fbc5a ffff88091007bdb0 ffffffff813a6caf
[84436.133059]  ffff880914ba3c40 ffff88091007bdc8 ffffffffa0697927 ffff88091007bd80
[84436.133061]  ffff88091007be18 ffffffffa08ae400 ffff88091007bdd8 ffff88091007bdd8
[84436.133062] Call Trace:
[84436.133064]  [<ffffffff813a6caf>] dump_stack+0x44/0x55
[84436.133066]  [<ffffffffa0697927>] tcm_qla2xxx_queue_status+0xf7/0x110 [tcm_qla2xxx]
[84436.133071]  [<ffffffffa08ae400>] target_qf_do_work+0x1f0/0x2d0 [target_core_mod]
[84436.133073]  [<ffffffff810b8cee>] process_one_work+0x19e/0x3f0
[84436.133084]  [<ffffffff810b8f8e>] worker_thread+0x4e/0x450
[84436.133087]  [<ffffffff810b8f40>] ? process_one_work+0x3f0/0x3f0
[84436.133089]  [<ffffffff810bedf8>] kthread+0xd8/0xf0
[84436.133090]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160
[84436.133092]  [<ffffffff81782b5f>] ret_from_fork+0x3f/0x70
[84436.133094]  [<ffffffff810bed20>] ? kthread_worker_fn+0x160/0x160

En dit:



Denk toch dat 1 van die kaartjes een beetje heen is...

[rikadoo]

Wat voor kaartjes zijn het? En zitten er geen losse gbic modules in? Die gaan nog wel eens stuk...

[FireDrunk]

Host heeft 2 stuks QLogic QLE2462's, Client heeft 2 * Emulex LPE11000's
Beide hebben ingebouwde GBIC's.

Allergrootste irritatie is nog wel dat FC en iSCSI door dezelfde kernel modules gaan. Wat op zich qua configuratie wel leuk is (minder werk), maar als FC hangt, heeft iSCSI daar ook last van.

Best onhandig als je VC op iSCSI draait...

[ Voor 72% gewijzigd door FireDrunk op 01-03-2016 20:25 ]

[cyspoz]

Gisteren avond een beetje vreemde ervaring met mijn FreeNAS deployment. Ik hoorde dat er iets niet goed was met een schijf die een enorm ratelend geluid maakte wat klonk als iets dat tegen de platters aan zat en bovendien hoorde ik de schijf kop continue resetten.
Tot mijn verbazing was er volgens FreeNAS nog niets aan de hand en waren alle volumes nog healthy. Mogelijk omdat er geen I/O plaats vond, maar toch. Ben toen de defecte schijf gaan opzoeken, wat erg makkelijk was, namelijk de warmste van allemaal. Dus kort voelen was genoeg om hem te vinden en af te koppelen. Ik had nog een nieuwe schijf liggen, dus deze geplaatst maar kreeg via de GUI geen replacement uitgevoerd:

code:

Error: Disk replacement failed: "invalid vdev specification, use '-f' to override the following errors:, /dev/gptid/3417822c-e188-11e5-b2c7-0cc47a6c12ea is part of potentially active pool 'Volume1'"

Vanmorgen via de cmd line zpool replace uitgevoerd zonder -f en dat werkte meteen. Kan dit mogelijk komen omdat de schijf een andere grote heeft, 2TB i.p.v. 1,5TB?

Update
Inmiddels is de resilvering compleet maar staat de nieuwe schijf niet als GPTID er bij. Maakt dat nog iets uit?

code:

  pool: Volume2                                                                                                                     
 state: ONLINE                                                                                                                      
  scan: resilvered 691G in 2h44m with 0 errors on Fri Mar  4 09:25:05 2016                                                          
config:                                                                                                                             
                                                                                                                                    
        NAME                                            STATE     READ WRITE CKSUM                                                  
        Volume2                                         ONLINE       0     0     0                                                  
          raidz2-0                                      ONLINE       0     0     0                                                  
            gptid/efd860ff-c852-11e5-9461-0cc47a6c12ea  ONLINE       0     0     0                                                  
            gptid/f0f04bb6-c852-11e5-9461-0cc47a6c12ea  ONLINE       0     0     0                                                  
            gptid/f29268d8-c852-11e5-9461-0cc47a6c12ea  ONLINE       0     0     0                                                  
            gptid/f39342c2-c852-11e5-9461-0cc47a6c12ea  ONLINE       0     0     0                                                  
            da3                                         ONLINE       0     0     0

[ Voor 48% gewijzigd door cyspoz op 04-03-2016 10:02 ]

[FireDrunk]

Heb je de nieuwe schijf eerst met GPT geformatteerd?

[Compizfox]

Zo te zien is de schijf op basis van zijn normale device label toegevoegd in plaats van op basis van GPT label.

[FireDrunk]

Jup, dat dacht ik ook....

[cyspoz]

Nee niet gedaan. Heb uberhaubt niet gekeken of er iets nog op stond. Maakt het nog uit of kan ik het gewoon zo laten?

[FireDrunk]

Het is niet echt best-practice om hele disks aan ZFS te geven via hun device node. Het *kan* in theorie wel, maar netjes is anders.

Beter was geweest om de disk eerst te partitioneren, en te labelen, en daarna de disk via zijn GPT Partitie label toe te voegen aan ZFS (of te replacen).

Nu kan je niet meer terug.

[CurlyMo]

FireDrunk schreef op vrijdag 04 maart 2016 @ 10:33:
Nu kan je niet meer terug.

Waarom niet. Hij kan toch de disk offline halen, fixen en weer aan de pool toevoegen. Het is immer een RAIDZ2.

[FireDrunk]

Als hij de disk partitioneert wordt hij toch kleiner? Ik zat te denken dat ZFS dan gaat klagen dat de disk waarmee je replaced kleiner is dan wat er oorspronkelijk stond.

[CurlyMo]

Het gaat hier over een 2TB in een pool van 1.5TB schijven. Dus dat is geen probleem.

[Q]

Het is niet permanent, als je een device als /dev/sda toevoegde in plaats van /dev/disk/by-id/wwn-bljljlkjlkjwefwelfkj dat is niet erg.

Je kunt je pool mounten onder Linux op iedere manier die je wilt.

De stomme manier: via /dev/sd?
De betere manieren:

via /dev/disk/by-id
via /dev/disk/by-path

Onder linux moet je deze file ff openen:

/etc/default/zfs

code:

# Any additional option to the 'zfs import' commandline?
# Include '-o' for each option wanted.
# You don't need to put '-f' in here, unless you want it ALL the time.
# Using the option 'zfsforce=1' on the grub/kernel command line will
# do the same, but on a case-to-case basis.
ZPOOL_IMPORT_OPTS="-d /dev/disk/by-path"

[ Voor 10% gewijzigd door Q op 04-03-2016 11:14 ]

[Verwijderd]

Wat is de reden dat jullie disks opgeven en niet GPT partities?

[FireDrunk]

cyspoz in "Het grote ZFS topic"

[Verwijderd]

Ja, dus? Dat is misschien een FreeNAS probleem. Maar hij had toch evengoed een zpool replace commando kunnen gebruiken met de GPT partitie ipv raw device node? Dat lijkt mij bad practise.

[FireDrunk]

Dat is de reden, niets meer en niets minder. Dat het bad practice is, had ik al gemeld...

[Verwijderd]

Ik reageerde ook vooral op Q; in die zin dat het op mij overkwam alsof er device nodes worden aanbevolen, ipv partities. Dat laatste lijkt mij altijd beter.

Over de grootte: als hij op alle disks GPT partities gebruikt dan is de raw device node juist groter. Dus ook al was de disk 1.5TB had hij prima de disk offline kunnen halen, gpt partities kunnen maken en weer toevoegen aan de pool met een replace commando. Dat lijkt mij het beste dat hij nu kan doen.

[cyspoz]

Thanks voor de discussie en best practice advies. Ik ga de disk offline halen, maak één grote 2TB GPT partitie er op aan, en replace vervolgens de "oude versie van zichzelf" in de pool met

code:

zfs replace /dev/da3 gptid/{GUID}

[Verwijderd]

Dat lijkt mij beter ja. Dan heb je alle devices als partities. Ik zelf vind partitie labels veel beter dan partitie IDs, maar FreeNAS werkt volgens mij uitsluitend met IDs. Dus dat kun je dan denk ik beter zo aanhouden.

PS. het is zpool replace, niet zfs replace.

[ Voor 10% gewijzigd door Verwijderd op 04-03-2016 12:36 ]

[Q]

Tja voor Linux volg ik gewoon deze instructie:

1.8 What /dev/ names should I use when creating my pool?
http://zfsonlinux.org/faq.html

Een 'zfs create' zorgt er zelf voor dat de disks voorzien worden van gpt partities enzo.

mag je zelf weten of je je disks ook wilt part-labelen en de extra effort daarin wilt stoppen.
Ik denk dat het allemaal niets uit maakt.

Als je maar niet /dev/sd? gebruikt want want die devices willen nog wel eens van identiteit wisselen.
Ik praat nu alleen over Linux, ik weet niets van FreeBSD.

[ Voor 5% gewijzigd door Q op 04-03-2016 12:56 ]

[Compizfox]

Verwijderd schreef op vrijdag 04 maart 2016 @ 12:18:
Ik reageerde ook vooral op Q; in die zin dat het op mij overkwam alsof er device nodes worden aanbevolen, ipv partities. Dat laatste lijkt mij altijd beter.

Dat werd nergens aanbevolen Q had dat (niet met opzet) gedaan, en vroeg of dat wel goed was. Waarop Firedrunk en ik opmerkten dat het eigenlijk beter is om GPT-labels te gebruiken.