शुरुआती लोगों के लिए ZFS

 (ikrima.dev)
2 पॉइंट द्वारा GN⁺ 2023-09-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FreeNAS में ZFS failure को आधार बनाकर troubleshooting, नया volume configure करना और backup strategy तक समेटने वाली शुरुआती guide; ZFS को पहली बार operate करते समय ज़रूरी structure और commands को एक flow में समझाती है
  • ZFS filesystem और logical volume manager दोनों देता है; इसकी शुरुआत Sun Microsystems में हुई थी, और Linux व FreeBSD आदि में मुख्यतः OpenZFS code इस्तेमाल होता है
  • इसकी basic structure में physical disks को जोड़ने वाला vdev, उन्हें मिलाकर बना pool, filesystem की भूमिका वाला dataset, और block device रूप में volume शामिल हैं; RAIDZ-1/2/3 क्रमशः 1, 2, 3 disk failures सहन कर सकते हैं
  • Practical commands में zpool create/status/list/import/export/destroy/scrub और zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy मुख्य हैं; device name बदलने की समस्या से बचने के लिए device UUID इस्तेमाल करना बेहतर माना जाता है
  • snapshot किसी खास समय की state को हल्के तरीके से protect करता है और zfs send/recv से दूसरे pool या system में replicate किया जा सकता है, लेकिन सिर्फ snapshot backup या DR का विकल्प नहीं बनता

ZFS के बुनियादी concept

  • ZFS ext4, NTFS, exFAT जैसा local filesystem है और साथ ही Linux के LVM जैसा logical volume manager भी काम करता है
  • इसे Sun Microsystems ने बनाया था, और Oracle द्वारा Sun का अधिग्रहण किए जाने से पहले ZFS source code open source license के तहत उपलब्ध था
  • चूँकि पहले से public code कई OS में port हो चुका था, बाद में OpenZFS project बना, और Linux व FreeBSD सहित ज़्यादातर Unix-like systems में यही code इस्तेमाल होता है
  • यह सामग्री शुरुआती नज़रिए से तैयार की गई है ताकि ZFS से पहली बार परिचित होने वाले लोग इसकी structure और operational commands समझ सकें

ZFS components

  • vdev एक या अधिक physical drives से बना होता है, और hard drive के अलावा file भी शामिल कर सकता है
    • इसे mirror या RAIDZ रूप में combine किया जा सकता है
    • hot spare, L2ARC, ZIL जैसे महत्वपूर्ण vdev types सहित कुल 7 vdev types होते हैं
  • pool एक या अधिक vdev से बना होता है, और आम तौर पर pool के अंदर volume या dataset बनाया जाता है
    • zpool command से pool बनाते समय vdev भी साथ में define किया जाता है
    • कई vdev types को mix करके RAIDZ level configure किया जा सकता है
  • dataset ZFS में filesystem के बराबर component है
    • user access, quota, compression, snapshot आदि set किए जा सकते हैं
  • volume dataset जैसा होता है, लेकिन block device representation देता है
    • यह dataset features में से कुछ ही उपलब्ध कराता है
    • ZFS के ऊपर कोई दूसरा filesystem चलाने या iSCSI extent export करने में उपयोगी है

RAIDZ types

  • Dynamic/Simple Stripe, यानी RAID0, parity के बिना data distribute करता है; एक भी device खोने पर पूरा data खो जाता है
  • MIRROR, यानी RAID1, disks को mirror करता है और 2–4 या उससे अधिक disks के साथ इस्तेमाल होता है
  • RAIDZ-1, यानी RAID5, data के साथ parity distribute करता है और RAID failure से पहले 1 physical drive loss सहन कर सकता है
    • RAIDZ के लिए कम से कम 3 disks चाहिए
  • RAIDZ-2, यानी RAID6, अधिकतम 2 physical drives loss सहन कर सकता है
    • RAIDZ-2 के लिए कम से कम 4 disks चाहिए
  • RAIDZ-3 अधिकतम 3 physical drives loss सहन करता है
    • कम से कम 4 disks चाहिए, लेकिन 5 से कम disks के साथ इसे इस्तेमाल न करना बेहतर है

