Dotaz: ZFS - deduplikace a jiné problémy

[Max]

Sestavil jsem celkem pěkný storage, který vychází z tohoto : Návrh škálovatelného Enterprise Storage za hubičku
Tzn. Areca řadič s 2GiB cache + baterie + 13x4TiB WD RED (ZFS RAID10 + 1x spare) + 64GiB DDR4 ECC
Vyzkoušel jsem si, že vše běží rychle (zálohy celých VM, rychlost přes LACP 1,5Gb/s). Po pár týdnech jsem zkusil zapnout deduplikaci. Celkem to ještě šlapalo, nepoznával jsem rozdíl. Pak ovšem přišel výpadek proudu a selhání UPS.
To mělo za následek, že vypadl asi jeden disk z řadiče, přidal jsem ho zpět, ZFS zahlásil health ok a vše vypadalo dobře. Po pár dnech se storage padnul. Zjistil jsem, že se Areca řadič odpojil a FreeNAS ho nevidí. Provedl jsem úplně odpojení napájení serveru a od té doby vše ok. Tedy jen po HW stránce. Pole nejdříve dva dny nešlo připojit, FreeNAS ležel na importování poolu a kernel padal dokola a dokola a vyhazoval backtrace. Nabootoval jsem FreeBSD, postupně připojoval a zjistil, že je problém s připojením jednoho datasetu, tak jsem ho smazal. Kvůli problémům s výkonem jsem vypnul deduplikaci, ale stále jsem ve stavu, kdy pole zlobí. A to následovně :
Pool hlásí, že jsou na něm ještě nějaká dedup data (což lze asi chápat):

[root@bs1-ph] ~# zpool list datastore1
NAME         SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
datastore1  21.8T  17.6T  4.17T         -    65%    80%  1.03x  ONLINE  /mnt

A problém je takový, že když o víkendu pustím dump 2,7TiB databáze přes NFS rovnou na storage, tak celý server padne. Pád nastane i v případě, že chci smazat starým 2,7TiB dump db. Chvíli server běží, ale poté se asi procesy na pozadí rozhodnou soubor skutečně smazat a jde to dolu. Občas se i stane to, že jiné mašiny, co zálohuji přes NFS zahlásí problémy s nedostupností NFS (storage se tak zpomalí, že neodpovídá).
V logu FreeNASu jsem i zahlédl problém s nedostatkem swap (to když šel FreeNAS na hubu a přes kvm jsem viděl na obrazovce log, stalo se mi to i při bootu).

[root@bs1-ph] ~# zpool history datastore1
History for 'datastore1':
2015-09-14.17:18:22 zpool create -o cachefile=/data/zfs/zpool.cache -o failmode=continue -o autoexpand=on -O compression=lz4 -O aclmode=passthrough -O aclinherit=passthrough -f -m /datastore1 -o altroot=/mnt datastore1 mirror /dev/gptid/d33bdf38-5af3-11e5-8367-0cc47a34a53a /dev/gptid/d37672d0-5af3-11e5-8367-0cc47a34a53a mirror /dev/gptid/d3b099a3-5af3-11e5-8367-0cc47a34a53a /dev/gptid/d3ebf665-5af3-11e5-8367-0cc47a34a53a mirror /dev/gptid/d426e367-5af3-11e5-8367-0cc47a34a53a /dev/gptid/d4624a7b-5af3-11e5-8367-0cc47a34a53a mirror /dev/gptid/d49effcc-5af3-11e5-8367-0cc47a34a53a /dev/gptid/d4d9eb20-5af3-11e5-8367-0cc47a34a53a mirror /dev/gptid/d5181f27-5af3-11e5-8367-0cc47a34a53a /dev/gptid/d554313e-5af3-11e5-8367-0cc47a34a53a mirror /dev/gptid/d591a58d-5af3-11e5-8367-0cc47a34a53a /dev/gptid/d5ccb0a0-5af3-11e5-8367-0cc47a34a53a spare /dev/gptid/d60b9953-5af3-11e5-8367-0cc47a34a53a
2015-09-14.17:18:27 zfs inherit mountpoint datastore1
2015-09-14.17:18:27 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-15.16:13:10 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-09-15.16:13:10 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-15.16:35:47 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-09-15.16:35:47 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-16.11:35:59 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-09-16.11:35:59 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-16.11:58:09 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-09-16.11:58:09 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-16.12:10:02 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-09-16.12:10:02 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-16.12:43:38 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-09-16.12:43:38 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-09-17.15:21:19 zfs create -o casesensitivity=sensitive datastore1/partimaged_storage
2015-09-17.15:21:46 zfs create -o casesensitivity=sensitive datastore1/partimaged_storage/VM-backup
2015-09-17.15:22:01 zfs destroy -r datastore1/partimaged_storage/VM-backup
2015-09-17.15:22:23 zfs create -o casesensitivity=sensitive datastore1/VM-backup
2015-09-23.16:20:02 zfs rename datastore1/partimaged_storage datastore1/parted
2015-09-23.16:37:00 zfs rename datastore1/parted datastore1/partimag
2015-09-24.21:03:14 zfs create -o casesensitivity=sensitive -o aclmode=restricted datastore1/Helios-dump
2015-09-24.21:05:39 zfs inherit compression datastore1/Helios-dump
2015-09-24.21:05:39 zfs inherit atime datastore1/Helios-dump
2015-09-24.21:05:39 zfs inherit dedup datastore1/Helios-dump
2015-09-24.21:05:39 zfs set reservation=0 datastore1/Helios-dump
2015-09-24.21:05:39 zfs set refreservation=0 datastore1/Helios-dump
2015-09-24.21:05:39 zfs set quota=none datastore1/Helios-dump
2015-09-24.21:05:39 zfs set refquota=none datastore1/Helios-dump
2015-09-24.21:05:39 zfs set aclmode=restricted datastore1/Helios-dump
2015-09-24.21:15:53 zfs create -o casesensitivity=sensitive datastore1/helios-db
2015-09-24.23:08:07 zfs create -o casesensitivity=sensitive datastore1/rail-data-backup
2015-10-03.12:03:45 zfs destroy -r datastore1/Helios-dump
2015-10-03.12:04:58 zfs create -o casesensitivity=sensitive datastore1/dms-db
2015-10-03.12:16:22 zfs inherit compression datastore1/dms-db
2015-10-03.12:16:23 zfs inherit atime datastore1/dms-db
2015-10-03.12:16:23 zfs set dedup=verify datastore1/dms-db
2015-10-03.12:16:23 zfs set reservation=0 datastore1/dms-db
2015-10-03.12:16:23 zfs set refreservation=0 datastore1/dms-db
2015-10-03.12:16:23 zfs set quota=none datastore1/dms-db
2015-10-03.12:16:23 zfs set refquota=none datastore1/dms-db
2015-10-03.12:16:28 zfs set aclmode=passthrough datastore1/dms-db
2015-10-04.00:31:52 zfs create -o casesensitivity=sensitive datastore1/gfi-backup
2015-10-04.11:35:39 zfs inherit compression datastore1/gfi-backup
2015-10-04.11:35:39 zfs inherit atime datastore1/gfi-backup
2015-10-04.11:35:39 zfs set dedup=verify datastore1/gfi-backup
2015-10-04.11:35:39 zfs set reservation=0 datastore1/gfi-backup
2015-10-04.11:35:39 zfs set refreservation=0 datastore1/gfi-backup
2015-10-04.11:35:39 zfs set quota=none datastore1/gfi-backup
2015-10-04.11:35:39 zfs set refquota=none datastore1/gfi-backup
2015-10-04.11:35:44 zfs set aclmode=restricted datastore1/gfi-backup
2015-10-04.11:35:58 zfs inherit compression datastore1/helios-db
2015-10-04.11:35:58 zfs inherit atime datastore1/helios-db
2015-10-04.11:35:58 zfs set dedup=verify datastore1/helios-db
2015-10-04.11:35:58 zfs set reservation=0 datastore1/helios-db
2015-10-04.11:35:58 zfs set refreservation=0 datastore1/helios-db
2015-10-04.11:35:58 zfs set quota=none datastore1/helios-db
2015-10-04.11:35:58 zfs set refquota=none datastore1/helios-db
2015-10-04.11:36:03 zfs set aclmode=passthrough datastore1/helios-db
2015-10-06.23:26:46 zfs create -o casesensitivity=sensitive -o dedup=verify datastore1/rail-backup
2015-10-06.23:27:48 zfs inherit compression datastore1/partimag
2015-10-06.23:27:49 zfs inherit atime datastore1/partimag
2015-10-06.23:27:49 zfs set dedup=verify datastore1/partimag
2015-10-06.23:27:49 zfs set reservation=0 datastore1/partimag
2015-10-06.23:27:49 zfs set refreservation=0 datastore1/partimag
2015-10-06.23:27:49 zfs set quota=none datastore1/partimag
2015-10-06.23:27:49 zfs set refquota=none datastore1/partimag
2015-10-06.23:27:50 zfs set aclmode=passthrough datastore1/partimag
2015-10-07.00:01:57 zfs create -o casesensitivity=sensitive datastore1/scripts
2015-10-09.12:14:35 zfs create -o casesensitivity=sensitive datastore1/sap-backup
2015-10-09.15:22:13 zfs snapshot datastore1/rail-backup@manual-20151009
2015-10-09.15:35:00 zfs snapshot datastore1/rail-backup@manual-2015-10-09
2015-10-09.21:42:21 zfs snapshot datastore1/rail-backup@manual-
2015-10-10.01:06:40 zfs destroy datastore1/rail-backup@bkp-2015-10-10-010420
2015-10-10.01:06:59 zfs destroy datastore1/rail-backup@manual-
2015-10-10.01:15:23 zfs snapshot datastore1/rail-backup@bkp-2015-10-10-011412
2015-10-10.20:03:08 zfs snapshot datastore1/rail-backup@bkp-2015-10-10-200308
2015-10-11.20:03:21 zfs snapshot datastore1/rail-backup@bkp-2015-10-11-200320
2015-10-12.20:03:38 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-12-200336
2015-10-12.20:27:52 zfs set compression=lz4 datastore1
2015-10-12.20:27:52 zfs inherit atime datastore1
2015-10-12.20:27:53 zfs set dedup=verify datastore1
2015-10-12.20:27:54 zfs set reservation=0 datastore1
2015-10-12.20:27:55 zfs set refreservation=0 datastore1
2015-10-12.20:27:55 zfs set quota=none datastore1
2015-10-12.20:27:56 zfs set refquota=none datastore1
2015-10-12.20:27:58 zfs set aclmode=passthrough datastore1
2015-10-12.20:28:14 zfs inherit compression datastore1/VM-backup
2015-10-12.20:28:15 zfs inherit atime datastore1/VM-backup
2015-10-12.20:28:16 zfs set dedup=off datastore1/VM-backup
2015-10-12.20:28:17 zfs set reservation=0 datastore1/VM-backup
2015-10-12.20:28:17 zfs set refreservation=0 datastore1/VM-backup
2015-10-12.20:28:18 zfs set quota=none datastore1/VM-backup
2015-10-12.20:28:18 zfs set refquota=none datastore1/VM-backup
2015-10-12.20:28:19 zfs set aclmode=passthrough datastore1/VM-backup
2015-10-12.20:28:32 zfs inherit compression datastore1/helios-db
2015-10-12.20:28:32 zfs inherit atime datastore1/helios-db
2015-10-12.20:28:32 zfs inherit dedup datastore1/helios-db
2015-10-12.20:28:33 zfs set reservation=0 datastore1/helios-db
2015-10-12.20:28:33 zfs set refreservation=0 datastore1/helios-db
2015-10-12.20:28:33 zfs set quota=none datastore1/helios-db
2015-10-12.20:28:33 zfs set refquota=none datastore1/helios-db
2015-10-12.20:28:34 zfs set aclmode=passthrough datastore1/helios-db
2015-10-12.20:28:43 zfs inherit compression datastore1/partimag
2015-10-12.20:28:43 zfs inherit atime datastore1/partimag
2015-10-12.20:28:43 zfs inherit dedup datastore1/partimag
2015-10-12.20:28:44 zfs set reservation=0 datastore1/partimag
2015-10-12.20:28:44 zfs set refreservation=0 datastore1/partimag
2015-10-12.20:28:44 zfs set quota=none datastore1/partimag
2015-10-12.20:28:44 zfs set refquota=none datastore1/partimag
2015-10-12.20:28:45 zfs set aclmode=passthrough datastore1/partimag
2015-10-12.20:28:53 zfs inherit compression datastore1/rail-backup
2015-10-12.20:28:53 zfs inherit atime datastore1/rail-backup
2015-10-12.20:28:53 zfs inherit dedup datastore1/rail-backup
2015-10-12.20:28:54 zfs set reservation=0 datastore1/rail-backup
2015-10-12.20:28:54 zfs set refreservation=0 datastore1/rail-backup
2015-10-12.20:28:54 zfs set quota=none datastore1/rail-backup
2015-10-12.20:28:54 zfs set refquota=none datastore1/rail-backup
2015-10-12.20:28:55 zfs set aclmode=passthrough datastore1/rail-backup
2015-10-12.20:29:05 zfs inherit compression datastore1/dms-db
2015-10-12.20:29:05 zfs inherit atime datastore1/dms-db
2015-10-12.20:29:05 zfs inherit dedup datastore1/dms-db
2015-10-12.20:29:05 zfs set reservation=0 datastore1/dms-db
2015-10-12.20:29:05 zfs set refreservation=0 datastore1/dms-db
2015-10-12.20:29:06 zfs set quota=none datastore1/dms-db
2015-10-12.20:29:06 zfs set refquota=none datastore1/dms-db
2015-10-12.20:29:07 zfs set aclmode=passthrough datastore1/dms-db
2015-10-12.20:29:20 zfs inherit compression datastore1/gfi-backup
2015-10-12.20:29:22 zfs inherit atime datastore1/gfi-backup
2015-10-12.20:29:24 zfs inherit dedup datastore1/gfi-backup
2015-10-12.20:29:25 zfs set reservation=0 datastore1/gfi-backup
2015-10-12.20:29:26 zfs set refreservation=0 datastore1/gfi-backup
2015-10-12.20:29:27 zfs set quota=none datastore1/gfi-backup
2015-10-12.20:29:28 zfs set refquota=none datastore1/gfi-backup
2015-10-12.20:29:30 zfs set aclmode=restricted datastore1/gfi-backup
2015-10-13.14:59:55 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-13-145948
2015-10-13.20:04:39 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-13-200437
2015-10-14.20:04:22 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-14-200421
2015-10-15.20:04:07 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-15-200407
2015-10-16.20:03:44 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-16-200344
2015-10-17.20:03:22 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-17-200321
2015-10-18.20:03:44 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-18-200327
2015-10-19.20:03:24 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-19-200323
2015-10-20.20:04:24 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-20-200421
2015-10-21.14:28:34 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-10-21.14:28:34 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-21.14:45:23 zpool scrub datastore1
2015-10-21.21:20:36 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-21-211848
2015-10-21.21:20:49 zfs create -o casesensitivity=sensitive datastore1/oracle-backups
2015-10-22.20:03:45 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-22-200339
2015-10-23.13:27:54 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-10-23.13:27:54 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-24.18:43:14 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-10-24.18:43:14 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-24.19:03:55 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-10-24.19:03:55 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-24.19:13:43 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-10-24.19:13:43 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-24.21:26:41 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-24-212634
2015-10-25.19:40:27 zfs set mountpoint=/tmp/zfs datastore1/dms-db
2015-10-25.20:49:23 zpool import -N -f datastore1
2015-10-26.23:49:24 zpool import -N -f datastore1
2015-10-26.23:53:07 zfs set mountpoint=/tmp/zfs datastore1/scripts
2015-10-26.23:53:14 zfs set mountpoint=/tmp/zfs datastore1/dms-db
2015-10-26.23:53:21 zfs set mountpoint=/tmp/zfs datastore1/VM-backup
2015-10-27.10:37:16 zpool import -N -f datastore1
2015-10-27.10:52:12 zfs set mountpoint=/mnt/datastore1/scripts datastore1/scripts
2015-10-27.10:55:50 zfs set mountpoint=/mnt/datastore1/partimag datastore1/partimag
2015-10-27.10:56:18 zfs set mountpoint=/mnt/datastore1/rail-backup datastore1/rail-backup
2015-10-27.10:56:31 zfs set mountpoint=/mnt/datastore1/oracle-backups datastore1/oracle-backups
2015-10-27.10:56:44 zfs set mountpoint=/mnt/datastore1/gfi-backup datastore1/gfi-backup
2015-10-27.10:57:03 zfs set mountpoint=/mnt/datastore1/rail-data-backup datastore1/rail-data-backup
2015-10-27.10:57:19 zfs set mountpoint=/mnt/datastore1/sap-backup datastore1/sap-backup
2015-10-27.10:57:37 zfs set mountpoint=/mnt/datastore1/helios-db datastore1/helios-db
2015-10-27.10:59:05 zfs set mountpoint=/mnt/datastore1/VM-backup datastore1/VM-backup
2015-10-27.10:59:15 zfs set mountpoint=/mnt/datastore1/dms-db datastore1/dms-db
2015-10-27.14:09:45 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-10-27.14:09:45 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-27.18:18:37 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-10-27.20:12:31 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-27-200534
2015-10-27.23:08:26 zfs set compression=lz4 datastore1
2015-10-27.23:09:15 zfs inherit atime datastore1
2015-10-27.23:10:31 zfs set dedup=off datastore1
2015-10-27.23:14:15 zfs set reservation=0 datastore1
2015-10-27.23:21:37 zfs set refreservation=0 datastore1
2015-10-27.23:30:39 zfs set quota=none datastore1
2015-10-27.23:42:48 zfs set refquota=none datastore1
2015-10-28.00:19:05 zfs set aclmode=passthrough datastore1
2015-10-28.20:56:48 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-28-200350
2015-10-28.21:37:27 zfs set compression=lz4 datastore1
2015-10-28.22:04:19 zfs inherit atime datastore1
2015-10-28.22:20:21 zfs set mountpoint=/mnt/datastore1/VM-backup datastore1/VM-backup
2015-10-28.22:27:31 zfs set dedup=off datastore1
2015-10-28.23:18:02 zfs set reservation=0 datastore1
2015-10-28.23:18:20 zfs set refreservation=0 datastore1
2015-10-29.01:38:33 zfs set quota=none datastore1
2015-10-29.01:40:15 zfs set refquota=none datastore1
2015-10-29.01:42:04 zfs set aclmode=passthrough datastore1
2015-10-29.20:04:40 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-29-200440
2015-10-30.20:04:12 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-30-200411
2015-10-31.20:04:06 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-10-31-200405
2015-11-01.20:03:54 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-01-200353
2015-11-02.14:53:58 zfs create -o casesensitivity=sensitive datastore1/horak
2015-11-02.14:58:02 zfs destroy -r datastore1/horak
2015-11-02.14:59:55 zfs create -o casesensitivity=sensitive datastore1/horak
2015-11-02.15:01:36 zfs set mountpoint=/mnt/datastore1/horak datastore1/horak
2015-11-02.20:03:53 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-02-200353
2015-11-02.23:50:22 zfs create -o casesensitivity=sensitive datastore1/dms-backup
2015-11-02.23:51:23 zfs set mountpoint=/mnt/datastore1/dms-backup datastore1/dms-backup
2015-11-03.09:39:04 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-11-03.09:39:04 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-11-03.09:39:10 zfs inherit -r mountpoint datastore1
2015-11-04.00:22:25 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-04-002224
2015-11-04.20:04:16 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-04-200415
2015-11-05.20:04:02 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-05-200401
2015-11-06.20:03:46 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-06-200346
2015-11-07.20:03:54 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-07-200353
2015-11-08.20:03:29 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-08-200328
2015-11-09.20:04:06 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-09-200405
2015-11-10.20:03:43 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-10-200342
2015-11-11.20:03:51 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-11-200351
2015-11-12.20:04:43 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-12-200442
2015-11-13.08:22:26 zpool import -o cachefile=none -R /mnt -f 2626378954000273008
2015-11-13.08:22:26 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-11-13.22:48:28 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-13-224828
2015-11-14.20:03:49 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-14-200348
2015-11-15.20:03:34 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-15-200333
2015-11-16.20:03:42 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-16-200342
2015-11-17.20:03:35 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-17-200334
2015-11-18.12:39:07 zpool import -o cachefile=none -R /mnt -f 2626378954000273008
2015-11-18.12:39:07 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-11-18.13:10:22 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-11-18.13:10:22 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-11-19.00:16:52 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-19-001650
2015-11-19.20:03:50 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-19-200349
2015-11-20.20:04:16 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-20-200415
2015-11-21.20:04:27 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-21-200426
2015-11-22.20:04:03 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-22-200402
2015-11-23.20:05:08 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-23-200507
2015-11-24.20:04:29 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-24-200428
2015-11-25.20:04:32 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-25-200431
2015-11-26.20:04:20 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-26-200420
2015-11-27.20:04:18 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-27-200418
2015-11-28.20:06:00 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-28-200556
2015-11-29.00:01:34 zpool scrub datastore1
2015-11-29.20:03:56 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-11-29-200353
2015-11-30.15:16:42 zpool import -c /data/zfs/zpool.cache.saved -o cachefile=none -R /mnt -f 2626378954000273008
2015-11-30.15:16:42 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-12-05.22:38:06 zpool import -o cachefile=none -R /mnt -f 2626378954000273008
2015-12-05.22:38:06 zpool set cachefile=/data/zfs/zpool.cache datastore1
2015-12-05.22:41:47 zfs destroy -r datastore1/horak
2015-12-06.20:07:48 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-06-200739
2015-12-07.20:04:00 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-07-200359
2015-12-08.20:04:04 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-08-200402
2015-12-09.20:03:52 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-09-200351
2015-12-10.20:04:00 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-10-200359
2015-12-11.20:04:13 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-11-200411
2015-12-12.20:03:51 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-12-200350
2015-12-13.20:03:54 zfs snapshot datastore1/rail-backup@bkp-rail-backup-2015-12-13-200351