pool बनाना और status check करना

  • ZFS pool zpool create [pool] [devices] format में बनाया जाता है
    • single disk pool example: zpool create tank /dev/sdb
    • 3-disk stripe example: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • 2-disk mirror example: zpool create tank mirror sdb sdc
    • RAIDZ pool example: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3 को zpool create [pool name] raidz[1,2,3] [devices] format में बनाया जा सकता है
  • pool बनाते समय -m flag से default mount point specify किया जा सकता है
    • example: zpool create tank -m /mnt/tank mirror sdb sdc
  • examples में /dev/sdx form वाले device names इस्तेमाल किए गए हैं, लेकिन device name बदलने से boot issues से बचने के लिए device UUID का इस्तेमाल बेहतर माना जाता है
  • zpool status pool status check करने की basic command है
    • state बताता है कि pool online है या नहीं
    • status pool के बारे में additional information दिखाता है
    • action ज़रूरी follow-up action दिखाता है
    • scan scrub progress या last scrub status दिखाता है
    • errors बताता है कि pool में कोई issue है या नहीं
  • zpool list pool की size, allocated amount, free space, fragmentation, capacity, dedup, health जैसी detailed information दिखाता है
  • zpool history pool बनने के बाद configuration changes में इस्तेमाल commands का history दिखाता है

pool import, export, delete और scrub

  • pool बनने के बाद आम तौर पर automatically import और mount हो जाता है, लेकिन troubleshooting या system reimaging के बाद manual import की ज़रूरत पड़ सकती है
  • zpool import को pool name के बिना चलाने पर import किए जा सकने वाले pools की list दिखती है
    • अगर import करने लायक pool नहीं है तो no pools available to import दिखता है
    • pool name specify करने पर वही pool import होता है, और import command pool mount भी करती है
    • zpool import -a import किए जा सकने वाले सभी pools लाता है
  • zpool import -R /mnt/tank2 tank की तरह -R इस्तेमाल करने पर यह alternate root location पर mount करता है
    • यह pool का अपना mount path नहीं, बल्कि alternate root folder होता है
  • zpool export [pool name] import का reverse operation है; यह pool के अंदर mounted filesystem को unmount करके export की कोशिश करता है
    • अगर filesystem unmount fail हो जाए तो -f से force unmount किया जा सकता है
    • अगर कोई ZFS volume in use हो, तो -f इस्तेमाल करने पर भी export fail हो जाता है
  • zpool destroy pool और उसके child dataset या volume को delete करता है
    • इससे सभी data और snapshots तक delete हो जाते हैं, इसलिए सावधानी ज़रूरी है
  • ZFS scrub pool के सभी blocks को ज्ञात checksums से compare करके data validity check करता है
    • parity वाले vdev में यह healthy disks के data का उपयोग करके corrupted data recover करता है
    • system state बनाए रखने के लिए scrub को schedule के अनुसार चलाना चाहिए
    • start: zpool scrub [pool]
    • status check: zpool status के scan area को देखें
    • stop: zpool scrub -s [pool]

dataset बनाना और mount करना

  • zfs create नया filesystem या volume बनाने की command है; यहाँ volume से ज़्यादा dataset पर focus है
  • zfs create tank/dataset1 tank के नीचे dataset1 बनाता है
    • tank dataset zpool create के समय automatically बनता है
  • zfs create -p, mkdir -p की तरह, non-existing parent datasets भी साथ में बनाता है
    • parent dataset न हो तो सामान्य zfs create fail हो जाता है
  • zfs mount को arguments के बिना चलाने पर currently mounted ZFS filesystems और mount points दिखते हैं
    • इस output में child datasets शामिल नहीं होते
  • zfs mount [pool|dataset] specified filesystem को mount करता है
    • zfs mount -a सभी filesystems को mount करता है
  • child dataset को parent dataset के बिना भी mount किया जा सकता है
    • इस case में OS filesystem में ज़रूरी path बन जाता है
    • बाद में parent dataset mount करने की कोशिश करने पर बने हुए directory के कारण directory is not empty error आ सकता है
  • zfs unmount [dataset] specified dataset को unmount करता है