FreeNAS jsem zvolil jednak kvůli kolegům nelinuxákům, tak kvůli tomu, abych rychle pochopil filosofii ZFS (a díky zmíněným problémům už jsem ve fázi, kdy webgui nepotřebuji) + je to BSD, tudíž lepší implementace ZFS, jak v linuxu.
ZFS jsem zvolil kvůli kompresi, snapshotům a chtěl jsem i vyzkoušet deduplikaci + do budoucna jsem plánoval mít dva storage a dělat replikaci zálohy na druhý storage, kdyby se první nějak vysypal.

Otázka do placu, zda se někdo setkal s podobných chováním? Osobně si totiž myslím, že mám ram víc, než dost a zaplnění do 80% kapacity také dodržuji.
Případně zda by někdo neměl nápad, jak pool vyléčit, než ho celý dropnout a vytvořit nový.
Díky
Zdar Max

Odpovědi

[logik]

S problémem Ti moc nepomůžu, jen mohu s velkou jistotou konstatovat, že pro deduplikaci takhle velkého pole máš té paměti přecijenom málo. Horní limit pro deduplikaci je někde kolem 5GB na 1TB.... A to je jen pamět pro samotnou deduplikaci. Zkus si to spočítat:

http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe

Osobně pak bych Ti doporučil pole kompletně znovu vytvořit, evidentně je nakoplý, myslím, že je to nejrychlejší řešení, ale samozřejmě opravou se naučíš daleko víc....

[snajpa]

Zrejme se ti povedlo to pole dobre rozborit. Technicka poznamka - nepouzivej dedup nikdy, pokud presne nevis, co delas a nemas to pro danej workload dobre otestovany, ze ma vubec smysl. Dedup obecne smysl totiz moc nemiva a byva s nim vic problemu, nez uzitku, mnohem lepsi napad je komprese. Jinak k naprave rozjebanejch ZFS poli dost casto pomaha nabootovat ndco s Illumosem a oravit yo tam, pripadne aspon nouzove send/recv dat jinam. Doporucuju na to treba SmartOS.

Zkus omezit velikost ARC, sleduj, jak to na masine vypada s RAM. Podezrivam nejakej bug v aouvislosti s jadernou pameti a dedupem. Skript arc_summary.py ti pekne ukaze stav ARC.

Zkus se divat, co se deje, nez ta masina vytuhne.

[martin-ux]

Tej ramky je tam skutocne malo na to. Je specialna poziadavka na dedup ?

Hlavny problem je, ze co je to "storage padol". Co robil adapter a preco "sa odpojil" ? Radic je v stave JBOD ?

Vsadil by som sa, ze padne pri kopirovani kvoli pamati. Davnejsie som pisal na FreeBSD mailing list aj na forach - system crashoval po par minutach pri zalohe maleho 8TB pola cez NFS. Na 9 na sekol, pri 10tke mi pomohol uz nejaky timer. Musel som si pomoct rsyncom. Vyskusaj aj ty, mozno pomoze. Ak je remote masina solaris/FreeBSD tak mozes poslat data cez zfs send.

Skoda, ze nemas trace prveho padu. Ak si do toho este menil (mazal) potom, tak skutocne restore bude istejsia cesta.

Vela dobrych clankov je aj na oraclovskej stranke, napr. zfs dedup

[Max]

Hmm, děkuji všem za info. Vzhledem k tomu, že tam nemám žádné kritické věci, tak celý zpool zruším a vše vytvořím znovu.
To bude asi nejrozumnější a deduplikaci se vyhnu.
Osobně jsem myslel, že 3GiB ram na 1TiB dat bude stačit, resp. těch dat bylo ještě méně, takže to spíše vycházelo 4GiB/1TiB. Mno, je to až moc drahá sranda a nemá cenu to řešit. Dedup nepotřebuji, jen mi přišlo, že bych to mohl vyzkoušet a zjistit, kolik se tím dá reálně ušetřit místa a jak moc poklesne výkon.
Zdar Max