dataset देखना और properties set करना

  • zfs list [dataset name] specified dataset information दिखाता है
    • dataset name के बजाय mount point को भी argument के रूप में दिया जा सकता है
  • dataset name के बिना zfs list चलाने पर system के सभी datasets recursively दिखते हैं
  • dataset name specify करते समय -r flag इस्तेमाल करने पर उस dataset के नीचे की चीज़ें recursively दिखाई जा सकती हैं
  • ZFS property filesystem, volume, snapshot, clone के behavior को control करती है
    • यह mount option जैसी दिख सकती है
  • zfs get all [dataset] dataset की सभी properties दिखाता है
  • किसी specific property value को zfs get compression tank की तरह check करें
  • property set करने के लिए zfs set इस्तेमाल होता है
    • example: zfs set compression=lz4 tank
    • set करने के बाद zfs get compression tank से verify कर सकते हैं कि compression value lz4 हो गई है

snapshot का काम करने का तरीका और उपयोग

  • snapshot filesystem की किसी specific point-in-time state को save करता है, लेकिन files copy नहीं करता
  • snapshot existing data को read-only mark करता है, और बाद में filesystem में नया data add होने पर भी snapshot द्वारा protected existing data blocks प्रभावित नहीं होते
  • example flow इस प्रकार है
    • Data A वाले existing filesystem में snapshot 1 बनाते हैं
    • इसके बाद Data B add करके snapshot 2 बनाते हैं
    • इसके बाद Data C add करते हैं
    • snapshot 1 Data A को protect करता है, और snapshot 2 Data A व Data B को protect करता है
    • snapshot 1 delete करने पर भी Data A, snapshot 2 द्वारा protect रहता है
  • snapshot द्वारा इस्तेमाल data amount बहुत कम होता है
    • क्योंकि file copy करने के बजाय filesystem top-level metadata block में यह record किया जाता है कि वह snapshot से संबंधित है
  • snapshot software development testing या upgrade से पहले failsafe बनाने में उपयोगी है
  • सिर्फ snapshot को backup या DR solution नहीं मानना चाहिए

snapshot commands

  • snapshot बनाने के लिए zfs snapshot [pool/dataset@snapshot_name] format इस्तेमाल होता है
    • example: zfs snapshot tank/dataset1@snapshot1
  • snapshot list zfs list -t snapshot से check की जाती है
  • अगर कई child datasets हों, तो top-level dataset पर snapshot बनाया जा सकता है या -r flag से recursive snapshot बनाया जा सकता है
    • normal snapshot example: zfs snapshot tank@snapshot-master
    • recursive snapshot example: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot] snapshots के बीच difference compare करता है
    • output में added files और modified paths देखे जा सकते हैं
  • snapshot restore zfs rollback [pool/dataset@snapshot_name] से किया जाता है
    • rollback करने पर snapshot के बाद बनाई गई files delete हो जाती हैं
    • newer snapshots भी delete हो जाते हैं, और इस case में आपसे -r option इस्तेमाल करने को कहा जा सकता है

ZFS send/recv और replication

  • ZFS send snapshot को data stream के रूप में भेजने की capability है
  • snapshot और dataset को file, दूसरे pool, या SSH के ज़रिये दूसरे system में replicate किया जा सकता है
  • examples में tank और backup नाम के दो pools इस्तेमाल होते हैं
    • tank/Movies dataset में 1.50G data है
    • transfer से पहले zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M') से snapshot बनाते हैं
    • zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies से snapshot को backup pool में transfer करते हैं
  • transfer के बाद zfs list में backup/Movies और tank/Movies दोनों दिखते हैं, और zfs list -t snapshot में दोनों तरफ के snapshots भी check किए जा सकते हैं
  • zfs send में कई options और use cases देखने लायक हैं, और RAIDZ व snapshot के साथ इस्तेमाल करने पर filesystem को ज़्यादा robust बनाया जा सकता है

dataset और snapshot delete करना

  • dataset delete करने के लिए zfs destroy [pool/dataset] format इस्तेमाल होता है
    • -r flag भी इस्तेमाल किया जा सकता है
  • snapshot delete करने के लिए भी zfs destroy [pool/dataset@snapshot_name] इस्तेमाल होता है
    • snapshot delete करने में भी -r flag इस्तेमाल किया जा सकता है
  • ZFS और भी कई features देता है, लेकिन यह सामग्री basic concepts और commands सीखने का starting point जैसी है