[trubicoid2]

kdyz tu deduplikaci vsude vypnes, tak by se to melo rozduplikovat vsechno, ne?

mne teda jo, mam tam 1.00x

co dela toto?

zfs get dedup

[Max]

Co jsem tak četl, tak by se to nemělo rozdeduplikovat, ale postupnou výměnou dat by duplikace měla postupně vymizet, tzn., že původní data po vypnutí dedup budou stále dedup s tím, že jen nová data se nebudou nově duplikovat. Řešení tedy pro kompletní oddeduplikaci je odkopírování dat jinam a zase nakopírování.

[root@bs1-ph] ~# zfs get dedup
NAME                                                                   PROPERTY  VALUE          SOURCE
System                                                                 dedup     off            local
System/.system                                                         dedup     off            inherited from System
System/.system/configs-5ece5c906a8f4df886779fae5cade8a5                dedup     off            inherited from System
System/.system/cores                                                   dedup     off            inherited from System
System/.system/rrd-5ece5c906a8f4df886779fae5cade8a5                    dedup     off            inherited from System
System/.system/samba4                                                  dedup     off            inherited from System
System/.system/syslog-5ece5c906a8f4df886779fae5cade8a5                 dedup     off            inherited from System
System/jails                                                           dedup     off            inherited from System
System/jails/.warden-template-pluginjail                               dedup     off            inherited from System
System/jails/.warden-template-pluginjail@clean                         dedup     -              -
System/jails/.warden-template-standard                                 dedup     off            inherited from System
System/jails/.warden-template-standard@clean                           dedup     -              -
System/jails/bacula-sd_1                                               dedup     off            inherited from System
Vol2T                                                                  dedup     off            local
datastore-e1                                                           dedup     off            default
datastore-e1/gfi-backup                                                dedup     off            default
datastore-e1/oracle-backup                                             dedup     off            default
datastore1                                                             dedup     off            local
datastore1/VM-backup                                                   dedup     off            local
datastore1/dms-backup                                                  dedup     off            inherited from datastore1
datastore1/gfi-backup                                                  dedup     off            inherited from datastore1
datastore1/helios-db                                                   dedup     off            inherited from datastore1
datastore1/oracle-backups                                              dedup     off            inherited from datastore1
datastore1/partimag                                                    dedup     off            inherited from datastore1
datastore1/rail-backup                                                 dedup     off            inherited from datastore1
datastore1/rail-backup@manual-20151009                                 dedup     -              -
datastore1/rail-backup@manual-2015-10-09                               dedup     -              -
datastore1/rail-backup@bkp-2015-10-10-011412                           dedup     -              -
datastore1/rail-backup@bkp-2015-10-10-200308                           dedup     -              -
datastore1/rail-backup@bkp-2015-10-11-200320                           dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-12-200336               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-13-145948               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-13-200437               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-14-200421               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-15-200407               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-16-200344               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-17-200321               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-18-200327               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-19-200323               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-20-200421               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-21-211848               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-22-200339               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-24-212634               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-27-200534               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-28-200350               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-29-200440               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-30-200411               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-10-31-200405               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-01-200353               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-02-200353               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-04-002224               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-04-200415               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-05-200401               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-06-200346               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-07-200353               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-08-200328               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-09-200405               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-10-200342               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-11-200351               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-12-200442               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-13-224828               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-14-200348               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-15-200333               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-16-200342               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-17-200334               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-19-001650               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-19-200349               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-20-200415               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-21-200426               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-22-200402               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-23-200507               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-24-200428               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-25-200431               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-26-200420               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-27-200418               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-28-200556               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-11-29-200353               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-06-200739               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-07-200359               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-08-200402               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-09-200351               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-10-200359               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-11-200411               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-12-200350               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-13-200351               dedup     -              -
datastore1/rail-backup@bkp-rail-backup-2015-12-14-200346               dedup     -              -
datastore1/rail-data-backup                                            dedup     off            inherited from datastore1
datastore1/sap-backup                                                  dedup     off            inherited from datastore1
datastore1/scripts                                                     dedup     off            inherited from datastore1
freenas-boot                                                           dedup     off            default
freenas-boot/ROOT                                                      dedup     off            default
freenas-boot/ROOT/FreeNAS-9.3-STABLE-201511040813                      dedup     off            default
freenas-boot/ROOT/FreeNAS-9.3-STABLE-201511040813@2015-09-11-03:29:16  dedup     -              -
freenas-boot/ROOT/FreeNAS-9.3-STABLE-201511040813@2015-11-18-13:03:58  dedup     -              -
freenas-boot/ROOT/Initial-Install                                      dedup     off            default
freenas-boot/ROOT/default                                              dedup     off            default
freenas-boot/grub                                                      dedup     off            default
freenas-boot/grub@Pre-Upgrade-FreeNAS-9.3-STABLE-201511040813          dedup     -              -

Zdar Max

[trubicoid2]

asi mas pravdu, asi jsem si to pak cele prekopiroval v ramci jdnoho poolu, zabiralo to min nez pulku

[trubicoid2]

dokud to nebylo rozduplikovany, tak to blblo, evidentne kvuli nedostatku pameti, dokonce jsem musel kvuli tomu rozduplikovani na chvili RAM pridat, jinak se to sekalo

[Heron]

Zjistil jsem, že se Areca řadič odpojil a FreeNAS ho nevidí.

Tento rok jsme si s Arecou také užili své. 3 kousky po 35tis. Kč jsme odpálili úplně (máme potvrzené od dodavatele, že některé kousky odejdou do 14 dnů od připojení baterie) a u dalších jsme schopni to na počkání shodit, stačí jen vyčítat senzory (teploty apod.). Slibují nám nový firmware (už asi 10 měsíců).

Další řadič se chová dost divně, pokud se "vhodně" zatíží jeden svazek (jedny fyzické disky), tak další svazky mají prudce zvýšenou latenci, přestože se na nich nic moc neděje. Buď tam mají slabej procesor a nestíhá to, nebo se tam hádá cache nebo něco. Takže děláme co jedna areca, to jeden svazek.

[Max]