References

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-06
Hacker News की राय
  • मैंने अभी-अभी ZFS शुरू किया है, और सीखने की curve उम्मीद से ज्यादा steep है। काश आम use cases को बहुत सरल बना देने वाला कोई आसान wrapper होता
    उदाहरण के लिए pool बनाते समय ashift=12, lz4 compression, xattr=sa, acltype=posixacl, atime=off जैसे reasonable defaults बस इस्तेमाल हो जाएं, और encryption में कई options की जगह सिर्फ on/off हो
    यह encryption key generate करे, boot के समय pool decrypt करने वाली systemd service configure करे, और key backup के लिए guide करे। zfs list को यह दिखाना चाहिए कि dataset mounted है या नहीं, encrypted है या नहीं, और key loaded है या नहीं
    recursive datasets हटाकर {pool}/{dataset} की जगह {pool}:{dataset} से pool और dataset को साफ अलग दिखाना चाहिए। pool या snapshot के नाम भी user से न रखवाकर {hostname}-[A-Z], {pool name}_{datetime created} जैसे rules और numeric short names अपने-आप लगा दे तो अच्छा हो
    pool बनाते समय disk ID सीधे type न करानी पड़े, और /dev/sda, /dev/sdb से बनाने के बाद drive order बदल जाए तो confusion न हो, इसके लिए disk पर metadata store किया जाए
    progress हमेशा pv से दिखे, और weekly scrub तथा hourly/daily/weekly/monthly snapshots और cleanup अपने-आप configure हों
    अगर बिना pool वाली disk पर send किया जाए, तो confirmation लेने के बाद sending pool जैसी settings वाला single-disk pool बना दे, और zpool व zfs को एक ही command में मिला देना चाहिए
    encrypted dataset send करते समय --raw automatically इस्तेमाल हो, send का default --replicate हो, और जहां संभव हो -I इस्तेमाल हो। snapshot filesystem को hidden directory में छिपाने के बजाय snapshot datasets को आसानी से mount और browse करने का तरीका भी चाहिए
    • इसमें reasonable suggestions और बहुत strong preferences दोनों मिले-जुले हैं। ashift=12 default या {pool}:{dataset} syntax समझ आता है, लेकिन अब बदलना शायद मुश्किल है, और कुछ suggestions अनजाने use cases तोड़ सकते हैं
      hostname से pool name रखने का तरीका उन SAN pools के लिए सही नहीं है जिन्हें कई hosts से import किया जा सकता है
      weekly scrub, periodic snapshots, periodic cleanup मुझे operating system scheduler का काम लगता है। zpool और zfs को मिलाना भी संभव तो होगा, लेकिन आखिर में यह zfs -pool XXXX, zfs -volume XXXX जैसा बन जाएगा—समझ नहीं आता इसकी जरूरत क्यों है
      recursive datasets वास्तव में कुछ मामलों में उपयोगी होते हैं। वहीं zfs list को mount status, encryption status और key loaded status दिखाना चाहिए—इससे मैं पूरी तरह सहमत हूं
      disk ID न डालने वाली बात थोड़ी अस्पष्ट है। ID, WWN, label, sdX आदि कई तरीकों से specify किया जा सकता है, लेकिन कौन-सी disk इस्तेमाल करनी है यह तो किसी न किसी तरह बताना ही पड़ेगा
      disk पर metadata store करके order बदलने पर भी उसे खोज लेने वाली सुविधा पहले से मौजूद है। कुछ drives को बदलकर लगा दें और pool import करें, तब भी यह उन्हें ढूंढ लेता है
      कुछ suggestions defaults के रूप में ठीक हैं, लेकिन कुछ अपने usage pattern और जरूरतों से बाहर के मामलों पर पर्याप्त विचार नहीं करती लगतीं। ZFS बहुत ज्यादा तरह के users के लिए बना है
    • /dev/sda, /dev/sdb से pool बनाना और फिर ZFS का confuse होना, सच कहें तो ZFS की problem नहीं बल्कि उसे modern तरीके से न इस्तेमाल करने वाले user की problem ज्यादा है
      Linux में काफी लंबे समय से /dev/disk/by-id/ata-$manufactuer-$serial-$whatever जैसे पूर्ण references मौजूद हैं। pool बनाते समय ऐसे paths इस्तेमाल करने चाहिए
    • कई suggestions बहुत strongly opinionated हैं; यह अपने-आप में बुरा नहीं है, लेकिन वे existing conventions को बेवजह हिलाने जैसी लगती हैं। उदाहरण के लिए {pool}:{dataset} ही क्यों होना चाहिए, समझ नहीं आता
      अगर snapshot names खुद नहीं रखने हैं, तो मेरा बनाया छोटा tool https://github.com/rollcat/zfs-autosnap आपके काम आ सकता है
      zfs-autosnap snap को hourly cron में और zfs-autosnap gc को daily cron में डाल दें, तो यह retention policy के अनुसार snapshot history घुमाता रहेगा
      एक simple ZFS command wrapper इस्तेमाल करना मुश्किल नहीं है, इसलिए मेरा code लेकर अपना tool बना सकते हैं
    • मैंने कहीं पढ़ा था कि blacksmith apprentice के अंतिम tasks में से एक असली blacksmith द्वारा इस्तेमाल किए जाने वाले सभी tools—यानी anvil, hammer, tongs वगैरह—खुद बनाना होता है
      काम पर भी हमने उस दिन सोचे गए deployment form के हिसाब से ZFS arrays बनाने के लिए कई scripts लिखी थीं। उनमें zvol रखने के लिए LUKS-encrypted volume बनाना, naming rules standardize करना, ashift=12, lz4 compression जैसे defaults set करना शामिल था
      यह ZFS native encryption आने से काफी पहले की बात थी, और मौजूदा तरीके से कोई दिक्कत नहीं है, इसलिए ZFS encryption support के लिए scripts update नहीं कीं
      अब मुझे बहुत से flags याद नहीं रहते, लेकिन scripts documentation का काम करती हैं, और team के बाकी लोग बस make-zfs-big-mirror या make-big-zfs-undundant-raid0 चला देते हैं
      कभी साल में 20 से ज्यादा बार systems provision करने की नौबत आई, तो वह भी provisioning में automate हो सकता है
    • जैसा कि दूसरे लोग पहले ही कह चुके हैं, ये बहुत strongly opinionated suggestions हैं। राय रखना ठीक है, लेकिन कई items “Linux में मेरी familiar method जैसी नहीं है” से लेकर सचमुच problematic suggestions तक फैले हैं
      pool का name न रखने की बात समझ में नहीं आती। pools इतने frequently नहीं बनते, इसलिए बस name रख दें
      अगर snapshot name नहीं रखने हैं, तो httm और zfs allow इस्तेमाल कर सकते हैं। उदाहरण के लिए httm -S . rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount जैसा snapshot बनाता है
      zfs और zpool दोनों कई subcommands वाले बेहतरीन Unix commands हैं। मेरे हिसाब से ZFS designers ने और जटिल single management command न बनाने का बहुत smart निर्णय लिया
      snapshot datasets को साफ तौर पर mount और browse करना भी zfs mount से आसानी से संभव है। हालांकि एक stable virtual interface सभी file versions search करना आसान बनाता है, और कृपया मानें कि btrfs आदि में यह कहीं ज्यादा कठिन है। httm भी देखने लायक है
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • ZFS में कुछ और उपयोगी चीज़ें भी हैं। zpool-attach(8) और zpool-replace(8) के फर्क को जानना अच्छा है, और zfs list -t all -o space दिखाता है कि जगह कहाँ इस्तेमाल हो रही है
    बड़े बदलाव या upgrade से पहले operating system को सुरक्षित रखने के लिए ZFS Boot Environments सबसे बेहतरीन feature है। शुरुआत के लिए https://is.gd/BECTL उपयोगी हो सकता है
    zpool history poolname pool की configuration और बदलावों का पूरा इतिहास दिखाता है। उदाहरण के लिए zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m जैसे बदलाव दर्ज होते हैं
    guide में छूटी हुई एक महत्वपूर्ण जानकारी भी है। 3-way mirror में 3 disks में से 2 fail हो जाएँ तब भी data बचा रहता है, 4-way mirror में 4 में से 3 fail हो जाएँ तब भी बचता है, और N-way mirror में N में से N-1 disks fail हो जाएँ तब भी data सुरक्षित रहता है
    जब data सबसे महत्वपूर्ण हो लेकिन slots या disks ज़्यादा न हों, तब यह उपयोगी है

    • N-way mirror की एक खासियत यह भी है कि ZFS reads को कई disks में बाँटकर process कर सकता है। I/O operations की संख्या से सीमित rotational disks के दौर में यह बात काफी महत्वपूर्ण थी

  • कई सालों से बड़े multi-TB PostgreSQL database को ZFS पर चला रहा हूँ। ZFS की वजह से backups, पुराने snapshots पर आधारित test environments बनाना, और built-in compression से disk बचाना बहुत आसान हो गया
    रुचि हो तो अनुभव https://lackofimagination.org/2022/04/our-experience-with-po... पर पढ़ सकते हैं

  • ZFS शुरू करते समय सबसे ज़्यादा मदद FreeBSD के ZFS Handbook और Aaron Toponce के लेखों से मिली थी
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • मुझे FreeBSD documentation पसंद है
      इधर-उधर पड़ी ECC RAM 1GB वाली एक पुरानी HP Microserver पर FreeBSD install किया, और 500GB की 5 पुरानी hard disks भी थीं, इसलिए FreeBSD Handbook देखते हुए 5x mirror के रूप में configure किया। FreeBSD पहली बार इस्तेमाल कर रहा था, लेकिन यह बहुत आसानी से हो गया

  • हाल में मुख्य रूप से LAMP servers वाली infrastructure को काफी rebuild करते हुए, efficient backup replication और encryption के लिए सब कुछ Linux पर ZFS आधारित रखने का फैसला किया
    बहुत पहले से backups के लिए ZFS और rsync साथ में इस्तेमाल करता आया था, इसलिए काफी familiar था और नतीजा अच्छा रहा, लेकिन इसे सही तरीके से करने की कोशिश में उम्मीद से कहीं ज़्यादा समय लगा। खासकर databases और replication को लेकर web पर बहुत गलत सलाह भरी पड़ी थी
    database के लिए कम से कम block size alignment जैसी basic tuning करनी चाहिए। mariadb/InnoDB के मामले में Let's Encrypt की सामग्री https://github.com/letsencrypt/openzfs-nvme-databases बेहतरीन थी। हर item के पीछे कारण दिया है और कई sources cite किए हैं, इसलिए इसकी value बहुत है
    web पर और खोजें तो विरोधाभासी सलाह, किस्से और myths का अंतहीन सिलसिला मिलता है, जिनमें अधूरी और बिना आधार वाली theory जुड़ी होती है। आखिरकार खुद test करना, जिन चीज़ों को tune कर रहे हैं उन्हें समझना ज़रूरी है, और यह तय करना भी ठीक है कि कुछ tune नहीं करना
    replication के लिए मैं सच में manual pages recommend करता हूँ। ZFS मजबूत replication tools देता है, लेकिन वे इतने general-purpose हैं कि Git के low-level plumbing commands जैसे लगते हैं। यह assume नहीं करता कि आप SSH से इस्तेमाल करेंगे, इसलिए खुद जोड़ना पड़ता है, और automation के लिए edge cases तक सोचना पड़ता है, इसलिए शुरुआत में डरावना लग सकता है
    इसलिए लोग syncoid जैसे tools पर चले जाते हैं, लेकिन syncoid-style replication scripts में कुछ भयानक बातें थीं। वे ZFS का send --replication mode इस्तेमाल नहीं करते, बल्कि ज़्यादा flexible होने के नाम पर उसे Perl में अधूरा reimplement करते हैं
    शुरुआती testing में जब fresh restore किया और देखा कि सभी encryption roots टूट गए, और dataset properties अपने-आप पूरी तरह sync नहीं हो रहीं, तो दिमाग खराब हो जाता है। built-in recursive replication option ही इस्तेमाल करें तो ZFS यह सब संभाल देता है
    ठानकर अपनी script लिखें तो मुश्किल नहीं है। इसे simple रखें और syncoid की तरह pipeline में ढेर सारी गैरज़रूरी चीज़ें न डालें। असल testing में वे चीज़ें कभी-कभी speed भी घटाती हैं। progress pv से देखें और बस push कर दें, तो यह तेज़ी से चलता है
    शायद कभी अपनी replication script public करूँ। मुझे लगता है कि basics संभालते हुए replication को खराब तरीके से reimplement न करने वाली अच्छी reference scripts बहुत कम हैं

    • वह सामग्री io_capacity और io_capacity_max tuning का ज़िक्र करती है, लेकिन MySQL documentation खोलकर देखें कि असल में ये parameters क्या करते हैं, तो दुर्भाग्य से ये उतने उपयोगी नहीं लगते
      ये values change buffer merge जैसे background I/O को control करती हैं, और वास्तविक काम करने वाली main processes से I/O छीन सकती हैं
      काफी busy 120K QPS MySQL DB चलाने के अनुभव से, मुझे दोनों में से किसी को भी छूने की ज़रूरत नहीं पड़ी। अगर आपको लगता है कि इसकी ज़रूरत है, तो पहले redo log भरने में लगने वाला समय और buffer pool में dirty pages का ratio monitor करना चाहिए। शायद किसी और parameter को adjust करना बेहतर होगा
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • database में block size alignment जैसी basic tuning करते समय एक बात है जिसे आश्चर्यजनक रूप से check करना चाहिए। आम तौर पर record size match करने को कहा जाता है, और व्यवहार में इसका मतलब data रखने वाले ZFS filesystem का record size घटाना होता है
      किसी स्तर पर यह ज़्यादा efficient हो सकता है, लेकिन अनुभव के आधार पर यह compression ratio को काफी गिरा देता है
      एक दिलचस्प second-order effect के रूप में, workload पर निर्भर करता है, लेकिन अगर disk bandwidth bottleneck है तो throughput उल्टा खराब हो सकता है। compression की वजह से physical disk जितना संभाल सकती है उससे तेज़ पढ़ना-लिखना संभव होता है, लेकिन compression खराब कर दें तो read/write bandwidth पर बुरा असर पड़ सकता है

  • कुछ साल पहले से Linux पर ZFS इस्तेमाल करना शुरू किया था और कुल मिलाकर सब ठीक रहा
    बस एक बात ने चौंकाया: volblocksize का default value ज़्यादातर RAIDZ configurations के लिए काफ़ी खराब है। raw disk space का 50% न गंवाना हो तो value बढ़ानी पड़ती है
    संबंधित लेख ये हैं
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    आखिरकार ZFS से जुड़ी spreadsheets में से एक तक देखनी पड़ी
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • निजी तौर पर, mirror vdev की 50% efficiency को मैं simplicity और काफी बेहतर performance के लिए वाजिब कीमत मानता हूँ। अब RAIDZ pools को भी expand किया जा सकता है, लेकिन वे अब भी कहीं ज़्यादा जटिल हैं और performance भी उतनी अच्छी नहीं है

  • जब मैं छोटा और ज़्यादा नासमझ था, तब enthusiasts की बहुत-सी पोस्ट पढ़ीं कि open-source NAS OS, शायद FreeNAS और ZFS, कितने शानदार हैं। eBay से बेहद low-spec वाला पुराना HP micro server खरीदा और ठीक से जाने बिना कि कर क्या रहा हूँ, सीधे कूद पड़ा
    community forum पर कुछ सवाल पूछे, लेकिन ज़्यादातर जवाब “docs पढ़े हैं?”, “RAM पर्याप्त है?” जैसे थे
    वे docs पढ़ने में कठिन शैली वाली PowerPoint presentations थीं, थोड़ी प्रचारक-जैसी भाषा में, बहुत-सी prior knowledge मानकर चलती थीं, और नियमित रूप से update भी नहीं होती थीं। कितनी RAM चाहिए यह भी अस्पष्ट था, बस ज़ोर इस पर था कि जितनी हो सके उतनी लगाओ
    आखिरकार मैंने technology, hype और अपने knowledge level से जुड़े सारे warning signs नज़रअंदाज़ किए और बहुत-सा data खो दिया। बहुत कुछ सीखा

    • जानना चाहूँगा कि तुम्हें अंदाज़ा है यह लगभग कितने समय पहले की बात है। ZFS 2000s की शुरुआत से है और FreeNAS मुझे याद है 2005 में शुरू हुआ था
      filesystem अब कहीं ज़्यादा stable हो गया है, और docs भी मुझे लगता है ज़्यादा clear हो गए हैं
      फिर भी ext3 जैसे traditional journaling filesystems की तुलना में यह ज़्यादा powerful और advanced है, इसलिए अपने ही पैर पर कुल्हाड़ी मारने के तरीके भी ज़्यादा हैं

  • आगे के लिए कुछ बातें और छोड़ दूँ: ZFS की सारी redundancy vdev layer में होती है। zpool एक या उससे अधिक vdev से बनता है, और किसी भी हालत में अगर zpool के अंदर एक भी vdev खो गया तो zpool हमेशा के लिए नष्ट हो जाता है
    ऐतिहासिक रूप से RAIDZ, यानी parity RAID, disks जोड़कर expand नहीं किया जा सकता था। RAIDZ को बड़ा करने का एकमात्र तरीका array की हर disk को एक-एक कर बड़ी disk से बदलना था, और rebuild के दौरान उम्मीद करनी पड़ती थी कि कोई disk fail न हो
    बहुत amateur राय से कहूँ तो RAIDZ पर तभी विचार करूँगा जब disks की संख्या ज़्यादा हो, जैसे RAIDZ2 या RAIDZ3 में। अगर n<=6 हो और budget अनुमति दे, तो मैं कई mirror vdev इस्तेमाल करूँगा। production environment में अलग-अलग RAID की read/write performance metrics पर और research करनी चाहिए

    • mirror pool आम तौर पर ज़्यादा सुरक्षित तरीका है, यह सही है
      लेकिन RAIDZ1 की सलाह तभी दूँगा जब site-wide backup हो और अपनी क्षमता व monitoring पर काफी भरोसा हो
      मेरे मामले में 3x3 drive pool है, और snapshots को rack में कुछ U नीचे मौजूद backup target पर भेजता हूँ। वह backup target रोज़ wake up होता है और उसके पास 3x4 drive pool है, वह भी RAIDZ1 है
      NAS में drive failure होने पर मेरी योजना तुरंत backup शुरू करके snapshots स्वीकार कराने और फिर drive बदलने की है। इससे resilvering के दौरान दूसरी drive fail होने से data उड़ने की संभावना कम-से-कम हो जाती है
      सचमुच महत्वपूर्ण data तो बेशक बाहर भी रखा है

  • एक ZFS problem आ रही है जिसे समझ नहीं पा रहा हूँ। किसी zpool पर zpool status detected errors की list print करता है, लेकिन वे files में नहीं होते और हमेशा snapshots में, और शायद deleted snapshots जैसे दिखने वाले hexadecimal entries में ही दिखते हैं
    error के रूप में दिखाए गए snapshots delete करके zpool scrub दो बार चलाऊँ तो errors गायब हो जाते हैं और scrub भी कोई error नहीं ढूँढता। zpool status ने कभी किसी device पर error नहीं दिखाया
    files में error नहीं, devices में error नहीं, scrub में भी कोई error detect नहीं होता, लेकिन चलते रहने के दौरान हर दिन zpool status में 12 नए “errors” दिख जाते हैं। समझ नहीं आता यह कैसे हो रहा है

    • सच में अच्छा सवाल है। अभी duplicate issues खुद खोजने का समय नहीं है, लेकिन mailing list https://zfsonlinux.topicbox.com/groups/zfs-discuss और GitHub issues https://github.com/openzfs/zfs/issues में खोज सकते हैं या सवाल पूछ सकते हैं
      पहला थोड़ा अजीब दिखता है, लेकिन mailing list का normal web frontend है
    • मुझे भी यही समस्या आ रही है। कभी-कभी files सिर्फ snapshots में नहीं बल्कि current file version में भी corrupted लगती हैं
      उन्हें move या modify नहीं कर सकते, सिर्फ delete कर सकते हैं। कोई clue नहीं कि ये files corrupt क्यों हो रही हैं। गनीमत है कि वे सब बड़े Linux ISO थे, इसलिए catastrophic नहीं था