To je zajímavé, onen výtuh/odpojení řadiče jsem tak nějak přičítal baterii, tak jsem jí odpojil. Resp. nemám baterii, ale sadu kapacitorů. Jinak já mám ARC-1883I.
Teoreticky bych ani kapacitory nemusel mít. Správně bych neměl používat cache na řadiči a tím pádem ani baterii, protože ZFS si vše cachuje samo do ram.
Ale tak nějak jsem neodolal a používám cache na řadiči + u disků dělám PassThrough.
Jinak jsem mluvil s týpkem, co mi reagoval pod blogem a ptal jsem se ho na Areca řadiče. On říkal, že spokojenost, jen se občas odmlčí síťová část.
Mno, teď mi to šlape, zpool jsem odstranil a znovu vytvořil, takže jedu na čisto bez dedup a uvidíme, zda to bude stabilní. Pokud ano, tak za pár týdnů půjdu a zkusím vytrhnout kabel ze serveru, co to udělá :).
Zdar Max

[Heron]

Správně bych neměl používat cache na řadiči a tím pádem ani baterii, protože ZFS si vše cachuje samo do ram.

Neznám tak to detailu ZFS, ale přepokládám, že věci, které mají být na disku (příkaz (f)(data)sync), tak si nemůže uložit do ram, ale nutně to musí strčit na disk - resp. klidně do logu na ssd, ale zkrátka na persistentní úložiště. V tomto by se to mělo chovat stejně jako jiné FS. Cache na řadiči je dobrá jen pro urychlení zápisů, nikoliv čtení (od toho je iocache v os).

Ale tak nějak jsem neodolal a používám cache na řadiči + u disků dělám PassThrough.

Ano, pokud se používat cache na řadiči, tak cache na disku musí být vypnutá.

On říkal, že spokojenost, jen se občas odmlčí síťová část.

Tomu bych spokojenost neříkal. U nás se odmlčí řadič úplně. Nejen síťová část.

Mno, teď mi to šlape, zpool jsem odstranil a znovu vytvořil, takže jedu na čisto bez dedup a uvidíme, zda to bude stabilní. Pokud ano, tak za pár týdnů půjdu a zkusím vytrhnout kabel ze serveru, co to udělá :).

Ok

[Max]

Také neznám do podrobna ZFS, ale četl jsem Best Practilces. Byly tam argumenty proti používání cache na řadiči, ale podle mně to není oprávněné, když člověk má baterii, tak by ani při výpadku proudu nemělo dojít k nekonzistenci.
O vypínání cache na disku se stará řadič, nevím o žádném, který by umožňoval obojí :). Ta areca má možnost při PassThrough zvolit, jakou cache použít, zda na řadiči, nebo na hdd. Používám tu na řadiči.
Jinak kromě shození proudu chci ještě vyzkoušet, zda bude nějaký výkonový rozdíl mezi použitím cache na řadiči a cache na diskách, nebo zda to ZFS umí tak dobře odcachovat, že je cache na řadiči zbytečná.
Zdar Max

[trubicoid2]

ad cache na disku: co rika hdparm -W /dev/sdx ? Tak to nejde ovladat? -W 0 a -W 1 ?

[Max]

Správně by to nemělo jít, i smart informace se nedají číst úplně napřímo, viz :Areca RAID controllers and SMART support
Zdar Max

[martin-ux]

Opat sa da najst viac blogov a dokumentov (od opensolaris po oracle), ktory hovori proti pouzivaniu cache na radicoch. Prave preto, ze ZFS si to handluje sam. Pre cachovanie mozes pouzit ARC/ZIL.

Preto som sa aj pytal, ci vie/je radic v JBOD. Nech len doda disky pre system, nech nic ine radic neriesi.

S areca radicmi nemam osobnu skusenost, pouzivam LSI.

[Max]

Samozřejmě jsem je četl také. Proto jsem to i zmínil. Jen si chci otestovat, zda to handluje stejně tak dobře / rychle, jako cache na řadiči. Proto jsem to nejdříve rozjel s cache na řadiči + baterií s tím, že později přejdu na cache na diskách.
Jinak už teď mám Passthrough disků do systému, ale na řadiči mám nastaveno, aby se používala cache řadiče a né disků.
Zdar Max

[Vantomas]

A v čem je ta disková cache lepší než ta od řadiče? Hlavně když u řadiče je baterka, která zase není u disků. To si snad myslím, že než nezálohovaná cache, tak radši žádná cache.

[Max]

Ahoj, nemáš úplně tak pravdu. Nebudu opisovat, rovnou linkuju : I/O bariéry a cache
Zdar Max

[Vantomas]

Aha, hm hm, bariéry vem čert, podle toho co píšou se vypínají když je zálohovaná cache na řadiči a je IO pak rychlejší. Ale argument o tom, že FS si potom myslí, že se to zapsalo, ale kvůli absenci reálné kontroly dál a následném rozsypáním FS chápu, to je pravda, takhle jsem nad tím nepřemýšlel, trochu jsem předpokládal, že co řadič slíbil, tak to taky dodrží - tedy, že řekne, že to zapsal, ale kvůli nějaká následné poruše nezapíše, ale pamatuje si a dozapíše... Něco na tom je, teď už to chápu.

[martin-ux]

V pohode, testovat treba. Ono ale nejde len o rychlost, ale o spolahlivost. A prave vtedy, ked ZFS dostalo odpoved, ze I/O je done a ono je este stale v cache tak to je taka mala ruska ruleta nad datami. Preto len JBOD a nic necachovat.

Som si vsimol, ze sa objavili aj clanky (ale nie od oracle ludi, ani od OpenZFS komunity) preco pouzivat len mirror a nie raidz*. Osobne s tym nesuhlasim a povazujem to za waste of space. Ostatne to nie je zaloha a stale plati, ze backup nad datami musi byt. Hrali sa tam aj s argumentami performance mirror vs raidz* - to sice neviem objektivne povedat, ale som skor skepticky. Minimalne tradeoff waste of space vs performance gain.

[Max]

Samozřejmě, ale baterie na řadiči by tu ruskou ruletu měla ohlídat. Když tedy řadič vrátí, že je zapsáno, tak zapsat musí, protože to baterie podrží. Samozřejmě tu je pak druhá věc, jak spolehlivá je baterie na řadiči a celý ten systém okolo.
Zdar Max

[Heron]

Ono ale nejde len o rychlost, ale o spolahlivost.

Přesně tak, testy výkonnosti jsou moc hezký, ale zcela naprd, když k vůli pár procentům výkonu navíc přijdete o všechna data.

A prave vtedy, ked ZFS dostalo odpoved, ze I/O je done a ono je este stale v cache tak to je taka mala ruska ruleta nad datami.

Nevím, jak to má Max zapojené. Píše, že disky má PassThrough + write cache na řadiči. Nevím jak se to chová, takto jsem to nikdy netestoval. Píše, že vypadl jeden disk a objevil se až po power cycle. Takže se klidně mohlo stát, že ZFS poslal požadavek na zápis dat, řadič odpověděl, že je vše zapsáno (no měl to dejme tomu ve BBWC), potom nebyl vidět disk, takže řadič tato data zahodil a nezapsal. Ale ZFS předpokládal, že data jsou na disku (dostal o tom potvrzení od řadiče) - min mohl zapsat další data na další disky s tímto předpokladem - a těžká nekonzistence je na světě.

Jestli se to stalo takto nevím, ale s tímto by se nevyrovnal žádný FS. V takovém případě je otázkou, zda nevypnout rovnou i cache řadiče a nechat to jen na inteligenci ZFS.

[Max]

Mám RAID10 v rámci ZFS. Tzn., že mám 6xRAID1 po dvou diskách. Tebou popsanou hypotetickou situaci by tedy měl rozchodit bez problémů.
Zdar Max

[Heron]

Celkem to ještě šlapalo, nepoznával jsem rozdíl. Pak ovšem přišel výpadek proudu a selhání UPS. To mělo za následek, že vypadl asi jeden disk z řadiče

Nevím, nakolik je hypotetická, nakolik reálná. Vypadl disk, řadič, pokud něco měl v BWCC neměl kam zapsat data. To, že je to v R10 na věci nic nemění, na 5 discích jsou data "jako by jich bylo 6" a na jednom disku něco není, protože vypadl. Teoreticky by si měl zapsat i generaci posledního zápisu a poznat, že jeden z disků není úplně aktuální a nepřipojit ho do fs.

Opět, neznám ZFS, na BTRFS bych pustil scrub a kochal bych se výpisem do dmesgu. Resp kdybych věděl, který disk to je, tak ho nenechám připojit a přidal bych jej do btrfs jako čistý disk, ať si to znovu zesyncuje.

[Max]

ZFS scrub prošel ok.
Zdar Max

[martin-ux]

Ale prave o to ide - ZFS nebude vediet povedat, ci je to zle. Nove data nebudu zapisane. Vyhoda tu je, ze tie stare by sa nemali poskodit, kedze sa robit copy-on-write. Samozrejme je to vecou preferencie, osobne by som vypol ale vsetko - radic nech nerobi nic. Plain JBOD.

@Heron: jj, to si myslim, ze sa aj stalo. ZFS si myslelo, ze je to ok, ale pri pade systemu bol prave s tym problem - doslo k inkonzistencii co si myslelo ZFS a co radic skutocne urobil.

Ohladne tej mirror vs raidz* neviem argumentovat na performance. Co sa tyka poskodenia dat, tak si nemyslim, ze je probblem s raidz* lebo:

• a) prvorade mam backup (PROD, doma asi skor nie)
• b) mam dostatocny fault tolerance (napr. 2P )
• c) hot spare v poole
• d) vdev-y vytvraram rozumne, tj.
• da) dodrziavam pocet diskov vo vdev podla raidz*
• db) pool extendujem vdev-ami podla da)
• e) aj highend storage (napr. P9500/XP7) pouziva ine ako raid1 groupy, a nie pre srandu

To vlastne vseobecne plati pre kazdy druh raid-u nezavisle od providera.

[Aleš Kapica]

..přepokládám, že věci, které mají být na disku (příkaz (f)(data)sync), tak si nemůže uložit do ram, ale nutně to musí strčit na disk - resp. klidně do logu na ssd, ale zkrátka na persistentní úložiště.

Plně s tebou souhlasím. Bohužel u některých FS to bez patřičného HW vybavení znamená degradaci IO výkonu. A proto jsem nyní sáhnul po řešení, které jsem testoval již před lety. Není tak profláknuté jako jiné, takže ho nejspíš ani v ČR nikdo mimo mne nepoužívá.

[Max]

Dobře jsi to nakousl, zřejmě očekáváš, aby se tě na to někdo zeptal, tak se tážu : jaké? :)
Zdar Max

[Aleš Kapica]

Pro ty bystřejší to nebude problém zjistit - stačí se podívat na přehled změn v naší wiki. Ale na nějaké generalizování je ještě brzy. Nechám si to jako téma pro Linux Days, nebo nějakou jinou podobnou akci. Předpokládám, že za tu dobu stihnou vyplavat i případné nedostatky.

[Max]

Kdyby ta wiki jela, tak bych se tam i podíval :)
Zdar Max

[Aleš Kapica]

No jo. To se nesmíš trefit zrovna do okamžiku, kdy zastavím Apache a Mysql server. Před chvílí jsem restartoval jeden z nodů a resynchronizace GlusterFS svazků, které ještě nejsou v odstřelu jako obvykle sežerala veškeré IO. Takže to jede, ale je to přibržděné..

[Max]

Hmm, o GlusterFS jsem věděl, ale že si hraješ s Sheepdogem, to ne. Jsem zvědavý na výsledky. Už jsem na něj jednou také koukal.
Zdar Max

[Aleš Kapica]

Už jsem tady o něm kdysi psal. Dopálilo mě právě to lagování při synchronizaci. Když je vše v pořádku, je GlusterFS ok. A co je pozitivní - data v bezpečí. Ale jakmile jenom restartuješ některý z nodů, je to na infarkt. Jak nemáš rychlé SAS nebo alespoň NL SAS disky a z nich sestavené svižné pole, tak je se soubory nad 10GB soubory nehorázný opruz. Ještě mi chybí přemigrovat tři stroje a jeden z nich je zrovna velká 50G mrcha plná dat. Mimochodem - jeho synchronizace ještě stále nedoběhla. IO výkon navíc degraduje to, že je to nad Thin LVM - to byla také úlitba GlusterFS, abych u něj mohl otestovat snapshoty.

[Max]

Mno, já toto nakonec asi ani řešit nebudu. Šéf chce řešení na klíč, takže budeme mít nějaké nabídky na NetApp, EMC apod. řešení, takže se aspoň seznámím s novýma hračkama + bude více času na jiné věci a SDS pole zatím tedy ne, o těch si přečtu u tebe na wiki :)
Zdar Max

[NoXO]

Ahoj, přesně toto se mi stalo před vánoci a přes vánoce ten server úplně zkolaboval, nemám hw raid, ale RaidZ2, 6x 4T disky, server se po zapnutí deduplikace a záloh celých mašin přes iSCSI vypínal 1-2x týdně podle náročnosti záloh (těsně před vánoci jsem server rozšířil o L2ARC + 32GB RAM + zapl tu dedup)... 

psalo mi to hlášku po pádu:

one or more devices has experienced an unrecoverable error. (nebo něco podobného)

při bootu importoval pool s chybama a napsal i který zvol je vadný, všiml jsem si toho až po vánocích, když jsem došel do práce..

vadný zvol jsem vymazal a musel se projet scrub... (pořád zpool vypisoval chybu, tentokrát s hex odkazem na neexistující zvol). scrub jel strašně pomalu snad 1b/s, to nevadilo, nechal jsem to cca 2h zaple a pak scrub stopl, zpool se začal hlásit, že je oka..., ručně jsem aktualizoval freenas...

myslel jsem si, že to bylo novým hw, ale evidentně je problém ve freenasu, protože v té době mi přestaly fungovat i řádné aktualizace přes webové rozhaní, psalo to něco o vadné cestě na update, fungoval jen freenas-update update, ale ten se neprovedl, protože mi hlásil zpool, že není oka.

Opravoval jsem to až včera, protože jsem si myslel, že to bylo novým hw..., ale nebylo, RAM i nový SSD DISK, prošel všemi testy ....

[NoXO]

Psalo to toto, našel jsem podobný odkaz na inetu... po vymazu zvolu, zustane jen hexa odkaz v < x >

status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.


            ada0    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0
            ada4    ONLINE       0     0     0
            ada5    ONLINE       0     0     0
            ada6    ONLINE       0     0     0
            ada7    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        storage/data:<0x0>

[Max]

To já to měl bez chyb. Jen to tuhlo, restartovalo se to, některé operace trvaly šíleně dlouho atd. (dle diskuse kvůli dedup + málo ram).
Potom, co jsem vše vytvořil znovu, je klid. Jednou se mi akorát stalo, že jsem zaplnil zpool na 95% a brutálně se zpomalil, začaly se mi odpojovat NFS klienti apod. Po smazání starých záloh / uvolnění místa pod 80% je vše plně ok.
Teď na tom přes NFS zkouším provozovat Oracle db 12c.
Samozřejmě jen pro testovací účely + FreeNAS = NFS3, což je tragedie.
Jeden z důvodů, kvůli kterým přemýšlím opustit FreeNAS, ale zase, blíží se verze 10 a těžko říci, zda to tam nakonec bude, nebo ne.
Zdar Max

[NoXO]

chyba se mi rovněž objevila po přidání RAM + L2RC + samozřejmě jsem s tím zapl dedup (což byl podle mě viník a taky důvod proč jsem upgradoval), vy máte HW raid, bůh ví, jak se to pak chová, výsledek byl však stejný a ve stejnou dobu, pády po zatížení, výrazné zpomalení (+samovolné vypnutí mašiny) ... dle mě však dedup fungoval u mě na menším 500GiB oddílu (to jsem testoval 10x za sebou jako první vlaštovku a bez jakýchkoliv problému, výkon byl taky super, zpomalení max o 1/3, na tomto zvolu mi to funguje, ale na tom velkým 8TiB zvolu jsem dedup vypl a prozatím oka), prostě mi to na tom 8TiB kolabovalo (ten jsem prvotně netestoval), protože než se provedou všechny zálohy, začnou se synchronizovat další replikace z jiného freenasu... ostestuji dedup nejdříve na menším oddílu a pak zkusím znova zapnout i na tom větší...

nfs je zastaralá záležitost, disky připojuji přes iSCSI. Vmware to podporuje i ve verzi free... dokonce umí u thin disku zeroing a uvolní nepouživané bloky ... což je super

[NoXO]

uff, píšu jako čuně, ale snad myšlenka je znatelná.

update přes webové rozhraní mi na tom jednom freenasu nejde dodnes:

Jan 13 10:23:59 san-ds1-ov manage.py: [freenasOS.Update:1362] Could not open sequence file in cache directory /var/db/system/update: [Errno 2] No such file or directory: '/var/db/system/update/SEQUENCE'
Jan 13 10:23:59 san-ds1-ov manage.py: [freenasOS.Update:978] Cache directory /var/db/system/update does not have a sequence file

přes shell update funguje.

[NoXO]

našel jsem chyby, které mám i já:

1) https://bugs.freenas.org/issues/13048

2) https://bugs.freenas.org/issues/12958 systém mi teď znova vytuhl po přenesení velkého množství dat. ping... OKA ssh... dead gui... dead

[Max]

Jak říkám, mně to sviští. Mám ZFS RAID10 poskládaný z 12x4TiB WD RE + 64GiB DDR4 ECC.
Denně zálohuji asi 3TiB dat VM img.
O víkendu pak dělám přímý dump db na NFS, db má 3,2TiB.
A vše ok. Samozřejmě bez dedup.
Zdar Max

[NoXO]

musel jsem odstranit L2ARC ... a už mi to nepadá (a to jsem si myslel, že mi ssd pomůže), ale scrub jede strašně pomalu, dedup mám stále na jednotce cca 1.32, podle mě mám nějak nabořený zpool což bude asi ten problém

[NoXO]

Odpojil jsem L2ARC cache a spustil scrub. Scrub mi doběhl po cca 32hodinách. Prvních 18hodin běžel rychlostí (1/b ??) a neustále v 30 sekundových intervalech něco zapisoval na disk rychlostí 20-40MB/s, po doběhnutí scrubu bylo opraveno 0 chyb, ale deduplikace na zpoolu klesla z 1.32 na 1.12, přitom nové data na zpool nikdo nezapisoval. Po doběhnutí scrubu se stal server opět stabilní, reboot a náběh probíhají už normálně - zajímavé chování.

PS: Jakoby se nějak porušila L2ARC v závislosti na zapnuté deduplikaci nebo to přerostlo jistou mez, kterou můj HW dokázal v rozumném čase zpracovat.. Nějakou dobu zkusím nechat vypnutou L2ARC cache a deduplikaci už zapínat raději nebudu.

PS2: Dočetl jsem se, že optimální velikost RAM na 1T diskového prostoru při zapnuté deduplikaci je 5 (+1) GB avšak už jsem se nedozvěděl, zda je to na 1T obsažených dat, velikost pole, zpoolu, zvolu nebo surové velikosti diskového pole. Tedy pro sebe a mých 16TB čistého diskového prostoru jsem vypočítal, že bych potřeboval při spotřebě 6GB RAM na 1TB asi 96GB RAM... (zvolil jsem tu hw náročnější cestu)

PK

[pq]

Radeji bych koupil neco funkcniho. Nebude potreba to za mesic zase lecit ... p.