ໃນພາກຮຽນ spring ນີ້ພວກເຮົາໄດ້ສົນທະນາແລ້ວບາງຫົວຂໍ້ແນະນໍາ, ສໍາລັບການຍົກຕົວຢ່າງ, ວິທີການກວດສອບຄວາມໄວຂອງໄດຂອງທ່ານ и RAID ແມ່ນຫຍັງ. ໃນຄັ້ງທີສອງຂອງພວກເຂົາ, ພວກເຮົາຍັງສັນຍາວ່າຈະສືບຕໍ່ການສຶກສາການປະຕິບັດຂອງ multi-disk topologies ໃນ ZFS. ນີ້ແມ່ນລະບົບໄຟລ໌ຮຸ່ນຕໍ່ໄປທີ່ປະຈຸບັນໄດ້ຖືກປະຕິບັດຢູ່ທົ່ວທຸກແຫ່ງ: ຈາກ ຈາກຫນາກແອບເປີ ການ Ubuntu.

ດີ, ມື້ນີ້ແມ່ນມື້ທີ່ດີທີ່ສຸດທີ່ຈະໄດ້ຮູ້ຈັກກັບ ZFS, ຜູ້ອ່ານ inquisitive. ພຽງແຕ່ຮູ້ວ່າໃນຄວາມຄິດເຫັນທີ່ຖ່ອມຕົວຂອງນັກພັດທະນາ OpenZFS Matt Ahrens, "ມັນຍາກແທ້ໆ."

ແຕ່ກ່ອນທີ່ພວກເຮົາຈະໄປຫາຕົວເລກ - ແລະພວກເຂົາຈະ, ຂ້ອຍສັນຍາ - ສໍາລັບທາງເລືອກທັງຫມົດສໍາລັບການຕັ້ງຄ່າ ZFS ແປດ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ສົນທະນາກ່ຽວກັບ. ວິທີການ ໂດຍທົ່ວໄປ, ZFS ເກັບຂໍ້ມູນໃນແຜ່ນ.

Zpool, vdev ແລະອຸປະກອນ

ແຜນວາດສະນຸກເກີເຕັມນີ້ປະກອບມີສາມ vdevs ຊ່ວຍເຫຼືອ, ຫນຶ່ງໃນແຕ່ລະຫ້ອງຮຽນ, ແລະສີ່ສໍາລັບ RAIDz2.

ປົກກະຕິແລ້ວບໍ່ມີເຫດຜົນທີ່ຈະສ້າງສະນຸກເກີຂອງປະເພດ vdev ທີ່ບໍ່ກົງກັນແລະຂະຫນາດ - ແຕ່ບໍ່ມີຫຍັງຂັດຂວາງທ່ານຈາກການເຮັດເຊັ່ນນັ້ນຖ້າທ່ານຕ້ອງການ.

ເພື່ອເຂົ້າໃຈລະບົບໄຟລ໌ ZFS ຢ່າງແທ້ຈິງ, ທ່ານຈໍາເປັນຕ້ອງເບິ່ງຢ່າງໃກ້ຊິດກ່ຽວກັບໂຄງສ້າງຕົວຈິງຂອງມັນ. ຫນ້າທໍາອິດ, ZFS unifies ລະດັບປະເພນີຂອງປະລິມານແລະການຄຸ້ມຄອງລະບົບໄຟລ໌. ອັນທີສອງ, ມັນໃຊ້ກົນໄກການເຮັດທຸລະກໍາສໍາລັບການສໍາເນົາໃນການຂຽນ. ລັກສະນະເຫຼົ່ານີ້ຫມາຍຄວາມວ່າລະບົບມີໂຄງສ້າງທີ່ແຕກຕ່າງຈາກລະບົບໄຟລ໌ທໍາມະດາແລະ RAID arrays. ຊຸດທໍາອິດຂອງການກໍ່ສ້າງພື້ນຖານທີ່ຈະເຂົ້າໃຈແມ່ນສະນຸກເກີເກັບຮັກສາ (zpool), ອຸປະກອນ virtual (vdev), ແລະອຸປະກອນທີ່ແທ້ຈິງ (ອຸປະກອນ).

zpool

ສະລອຍນ້ໍາການເກັບຮັກສາ zpool ແມ່ນໂຄງສ້າງ ZFS ສູງສຸດ. ແຕ່ລະສະນຸກເກີປະກອບມີຫນຶ່ງຫຼືຫຼາຍອຸປະກອນ virtual. ໃນທາງກັບກັນ, ແຕ່ລະພວກມັນປະກອບດ້ວຍອຸປະກອນທີ່ແທ້ຈິງຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ (ອຸປະກອນ). ສະລອຍນ້ຳສະເໝືອນແມ່ນບລັອກທີ່ບັນຈຸດ້ວຍຕົນເອງ. ຄອມພິວເຕີເຄື່ອງຄອມພິວເຕີໜ່ວຍໜຶ່ງສາມາດບັນຈຸສອງ ຫຼືຫຼາຍກວ່ານັ້ນແຍກກັນໄດ້, ແຕ່ແຕ່ລະອັນແມ່ນເປັນເອກະລາດທັງໝົດ. ສະລອຍນ້ຳບໍ່ສາມາດແບ່ງປັນອຸປະກອນສະເໝືອນໄດ້.

ການຊໍ້າຊ້ອນຂອງ ZFS ແມ່ນຢູ່ໃນລະດັບອຸປະກອນ virtual, ບໍ່ແມ່ນຢູ່ໃນລະດັບສະນຸກເກີ. ບໍ່ມີການຊໍ້າຊ້ອນຢ່າງແທ້ຈິງໃນລະດັບສະນຸກເກີ - ຖ້າໄດ vdev ຫຼື vdev ພິເສດຖືກສູນເສຍ, ຫຼັງຈາກນັ້ນສະນຸກເກີທັງຫມົດຈະສູນເສຍໄປພ້ອມກັບມັນ.

ສະລອຍນ້ໍາການເກັບຮັກສາທີ່ທັນສະໄຫມສາມາດລອດຊີວິດຈາກການສູນເສຍ cache ຫຼືບັນທຶກອຸປະກອນ virtual - ເຖິງແມ່ນວ່າພວກເຂົາສາມາດສູນເສຍຂໍ້ມູນເປື້ອນເລັກນ້ອຍຖ້າພວກເຂົາສູນເສຍ vdev log ໃນລະຫວ່າງການໄຟຟ້າຫຼືລະບົບຂັດຂ້ອງ.

ມີຄວາມເຂົ້າໃຈຜິດທົ່ວໄປວ່າ ZFS "ເສັ້ນດ່າງຂໍ້ມູນ" ຖືກຂຽນໃນທົ່ວສະນຸກເກີທັງຫມົດ. ນີ້ບໍ່ແມ່ນຄວາມຈິງ. Zpool ບໍ່ແມ່ນ RAID0 ຕະຫລົກທັງຫມົດ, ມັນເປັນເລື່ອງຕະຫລົກຫຼາຍ JBOD ດ້ວຍກົນໄກການແຈກຢາຍຕົວແປທີ່ຊັບຊ້ອນ.

ສໍາລັບສ່ວນໃຫຍ່, ລາຍການໄດ້ຖືກແຈກຢາຍໃນບັນດາອຸປະກອນ virtual ທີ່ມີຢູ່ຕາມພື້ນທີ່ຫວ່າງທີ່ມີຢູ່, ດັ່ງນັ້ນໃນທາງທິດສະດີພວກມັນທັງຫມົດຈະຖືກຕື່ມໃສ່ໃນເວລາດຽວກັນ. ໃນ ZFS ຮຸ່ນຕໍ່ມາ, ການນໍາໃຊ້ vdev ໃນປະຈຸບັນ (ການນໍາໃຊ້) ໄດ້ຖືກພິຈາລະນາ - ຖ້າອຸປະກອນ virtual ໃດຫນຶ່ງແມ່ນ busier ຫຼາຍກ່ວາອື່ນ (ຕົວຢ່າງ, ເນື່ອງຈາກການໂຫຼດ), ມັນຈະຖືກຂ້າມຊົ່ວຄາວສໍາລັບການຂຽນ, ເຖິງວ່າຈະມີການຟຣີສູງສຸດ. ອັດຕາສ່ວນພື້ນທີ່.

ກົນໄກການຊອກຄົ້ນຫາການນໍາໃຊ້ທີ່ສ້າງຂຶ້ນໃນວິທີການຈັດສັນການຂຽນແບບ ZFS ທີ່ທັນສະໄຫມສາມາດຫຼຸດຜ່ອນຄວາມລ່າຊ້າແລະເພີ່ມການສົ່ງຜ່ານໃນໄລຍະເວລາຂອງການໂຫຼດສູງຜິດປົກກະຕິ - ແຕ່ມັນບໍ່ໄດ້. carte blanch ກ່ຽວກັບການປະສົມ HDDs ຊ້າ ແລະ SSDs ໄວໂດຍບໍ່ໄດ້ສະໝັກໃຈໃນກຸ່ມດຽວ. ສະນຸກເກີທີ່ບໍ່ເທົ່າທຽມກັນດັ່ງກ່າວຍັງຈະເຮັດວຽກຢູ່ໃນຄວາມໄວຂອງອຸປະກອນທີ່ຊ້າທີ່ສຸດ, ນັ້ນແມ່ນ, ຄືກັບວ່າມັນປະກອບດ້ວຍອຸປະກອນດັ່ງກ່າວທັງຫມົດ.

vdev

ແຕ່ລະສະລອຍນ້ໍາການເກັບຮັກສາປະກອບດ້ວຍຫນຶ່ງຫຼືຫຼາຍອຸປະກອນ virtual (ອຸປະກອນ virtual, vdev). ໃນທາງກັບກັນ, ແຕ່ລະ vdev ມີອຸປະກອນທີ່ແທ້ຈິງຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ. ອຸປະກອນ virtual ສ່ວນໃຫຍ່ຖືກນໍາໃຊ້ສໍາລັບການເກັບຮັກສາຂໍ້ມູນງ່າຍດາຍ, ແຕ່ມີຫ້ອງຮຽນຜູ້ຊ່ວຍ vdev ຫຼາຍ, ລວມທັງ CACHE, LOG, ແລະ SPECIAL. ແຕ່ລະ vdev ເຫຼົ່ານີ້ສາມາດມີຫນຶ່ງໃນຫ້າ topologies: ອຸປະກອນດຽວ (ອຸປະກອນດຽວ), RAIDz1, RAIDz2, RAIDz3, ຫຼື mirror (ກະຈົກ).

RAIDz1, RAIDz2 ແລະ RAIDz3 ແມ່ນແນວພັນພິເສດຂອງສິ່ງທີ່ຄົນເກົ່າເອີ້ນວ່າ RAID ເທົ່າ (ເສັ້ນຂວາງ) parity. 1, 2 ແລະ 3 ອ້າງອີງເຖິງຈໍານວນ parity blocks ຖືກຈັດສັນໃຫ້ແຕ່ລະແຖບຂໍ້ມູນ. ແທນທີ່ຈະເປັນແຜ່ນແຍກຕ່າງຫາກສໍາລັບ parity, ອຸປະກອນ virtual RAIDz ແຈກຢາຍ parity ນີ້ເຄິ່ງເທົ່າກັນໃນທົ່ວແຜ່ນ. A RAIDz array ສາມາດສູນເສຍແຜ່ນຫຼາຍເທົ່າທີ່ມັນມີຕັນ parity; ຖ້າມັນສູນເສຍອັນອື່ນ, ມັນຈະຂັດແລະເອົາສະລອຍນ້ໍາກັບມັນ.

ໃນອຸປະກອນ virtual mirrored (mirror vdev), ແຕ່ລະ block ຖືກເກັບໄວ້ໃນແຕ່ລະອຸປະກອນໃນ vdev. ເຖິງແມ່ນວ່າກະຈົກສອງກວ້າງແມ່ນທົ່ວໄປທີ່ສຸດ, ຈໍານວນຂອງອຸປະກອນທີ່ຕົນເອງມັກສາມາດຢູ່ໃນກະຈົກ - triples ມັກຈະຖືກນໍາໃຊ້ໃນການຕິດຕັ້ງຂະຫນາດໃຫຍ່ສໍາລັບການປັບປຸງປະສິດທິພາບການອ່ານແລະຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ. ກະຈົກ vdev ສາມາດລອດພົ້ນຈາກຄວາມລົ້ມເຫລວໄດ້ຕາບໃດທີ່ຢ່າງຫນ້ອຍຫນຶ່ງອຸປະກອນໃນ vdev ຍັງສືບຕໍ່ເຮັດວຽກ.

vdevs ດຽວແມ່ນອັນຕະລາຍໂດຍທໍາມະຊາດ. ອຸປະກອນ virtual ດັ່ງກ່າວຈະບໍ່ຢູ່ລອດຄວາມລົ້ມເຫລວດຽວ - ແລະຖ້າຖືກນໍາໃຊ້ເປັນການເກັບຮັກສາຫຼື vdev ພິເສດ, ຫຼັງຈາກນັ້ນຄວາມລົ້ມເຫຼວຂອງມັນຈະນໍາໄປສູ່ການທໍາລາຍສະນຸກເກີທັງຫມົດ. ຈົ່ງລະມັດລະວັງຫຼາຍຢູ່ທີ່ນີ້.

CACHE, LOG, ແລະ SPECIAL VAs ສາມາດຖືກສ້າງຂື້ນໂດຍໃຊ້ topologies ຂ້າງເທິງໃດໆ - ແຕ່ຈື່ວ່າການສູນເສຍ SPECIAL VA ຫມາຍເຖິງການສູນເສຍສະນຸກເກີ, ດັ່ງນັ້ນ topology ຊ້ໍາຊ້ອນແມ່ນແນະນໍາໃຫ້ສູງ.

ອຸປະກອນ

ນີ້ແມ່ນອາດຈະເປັນຄໍາສັບທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຂົ້າໃຈໃນ ZFS - ມັນເປັນອຸປະກອນການເຂົ້າເຖິງແບບສຸ່ມທາງຕັນ. ຈື່ໄວ້ວ່າອຸປະກອນສະເໝືອນແມ່ນປະກອບດ້ວຍອຸປະກອນແຕ່ລະອັນ, ໃນຂະນະທີ່ສະນຸກເກີແມ່ນປະກອບດ້ວຍອຸປະກອນສະເໝືອນ.

ແຜ່ນ - ບໍ່ວ່າຈະເປັນສະນະແມ່ເຫຼັກຫຼືແຂງ - ແມ່ນອຸປະກອນຕັນທົ່ວໄປທີ່ສຸດທີ່ຖືກນໍາໃຊ້ເປັນອາຄານຂອງ vdev. ຢ່າງໃດກໍຕາມ, ອຸປະກອນໃດໆທີ່ມີຕົວອະທິບາຍໃນ /dev ຈະເຮັດ, ດັ່ງນັ້ນຮາດແວ RAID arrays ທັງຫມົດສາມາດຖືກນໍາໃຊ້ເປັນອຸປະກອນແຍກຕ່າງຫາກ.

ໄຟລ໌ດິບທີ່ງ່າຍດາຍແມ່ນຫນຶ່ງໃນອຸປະກອນບລັອກທາງເລືອກທີ່ສໍາຄັນທີ່ສຸດທີ່ vdev ສາມາດສ້າງຂຶ້ນຈາກ. ທົດສອບສະນຸກເກີຈາກ ໄຟລ໌ກະແຈກກະຈາຍ ເປັນວິທີທີ່ມີປະໂຫຍດຫຼາຍໃນການກວດສອບຄຳສັ່ງສະນຸກເກີ ແລະເບິ່ງວ່າມີພື້ນທີ່ຫວ່າງຫຼາຍປານໃດໃນສະລອຍນ້ຳ ຫຼືອຸປະກອນສະເໝືອນຂອງ topology ທີ່ໃຫ້ໄວ້.

ທ່ານ​ສາ​ມາດ​ສ້າງ​ສະ​ນຸກ​ເກີ​ການ​ທົດ​ສອບ​ຈາກ​ໄຟລ​໌ sparse ໃນ​ພຽງ​ແຕ່​ສອງ​ສາມ​ວິ​ນາ​ທີ - ແຕ່​ບໍ່​ລືມ​ທີ່​ຈະ​ລົບ​ທັງ​ຫມົດ​ສະ​ນຸກ​ເກີ​ແລະ​ອົງ​ປະ​ກອບ​ຂອງ​ມັນ​ຫຼັງ​ຈາກ​ນັ້ນ​.

ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການໃສ່ເຄື່ອງແມ່ຂ່າຍໃນແປດແຜ່ນແລະວາງແຜນທີ່ຈະໃຊ້ແຜ່ນ 10 TB (~9300 GiB) - ແຕ່ທ່ານບໍ່ແນ່ໃຈວ່າ topology ໃດທີ່ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງທ່ານ. ໃນຕົວຢ່າງຂ້າງເທິງ, ພວກເຮົາສ້າງສະນຸກເກີການທົດສອບຈາກໄຟລ໌ທີ່ແຕກຫັກໃນວິນາທີ - ແລະໃນປັດຈຸບັນພວກເຮົາຮູ້ວ່າ RAIDz2 vdev ຂອງແປດ 10 TB ດິດໃຫ້ 50 TiB ຂອງຄວາມສາມາດທີ່ສາມາດໃຊ້ໄດ້.

ອຸປະກອນພິເສດອີກອັນໜຶ່ງແມ່ນ SPARE (ອາໄຫຼ່). ອຸ​ປະ​ກອນ Hot-swap, ບໍ່​ເຫມືອນ​ກັບ​ອຸ​ປະ​ກອນ​ປົກ​ກະ​ຕິ, ເປັນ​ຂອງ​ສະ​ນຸກ​ເກີ​ທັງ​ຫມົດ, ແລະ​ບໍ່​ແມ່ນ​ອຸ​ປະ​ກອນ virtual ດຽວ. ຖ້າ vdev ໃນສະລອຍນ້ໍາລົ້ມເຫລວແລະອຸປະກອນ spare ເຊື່ອມຕໍ່ກັບສະນຸກເກີແລະມີ, ຫຼັງຈາກນັ້ນມັນຈະເຂົ້າຮ່ວມ vdev ທີ່ຖືກກະທົບໂດຍອັດຕະໂນມັດ.

ຫຼັງຈາກການເຊື່ອມຕໍ່ກັບ vdev ທີ່ຖືກກະທົບ, ອຸປະກອນ spare ເລີ່ມຕົ້ນທີ່ຈະໄດ້ຮັບສໍາເນົາຫຼືການກໍ່ສ້າງຄືນໃຫມ່ຂອງຂໍ້ມູນທີ່ຄວນຈະຢູ່ໃນອຸປະກອນທີ່ຂາດຫາຍໄປ. ໃນ RAID ແບບດັ້ງເດີມນີ້ເອີ້ນວ່າການກໍ່ສ້າງຄືນໃຫມ່, ໃນຂະນະທີ່ຢູ່ໃນ ZFS ມັນຖືກເອີ້ນວ່າ resilvering.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າອຸປະກອນ spare ບໍ່ໄດ້ປ່ຽນແທນອຸປະກອນທີ່ລົ້ມເຫລວຢ່າງຖາວອນ. ນີ້ແມ່ນພຽງແຕ່ເປັນການທົດແທນຊົ່ວຄາວເພື່ອຫຼຸດຜ່ອນເວລາທີ່ vdev ຖືກທໍາລາຍ. ຫຼັງຈາກຜູ້ເບິ່ງແຍງລະບົບປ່ຽນແທນ vdev ທີ່ລົ້ມເຫລວ, ການຊໍ້າຊ້ອນຈະຖືກຟື້ນຟູກັບອຸປະກອນຖາວອນນັ້ນ, ແລະ SPARE ຖືກຕັດການເຊື່ອມຕໍ່ຈາກ vdev ແລະກັບຄືນໄປເຮັດວຽກເປັນອາໄຫຼ່ສໍາລັບສະລອຍນ້ໍາທັງຫມົດ.

ຊຸດຂໍ້ມູນ, ຕັນແລະຂະແຫນງການ

ຊຸດຕໍ່ໄປຂອງອາຄານເພື່ອເຂົ້າໃຈໃນການເດີນທາງ ZFS ຂອງພວກເຮົາແມ່ນຫນ້ອຍກ່ຽວກັບຮາດແວແລະເພີ່ມເຕີມກ່ຽວກັບວິທີການຂໍ້ມູນຕົວມັນເອງຖືກຈັດແລະເກັບຮັກສາ. ພວກເຮົາກໍາລັງຂ້າມສອງສາມລະດັບຢູ່ທີ່ນີ້ - ເຊັ່ນ metaslab - ເພື່ອບໍ່ໃຫ້ clutter ເຖິງລາຍລະອຽດໃນຂະນະທີ່ຮັກສາຄວາມເຂົ້າໃຈຂອງໂຄງສ້າງໂດຍລວມ.

ຊຸດຂໍ້ມູນ (ຊຸດຂໍ້ມູນ)

ເມື່ອພວກເຮົາສ້າງຊຸດຂໍ້ມູນທໍາອິດ, ມັນຈະສະແດງພື້ນທີ່ສະລອຍນ້ໍາທີ່ມີຢູ່ທັງຫມົດ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາກໍານົດໂຄຕ້າ - ແລະປ່ຽນຈຸດ mount. ວິເສດ!

Zvol ແມ່ນສໍາລັບສ່ວນໃຫຍ່ພຽງແຕ່ຊຸດຂໍ້ມູນທີ່ຖືກຖອດອອກຈາກຊັ້ນລະບົບໄຟລ໌ຂອງມັນ, ເຊິ່ງພວກເຮົາກໍາລັງປ່ຽນແທນທີ່ນີ້ດ້ວຍລະບົບໄຟລ໌ ext4 ປົກກະຕິຢ່າງສົມບູນ.

ຊຸດຂໍ້ມູນ ZFS ແມ່ນປະມານຄືກັນກັບລະບົບໄຟລ໌ທີ່ຕິດຕັ້ງມາດຕະຖານ. ເຊັ່ນດຽວກັນກັບລະບົບໄຟລ໌ປົກກະຕິ, ຢູ່ glance ທໍາອິດມັນຄ້າຍຄື "ພຽງແຕ່ໂຟນເດີອື່ນ". ແຕ່ຄືກັນກັບລະບົບໄຟລ໌ທີ່ສາມາດເຊື່ອມຕໍ່ໄດ້ປົກກະຕິ, ແຕ່ລະຊຸດຂໍ້ມູນ ZFS ມີຊຸດຄຸນສົມບັດພື້ນຖານຂອງຕົນເອງ.

ກ່ອນອື່ນ ໝົດ, ຊຸດຂໍ້ມູນສາມາດມີໂຄຕ້າທີ່ຖືກມອບ ໝາຍ. ຖ້າຕັ້ງ zfs set quota=100G poolname/datasetname, ຫຼັງຈາກນັ້ນທ່ານຈະບໍ່ສາມາດຂຽນໃສ່ໂຟນເດີທີ່ຕິດຕັ້ງ /poolname/datasetname ຫຼາຍກ່ວາ 100 GiB.

ສັງເກດເຫັນການມີ - ແລະບໍ່ມີ - ຂອງ slashes ໃນຕອນຕົ້ນຂອງແຕ່ລະແຖວ? ແຕ່ລະຊຸດຂໍ້ມູນມີສະຖານທີ່ຂອງຕົນເອງໃນທັງລະບົບ ZFS hierarchy ແລະລະບົບ mount hierarchy. ບໍ່ມີຕົວເລື່ອນຊັ້ນນໍາໃນລໍາດັບ ZFS - ທ່ານເລີ່ມຕົ້ນດ້ວຍຊື່ສະນຸກເກີແລະຫຼັງຈາກນັ້ນເສັ້ນທາງຈາກຊຸດຂໍ້ມູນຫນຶ່ງໄປຫາຊຸດຕໍ່ໄປ. ຍົກ​ຕົວ​ຢ່າງ, pool/parent/child ສໍາລັບຊຸດຂໍ້ມູນທີ່ມີຊື່ child ພາຍໃຕ້ຊຸດຂໍ້ມູນຂອງພໍ່ແມ່ parent ໃນສະນຸກເກີທີ່ມີຊື່ສ້າງສັນ pool.

ໂດຍຄ່າເລີ່ມຕົ້ນ, ຈຸດເຊື່ອມຕໍ່ຂອງຊຸດຂໍ້ມູນຈະທຽບເທົ່າກັບຊື່ຂອງມັນຢູ່ໃນລຳດັບ ZFS, ໂດຍມີເຄື່ອງໝາຍທັບນຳ - ສະນຸກເກີທີ່ມີຊື່ pool ຕິດ​ຕັ້ງ​ເປັນ /pool, ຊຸດຂໍ້ມູນ parent ຕິດຢູ່ໃນ /pool/parent, ແລະຊຸດຂໍ້ມູນເດັກນ້ອຍ child ຕິດຢູ່ໃນ /pool/parent/child. ຢ່າງໃດກໍ່ຕາມ, ຈຸດເຊື່ອມຕໍ່ຂອງຊຸດຂໍ້ມູນສາມາດປ່ຽນແປງໄດ້.

ຖ້າພວກເຮົາລະບຸ zfs set mountpoint=/lol pool/parent/child, ຫຼັງຈາກນັ້ນຊຸດຂໍ້ມູນ pool/parent/child ຕິດ​ຕັ້ງ​ໃນ​ລະ​ບົບ​ເປັນ​ /lol.

ນອກເຫນືອຈາກຊຸດຂໍ້ມູນ, ພວກເຮົາຄວນກ່າວເຖິງປະລິມານ (zvols). ປະລິມານປະມານເທົ່າກັບຊຸດຂໍ້ມູນ, ເວັ້ນເສຍແຕ່ວ່າມັນບໍ່ມີລະບົບໄຟລ໌ - ມັນເປັນພຽງແຕ່ອຸປະກອນບລັອກ. ທ່ານສາມາດ, ສໍາລັບການຍົກຕົວຢ່າງ, ສ້າງ zvol ດ້ວຍ​ຊື່ mypool/myzvol, ຫຼັງຈາກນັ້ນຈັດຮູບແບບມັນດ້ວຍລະບົບໄຟລ໌ ext4, ແລະຫຼັງຈາກນັ້ນ mount ລະບົບໄຟລ໌ນັ້ນ - ໃນປັດຈຸບັນທ່ານມີລະບົບໄຟລ໌ ext4, ແຕ່ມີລັກສະນະຄວາມປອດໄພທັງຫມົດຂອງ ZFS! ນີ້ອາດຈະເບິ່ງຄືວ່າໂງ່ຢູ່ໃນເຄື່ອງດຽວ, ແຕ່ເຮັດໃຫ້ຄວາມຮູ້ສຶກຫຼາຍເປັນ backend ໃນເວລາທີ່ສົ່ງອອກອຸປະກອນ iSCSI.

ທ່ອນໄມ້

ໄຟລ໌ແມ່ນສະແດງໂດຍຫນຶ່ງຫຼືຫຼາຍຕັນ. ແຕ່ລະບລັອກຖືກເກັບໄວ້ໃນອຸປະກອນ virtual ຫນຶ່ງ. ຂະຫນາດຂອງຕັນແມ່ນປົກກະຕິແລ້ວເທົ່າກັບພາລາມິເຕີ ຂະໜາດບັນທຶກ, ແຕ່ສາມາດຫຼຸດລົງເປັນ 2^ປ່ຽນຖ້າມັນມີ metadata ຫຼືໄຟລ໌ຂະຫນາດນ້ອຍ.

ພວກເຮົາແທ້ໆ ແທ້ ຢ່າເວົ້າຕະຫຼົກກ່ຽວກັບການລົງໂທດການປະຕິບັດອັນໃຫຍ່ຫຼວງຖ້າທ່ານກໍານົດການເລື່ອນຂະຫນາດນ້ອຍເກີນໄປ

ໃນສະນຸກເກີ ZFS, ຂໍ້ມູນທັງຫມົດ, ລວມທັງ metadata, ຖືກເກັບໄວ້ໃນບລັອກ. ຂະຫນາດບລັອກສູງສຸດສໍາລັບແຕ່ລະຊຸດຂໍ້ມູນແມ່ນຖືກກໍານົດໄວ້ໃນຊັບສິນ recordsize (ຂະຫນາດບັນທຶກ). ຂະຫນາດບັນທຶກສາມາດປ່ຽນແປງໄດ້, ແຕ່ນີ້ຈະບໍ່ປ່ຽນແປງຂະຫນາດຫຼືສະຖານທີ່ຂອງບລັອກໃດໆທີ່ໄດ້ຂຽນໄວ້ໃນຊຸດຂໍ້ມູນ - ມັນມີຜົນກະທົບພຽງແຕ່ບລັອກໃຫມ່ຍ້ອນວ່າພວກເຂົາຖືກຂຽນ.

ເວັ້ນເສຍແຕ່ໄດ້ລະບຸໄວ້ເປັນຢ່າງອື່ນ, ຂະຫນາດບັນທຶກເລີ່ມຕົ້ນໃນປັດຈຸບັນແມ່ນ 128 KiB. ມັນເປັນປະເພດຂອງການຊື້ຂາຍທີ່ຫຍຸ້ງຍາກທີ່ການປະຕິບັດບໍ່ສົມບູນແບບ, ແຕ່ມັນບໍ່ຂີ້ຮ້າຍໃນກໍລະນີຫຼາຍທີ່ສຸດ. Recordsize ສາມາດຕັ້ງຄ່າໄດ້ຈາກ 4K ຫາ 1M (ດ້ວຍການຕັ້ງຄ່າຂັ້ນສູງ recordsize ທ່ານ​ສາ​ມາດ​ຕິດ​ຕັ້ງ​ຫຼາຍ​, ແຕ່​ວ່າ​ນີ້​ແມ່ນ​ບໍ່​ຄ່ອຍ​ເປັນ​ຄວາມ​ຄິດ​ທີ່​ດີ​)​.

ບຼັອກໃດນຶ່ງໝາຍເຖິງຂໍ້ມູນຂອງໄຟລ໌ດຽວເທົ່ານັ້ນ - ທ່ານບໍ່ສາມາດບີບສອງໄຟລ໌ທີ່ແຕກຕ່າງກັນເຂົ້າໄປໃນບລັອກດຽວໄດ້. ແຕ່ລະໄຟລ໌ປະກອບດ້ວຍຫນຶ່ງຫຼືຫຼາຍຕັນ, ຂຶ້ນກັບຂະຫນາດ. ຖ້າຂະຫນາດໄຟລ໌ມີຂະຫນາດນ້ອຍກວ່າຂະຫນາດບັນທຶກ, ມັນຈະຖືກເກັບໄວ້ໃນຂະຫນາດບລັອກທີ່ນ້ອຍກວ່າ - ຕົວຢ່າງ, ບລັອກທີ່ມີໄຟລ໌ 2 KiB ຈະຄອບຄອງພຽງແຕ່ຫນຶ່ງຂະແຫນງ 4 KiB ໃນແຜ່ນ.

ຖ້າໄຟລ໌ມີຂະຫນາດໃຫຍ່ພຽງພໍແລະຕ້ອງການຫຼາຍຕັນ, ຫຼັງຈາກນັ້ນບັນທຶກທັງຫມົດທີ່ມີໄຟລ໌ນີ້ຈະມີຂະຫນາດ recordsize - ລວມທັງການເຂົ້າສຸດທ້າຍ, ສ່ວນຕົ້ນຕໍທີ່ອາດຈະເປັນ ພື້ນທີ່ບໍ່ໄດ້ໃຊ້.

zvols ບໍ່ມີຊັບສິນ recordsize — ແທນ​ທີ່​ຈະ​ເປັນ​ພວກ​ເຂົາ​ເຈົ້າ​ມີ​ຊັບ​ສິນ​ທຽບ​ເທົ່າ​ volblocksize.

ຂະແໜງການ

ສຸດທ້າຍ, ການກໍ່ສ້າງພື້ນຖານທີ່ສຸດແມ່ນຂະແຫນງການ. ມັນເປັນຫນ່ວຍງານທາງກາຍະພາບທີ່ນ້ອຍທີ່ສຸດທີ່ສາມາດຂຽນຫາຫຼືອ່ານຈາກອຸປະກອນພື້ນຖານ. ສໍາລັບຫຼາຍໆທົດສະວັດ, ແຜ່ນສ່ວນໃຫຍ່ໃຊ້ຂະແຫນງ 512-byte. ບໍ່ດົນມານີ້, ແຜ່ນສ່ວນໃຫຍ່ຖືກຕັ້ງເປັນຂະແຫນງ 4 KiB, ແລະບາງ - ໂດຍສະເພາະແມ່ນ SSDs - ມີຂະແຫນງການ 8 KiB ຫຼືຫຼາຍກວ່ານັ້ນ.

ລະບົບ ZFS ມີຄຸນສົມບັດທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດຂະຫນາດຂະແຫນງການດ້ວຍຕົນເອງ. ຊັບສິນນີ້ ashift. ຂ້ອນຂ້າງສັບສົນ, ashift ແມ່ນພະລັງງານຂອງສອງ. ຍົກ​ຕົວ​ຢ່າງ, ashift=9 ຫມາຍຄວາມວ່າຂະຫນາດຂອງຂະແຫນງການ 2^9, ຫຼື 512 bytes.

ZFS ສອບຖາມລະບົບປະຕິບັດການສຳລັບຂໍ້ມູນລະອຽດກ່ຽວກັບອຸປະກອນແຕ່ລະບລັອກເມື່ອມັນຖືກເພີ່ມເຂົ້າໃນ vdev ໃໝ່ ແລະໃນທາງທິດສະດີ, ຈະຕັ້ງຄ່າ ashift ໂດຍອັດຕະໂນມັດຢ່າງເໝາະສົມໂດຍອີງໃສ່ຂໍ້ມູນນີ້. ແຕ່ຫນ້າເສຍດາຍ, ໄດຣຟ໌ຫຼາຍອັນຕົວະກ່ຽວກັບຂະໜາດຂອງຂະແໜງການຂອງເຂົາເຈົ້າເພື່ອຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບ Windows XP (ເຊິ່ງບໍ່ສາມາດເຂົ້າໃຈໄດຣຟ໌ທີ່ມີຂະໜາດຂອງເຊກເຕີທີ່ແຕກຕ່າງກັນໄດ້).

ນີ້ຫມາຍຄວາມວ່າຜູ້ບໍລິຫານ ZFS ໄດ້ຖືກແນະນໍາຢ່າງແຂງແຮງທີ່ຈະຮູ້ຂະຫນາດຂອງຂະແຫນງການຕົວຈິງຂອງອຸປະກອນຂອງພວກເຂົາແລະກໍານົດດ້ວຍຕົນເອງ ashift. ຖ້າ ashift ຖືກຕັ້ງໄວ້ຕ່ໍາເກີນໄປ, ຫຼັງຈາກນັ້ນ, ຈໍານວນຂອງການອ່ານ / ຂຽນການດໍາເນີນການເພີ່ມຂຶ້ນທາງດາລາສາດ. ດັ່ງນັ້ນ, ການຂຽນ 512-byte "sectors" ເຂົ້າໄປໃນຂະແຫນງການ 4 KiB ທີ່ແທ້ຈິງຫມາຍຄວາມວ່າຕ້ອງຂຽນ "sector", ຫຼັງຈາກນັ້ນອ່ານຂະແຫນງ 4 KiB, ດັດແປງມັນດ້ວຍ "sector" 512-byte ທີສອງ, ຂຽນມັນກັບຄືນໄປບ່ອນໃຫມ່. ຂະແຫນງການ 4 KiB, ແລະອື່ນໆ. ສໍາລັບແຕ່ລະລາຍການ.

ໃນໂລກທີ່ແທ້ຈິງ, ການລົງໂທດດັ່ງກ່າວ hits Samsung EVO SSDs, ເຊິ່ງ ashift=13, ແຕ່ SSDs ເຫຼົ່ານີ້ນອນກ່ຽວກັບຂະຫນາດຂອງຂະແຫນງການຂອງເຂົາເຈົ້າ, ແລະດັ່ງນັ້ນຄ່າເລີ່ມຕົ້ນແມ່ນຕັ້ງເປັນ ashift=9. ຖ້າຜູ້ເບິ່ງແຍງລະບົບທີ່ມີປະສົບການບໍ່ປ່ຽນແປງການຕັ້ງຄ່ານີ້, ຫຼັງຈາກນັ້ນ SSD ນີ້ເຮັດວຽກ ຊ້າກວ່າ HDD ສະນະແມ່ເຫຼັກທໍາມະດາ.

ສໍາລັບການປຽບທຽບ, ສໍາລັບຂະຫນາດໃຫຍ່ເກີນໄປ ashift ຕົວຈິງແລ້ວບໍ່ມີການລົງໂທດ. ບໍ່ມີການລົງໂທດການປະຕິບັດຕົວຈິງ, ແລະການເພີ່ມຂື້ນຂອງພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້ແມ່ນ infinitesimal (ຫຼືສູນທີ່ມີການບີບອັດເປີດ). ດັ່ງນັ້ນ, ພວກເຮົາແນະນໍາຢ່າງແຂງແຮງວ່າແມ້ແຕ່ໄດທີ່ນໍາໃຊ້ຂະແຫນງ 512-byte ຕິດຕັ້ງ ashift=12 ຫຼື​ແມ້​ກະ​ທັ້ງ ashift=13ເພື່ອປະເຊີນກັບອະນາຄົດດ້ວຍຄວາມຫມັ້ນໃຈ.

ຄຸນ​ສົມ​ບັດ ashift ຖືກກໍານົດໄວ້ສໍາລັບແຕ່ລະອຸປະກອນ virtual vdev, ແລະ ບໍ່ແມ່ນສໍາລັບສະນຸກເກີ, ດັ່ງທີ່ຫຼາຍຄົນຄິດຜິດ - ແລະບໍ່ປ່ຽນແປງຫຼັງຈາກການຕິດຕັ້ງ. ຖ້າເຈົ້າຕີໂດຍບັງເອີນ ashift ເມື່ອທ່ານເພີ່ມ vdev ໃຫມ່ໃສ່ສະນຸກເກີ, ທ່ານມີມົນລະພິດໃນສະນຸກເກີທີ່ມີອຸປະກອນທີ່ມີປະສິດທິພາບຕໍ່າແລະມັກຈະບໍ່ມີທາງເລືອກອື່ນນອກເຫນືອຈາກການທໍາລາຍສະລອຍນ້ໍາແລະເລີ່ມຕົ້ນໃຫມ່. ເຖິງແມ່ນວ່າການຖອນ vdev ຈະບໍ່ຊ່ວຍປະຢັດທ່ານຈາກການຕັ້ງຄ່າທີ່ແຕກຫັກ ashift!

ກົນໄກການຄັດລອກໃນການຂຽນ

ຖ້າລະບົບໄຟລ໌ປົກກະຕິຕ້ອງການຂຽນທັບຂໍ້ມູນ, ມັນຈະປ່ຽນແຕ່ລະບລັອກທີ່ມັນຢູ່

ລະບົບໄຟລ໌ copy-on-write ຂຽນເວີຊັນບລັອກໃໝ່ແລ້ວປົດລັອກເວີຊັນເກົ່າ

ໃນລັກສະນະທີ່ບໍ່ມີຕົວຕົນ, ຖ້າພວກເຮົາບໍ່ສົນໃຈສະຖານທີ່ທາງດ້ານຮ່າງກາຍທີ່ແທ້ຈິງຂອງຕັນ, ຫຼັງຈາກນັ້ນ, "ຂໍ້ມູນ comet" ຂອງພວກເຮົາຖືກແປເປັນ "ແມ່ທ້ອງຂໍ້ມູນ" ທີ່ເຄື່ອນຍ້າຍຈາກຊ້າຍໄປຂວາໃນທົ່ວແຜນທີ່ຂອງພື້ນທີ່ທີ່ມີຢູ່.

ໃນປັດຈຸບັນພວກເຮົາສາມາດໄດ້ຮັບຄວາມຄິດທີ່ດີຂອງວິທີການ copy-on-write snapshots ເຮັດວຽກ - ແຕ່ລະ block ສາມາດເປັນຂອງ snapshots ຫຼາຍ, ແລະຈະຍັງຄົງຢູ່ຈົນກ່ວາທັງຫມົດ snapshots ທີ່ກ່ຽວຂ້ອງຖືກທໍາລາຍ.

ກົນໄກການ Copy on Write (CoW) ແມ່ນພື້ນຖານພື້ນຖານຂອງສິ່ງທີ່ເຮັດໃຫ້ ZFS ເປັນລະບົບທີ່ຫນ້າປະຫລາດໃຈ. ແນວຄວາມຄິດພື້ນຖານແມ່ນງ່າຍດາຍ - ຖ້າທ່ານຂໍໃຫ້ລະບົບໄຟລ໌ແບບດັ້ງເດີມປ່ຽນໄຟລ໌, ມັນຈະເຮັດຕາມທີ່ທ່ານຖາມ. ຖ້າທ່ານຂໍໃຫ້ລະບົບໄຟລ໌ copy-on-write ເຮັດເຊັ່ນດຽວກັນ, ມັນຈະເວົ້າວ່າ "ok" ແຕ່ຕົວະເຈົ້າ.

ແທນທີ່ຈະ, ລະບົບໄຟລ໌ copy-on-write ຂຽນເວີຊັນໃຫມ່ຂອງບລັອກທີ່ຖືກດັດແປງແລະຫຼັງຈາກນັ້ນປັບປຸງ metadata ຂອງໄຟລ໌ເພື່ອຍົກເລີກການເຊື່ອມໂຍງບລັອກເກົ່າແລະເຊື່ອມໂຍງບລັອກໃຫມ່ທີ່ເຈົ້າຫາກໍ່ຂຽນໃສ່ມັນ.

ການຖອດບລັອກເກົ່າແລະການເຊື່ອມໂຍງອັນໃຫມ່ແມ່ນເຮັດໄດ້ໃນການດໍາເນີນງານຫນຶ່ງ, ດັ່ງນັ້ນມັນບໍ່ສາມາດຂັດຂວາງໄດ້ - ຖ້າທ່ານປິດໄຟຫຼັງຈາກນັ້ນ, ທ່ານມີໄຟລ໌ຮຸ່ນໃຫມ່, ແລະຖ້າທ່ານປິດໄຟໄວ, ທ່ານມີເວີຊັນເກົ່າ. . ໃນກໍລະນີໃດກໍ່ຕາມ, ຈະບໍ່ມີຂໍ້ຂັດແຍ່ງໃນລະບົບໄຟລ໌.

Copy-on-write ໃນ ZFS ເກີດຂຶ້ນບໍ່ພຽງແຕ່ໃນລະດັບລະບົບໄຟລ໌, ແຕ່ຍັງຢູ່ໃນລະດັບການຈັດການແຜ່ນ. ນີ້ຫມາຍຄວາມວ່າ ZFS ບໍ່ໄດ້ຮັບຜົນກະທົບຈາກພື້ນທີ່ສີຂາວ (ຂຸມໃນ RAID) - ປະກົດການເມື່ອແຖບມີເວລາທີ່ຈະບັນທຶກບາງສ່ວນເທົ່ານັ້ນກ່ອນທີ່ລະບົບຈະຂັດຂ້ອງ, ມີຄວາມເສຍຫາຍ array ຫຼັງຈາກ reboot. ທີ່ນີ້ເສັ້ນດ່າງຖືກຂຽນເປັນປະລໍາມະນູ, vdev ແມ່ນລໍາດັບສະເຫມີ, ແລະ Bob ແມ່ນລຸງຂອງເຈົ້າ.

ZIL: ບັນທຶກຄວາມຕັ້ງໃຈ ZFS

ລະບົບ ZFS ປະຕິບັດຕໍ່ການຂຽນແບບ synchronous ໃນລັກສະນະພິເສດ - ມັນຊົ່ວຄາວແຕ່ທັນທີເກັບຮັກສາພວກມັນໄວ້ໃນ ZIL ກ່ອນທີ່ຈະຂຽນພວກມັນຢ່າງຖາວອນຕໍ່ມາພ້ອມກັບການຂຽນ asynchronous.

ໂດຍປົກກະຕິ, ຂໍ້ມູນທີ່ຂຽນໃສ່ ZIL ຈະບໍ່ຖືກອ່ານອີກເທື່ອຫນຶ່ງ. ແຕ່ມັນເປັນໄປໄດ້ຫຼັງຈາກລະບົບຂັດຂ້ອງ

SLOG, ຫຼືອຸປະກອນ LOG ທີສອງ, ແມ່ນພຽງແຕ່ພິເສດ - ແລະມັກໄວຫຼາຍ - vdev, ບ່ອນທີ່ ZIL ສາມາດຖືກເກັບໄວ້ແຍກຕ່າງຫາກຈາກການເກັບຮັກສາຕົ້ນຕໍ.

ຫຼັງຈາກເກີດອຸປະຕິເຫດ, ຂໍ້ມູນເປື້ອນທັງໝົດໃນ ZIL ຈະຖືກຫຼິ້ນຄືນ - ໃນກໍລະນີນີ້, ZIL ຢູ່ໃນ SLOG, ສະນັ້ນມັນຈະຖືກຫຼິ້ນຄືນຈາກບ່ອນນັ້ນ.

ມີສອງປະເພດຕົ້ນຕໍຂອງການປະຕິບັດການຂຽນ - synchronous (sync) ແລະ asynchronous (async). ສໍາລັບວຽກງານສ່ວນໃຫຍ່, ສ່ວນໃຫຍ່ຂອງການຂຽນແມ່ນ asynchronous - ລະບົບໄຟລ໌ອະນຸຍາດໃຫ້ພວກເຂົາລວບລວມແລະອອກເປັນ batches, ຫຼຸດຜ່ອນການແຕກແຍກແລະເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ການ​ບັນ​ທຶກ synchronized ເປັນ​ເລື່ອງ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຫມົດ​. ເມື່ອແອັບພລິເຄຊັນຮ້ອງຂໍການຂຽນ synchronous, ມັນບອກລະບົບໄຟລ໌: "ເຈົ້າຈໍາເປັນຕ້ອງເຮັດສິ່ງນີ້ໃຫ້ກັບຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ປ່ຽນແປງ. ດຽວ​ນີ້ຈົນກ່ວານັ້ນ, ບໍ່ມີຫຍັງອີກທີ່ຂ້ອຍສາມາດເຮັດໄດ້." ດັ່ງນັ້ນ, ການຂຽນ synchronous ຄວນມຸ່ງຫມັ້ນຢູ່ໃນແຜ່ນທັນທີ - ແລະຖ້າວ່ານັ້ນເພີ່ມການແບ່ງສ່ວນຫຼືຫຼຸດຜ່ອນການສົ່ງຕໍ່, ຫຼັງຈາກນັ້ນກໍ່ເປັນເຊັ່ນນັ້ນ.

ZFS ຈັດການການຂຽນ synchronous ທີ່ແຕກຕ່າງຈາກລະບົບໄຟລ໌ປົກກະຕິ - ແທນທີ່ຈະໃຫ້ພວກມັນເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນປົກກະຕິ, ZFS ມອບໃຫ້ພວກເຂົາຢູ່ໃນພື້ນທີ່ເກັບຮັກສາພິເສດທີ່ເອີ້ນວ່າ ZFS Intent Log, ຫຼື ZIL. trick ແມ່ນວ່າບັນທຶກເຫຼົ່ານີ້ ຍັງ ຍັງຄົງຢູ່ໃນຄວາມຊົງຈໍາ, ຖືກລວບລວມພ້ອມກັບຄໍາຮ້ອງຂໍການຂຽນແບບ asynchronous ປົກກະຕິ, ຕໍ່ມາຈະຖືກນໍາໄປໃສ່ບ່ອນເກັບມ້ຽນເປັນ TXG ປົກກະຕິຢ່າງສົມບູນ (ກຸ່ມທຸລະກໍາ).

ໃນການດໍາເນີນງານປົກກະຕິ, ZIL ຖືກຂຽນເປັນແລະບໍ່ເຄີຍອ່ານອີກເທື່ອຫນຶ່ງ. ເມື່ອ, ຫຼັງຈາກສອງສາມນາທີ, ບັນທຶກຈາກ ZIL ມຸ່ງຫມັ້ນກັບການເກັບຮັກສາຕົ້ນຕໍໃນ TXGs ທໍາມະດາຈາກ RAM, ພວກມັນຖືກແຍກອອກຈາກ ZIL. ເວລາດຽວທີ່ບາງສິ່ງບາງຢ່າງຖືກອ່ານຈາກ ZIL ແມ່ນເວລາທີ່ສະນຸກເກີຖືກນໍາເຂົ້າ.

ຖ້າ ZFS ລົ້ມເຫລວ - ລະບົບປະຕິບັດການຂັດຂ້ອງຫຼືໄຟໄຫມ້ - ໃນຂະນະທີ່ມີຂໍ້ມູນຢູ່ໃນ ZIL, ຂໍ້ມູນນັ້ນຈະຖືກອ່ານໃນລະຫວ່າງການນໍາເຂົ້າໃນສະນຸກເກີຕໍ່ໄປ (ຕົວຢ່າງ, ເມື່ອ restart ລະບົບສຸກເສີນ). ສິ່ງໃດໃນ ZIL ຈະຖືກອ່ານ, ຈັດກຸ່ມເຂົ້າໄປໃນ TXGs, ມຸ່ງຫມັ້ນທີ່ຈະເກັບຮັກສາຕົ້ນຕໍ, ແລະຫຼັງຈາກນັ້ນແຍກອອກຈາກ ZIL ໃນລະຫວ່າງຂະບວນການນໍາເຂົ້າ.

ຫນຶ່ງໃນຫ້ອງຮຽນຜູ້ຊ່ວຍ vdev ຖືກເອີ້ນວ່າ LOG ຫຼື SLOG, ອຸປະກອນທີສອງຂອງ LOG. ມັນມີຈຸດປະສົງຫນຶ່ງ - ເພື່ອສະຫນອງສະນຸກເກີທີ່ມີແຍກຕ່າງຫາກ, ແລະມັກໄວ, vdev ທົນທານຕໍ່ການຂຽນຫຼາຍເພື່ອເກັບຮັກສາ ZIL, ແທນທີ່ຈະເກັບຮັກສາ ZIL ໃນຮ້ານ vdev ຕົ້ນຕໍ. ZIL ຕົວຂອງມັນເອງປະຕິບັດຕົວດຽວກັນບໍ່ວ່າມັນຖືກເກັບໄວ້ບ່ອນໃດກໍ່ຕາມ, ແຕ່ຖ້າ LOG vdev ມີປະສິດທິພາບການຂຽນສູງຫຼາຍ, ການຂຽນ synchronous ຈະໄວຂຶ້ນ.

ການເພີ່ມ vdev ກັບ LOG ກັບສະນຸກເກີໃຊ້ບໍ່ໄດ້ ສາມາດບໍ່ໄດ້ ປັບປຸງປະສິດທິພາບການຂຽນ asynchronous - ເຖິງແມ່ນວ່າທ່ານຈະບັງຄັບໃຫ້ຂຽນທັງຫມົດ ZIL ກັບ zfs set sync=always, ພວກເຂົາເຈົ້າຍັງຈະເຊື່ອມຕໍ່ກັບການເກັບຮັກສາຕົ້ນຕໍໃນ TXG ໃນທາງດຽວກັນແລະຢູ່ໃນຈັງຫວະດຽວກັນໂດຍບໍ່ມີການບັນທຶກ. ການປັບປຸງການປະຕິບັດໂດຍກົງພຽງແຕ່ແມ່ນ latency ຂອງ synchronous writes (ເນື່ອງຈາກວ່າບັນທຶກໄວຂຶ້ນເຮັດໃຫ້ການດໍາເນີນງານໄວຂຶ້ນ). sync).

ຢ່າງໃດກໍຕາມ, ໃນສະພາບແວດລ້ອມທີ່ຮຽກຮ້ອງໃຫ້ມີການຂຽນ synchronous ຫຼາຍ, vdev LOG ສາມາດເລັ່ງການຂຽນ asynchronous ແລະການອ່ານທີ່ບໍ່ແມ່ນຖານຄວາມຈໍາ. ການໂຫຼດຂໍ້ມູນ ZIL ໄປຫາ vdev LOG ແຍກຕ່າງຫາກຫມາຍຄວາມວ່າການຂັດແຍ້ງຫນ້ອຍລົງສໍາລັບ IOPS ກ່ຽວກັບການເກັບຮັກສາຕົ້ນຕໍ, ເຊິ່ງປັບປຸງປະສິດທິພາບຂອງການອ່ານແລະການຂຽນທັງຫມົດໃນບາງຂອບເຂດ.

ພາບຖ່າຍ

ກົນໄກການຄັດລອກເທິງການຂຽນຍັງເປັນພື້ນຖານທີ່ຈໍາເປັນສໍາລັບການຖ່າຍຮູບປະລໍາມະນູ ZFS ແລະການຈໍາລອງແບບ asynchronous ເພີ່ມຂຶ້ນ. ລະບົບໄຟລ໌ທີ່ໃຊ້ວຽກມີຕົ້ນຊີ້ບອກບັນທຶກທັງໝົດທີ່ມີຂໍ້ມູນປະຈຸບັນ - ເມື່ອທ່ານຖ່າຍຮູບ, ທ່ານພຽງແຕ່ເຮັດສໍາເນົາຂອງຕົ້ນໄມ້ຕົວຊີ້ນີ້.

ເມື່ອບັນທຶກຖືກຂຽນທັບໃນລະບົບໄຟລ໌ທີ່ໃຊ້ວຽກ, ZFS ທໍາອິດຂຽນສະບັບບລັອກໃຫມ່ໃຫ້ກັບພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້. ຫຼັງຈາກນັ້ນ, ມັນແຍກຕົວບລັອກເວີຊັນເກົ່າອອກຈາກລະບົບໄຟລ໌ໃນປະຈຸບັນ. ແຕ່ຖ້າຫາກວ່າບາງ snapshot ຫມາຍເຖິງບລັອກເກົ່າ, ມັນຍັງຄົງບໍ່ປ່ຽນແປງ. ບລັອກເກົ່າຈະບໍ່ຖືກຟື້ນຟູເປັນພື້ນທີ່ຫວ່າງໄດ້ ຈົນກວ່າທຸກພາບທີ່ອ້າງອີງເຖິງບລັອກນີ້ຈະຖືກທຳລາຍ!

ການຈຳລອງ

ຫ້ອງສະຫມຸດ Steam ຂອງຂ້ອຍໃນປີ 2015 ແມ່ນ 158 GiB ແລະລວມເຖິງ 126 ໄຟລ໌. ນີ້ແມ່ນຂ້ອນຂ້າງໃກ້ກັບສະຖານະການທີ່ດີທີ່ສຸດສໍາລັບ rsync - ZFS replication ໃນໄລຍະເຄືອຂ່າຍແມ່ນ "ພຽງແຕ່" 927% ໄວ.

ໃນເຄືອຂ່າຍດຽວກັນ, ການສຳເນົາໄຟລ໌ຮູບພາບເຄື່ອງ virtual ຂະໜາດ 40 ກິກະໄບທ໌ດຽວ Windows 7 ເປັນເລື່ອງທີ່ແຕກຕ່າງກັນໝົດ. ການສຳເນົາ ZFS ໄວກວ່າ rsync 289 ເທົ່າ—ຫຼື ໄວກວ່າ "ພຽງແຕ່" 161 ເທົ່າ ຖ້າທ່ານມີຄວາມສະຫຼາດພຽງພໍທີ່ຈະໂທຫາ rsync ດ້ວຍສະວິດ --inplace.

ເມື່ອຮູບພາບ VM ຖືກປັບຂະຫນາດ, rsync ບັນຫາຂະຫນາດກັບມັນ. 1,9 TiB ແມ່ນບໍ່ໃຫຍ່ປານໃດສໍາລັບຮູບພາບ VM ທີ່ທັນສະໄຫມ - ແຕ່ມັນໃຫຍ່ພໍທີ່ ZFS replication ແມ່ນໄວກວ່າ rsync 1148 ເທົ່າ, ເຖິງແມ່ນວ່າມີການໂຕ້ຖຽງ -inplace ຂອງ rsync.

ເມື່ອທ່ານເຂົ້າໃຈວິທີການເຮັດວຽກຂອງ snapshots, ມັນຄວນຈະງ່າຍທີ່ຈະເຂົ້າໃຈຄວາມສໍາຄັນຂອງການຈໍາລອງ. ເນື່ອງຈາກພາບຖ່າຍເປັນພຽງຕົ້ນໄມ້ຂອງຕົວຊີ້ໄປຫາບັນທຶກ, ມັນປະຕິບັດຕາມນັ້ນຖ້າພວກເຮົາເຮັດ zfs send ພາບຖ່າຍ, ຈາກນັ້ນພວກເຮົາສົ່ງທັງຕົ້ນໄມ້ນີ້ ແລະບັນທຶກທັງໝົດທີ່ກ່ຽວຂ້ອງກັບມັນ. ໃນເວລາທີ່ພວກເຮົາສົ່ງນີ້ zfs send в zfs receive ໃນເປົ້າຫມາຍ, ມັນຂຽນທັງເນື້ອໃນຕົວຈິງຂອງຕັນແລະຕົ້ນໄມ້ຂອງຕົວຊີ້ທີ່ອ້າງອີງເຖິງຕັນໄປຫາຊຸດຂໍ້ມູນເປົ້າຫມາຍ.

ສິ່ງທີ່ໜ້າສົນໃຈຫຼາຍຂຶ້ນໃນຄັ້ງທີສອງ zfs send. ໃນປັດຈຸບັນພວກເຮົາມີສອງລະບົບ, ແຕ່ລະປະກອບດ້ວຍ poolname/datasetname@1, ແລະທ່ານຖ່າຍຮູບໃຫມ່ poolname/datasetname@2. ເພາະສະນັ້ນ, ໃນສະນຸກເກີຕົ້ນສະບັບທ່ານມີ datasetname@1 и datasetname@2, ແລະໃນສະນຸກເກີເປົ້າຫມາຍມາເຖິງຕອນນັ້ນພຽງແຕ່ພາບຖ່າຍທໍາອິດ datasetname@1.

ເນື່ອງຈາກພວກເຮົາມີຮູບພາບທົ່ວໄປລະຫວ່າງແຫຼ່ງແລະເປົ້າຫມາຍ datasetname@1, ພວກເຮົາສາມາດເຮັດໄດ້ ເພີ່ມຂຶ້ນ zfs send ຫຼາຍກວ່າມັນ. ເມື່ອພວກເຮົາເວົ້າກັບລະບົບ zfs send -i poolname/datasetname@1 poolname/datasetname@2, ມັນປຽບທຽບສອງຕົ້ນໄມ້ pointer. ຕົວຊີ້ໃດໆທີ່ມີພຽງແຕ່ຢູ່ໃນ @2, ແນ່ນອນຫມາຍເຖິງຕັນໃຫມ່ - ດັ່ງນັ້ນພວກເຮົາຕ້ອງການເນື້ອໃນຂອງຕັນເຫຼົ່ານີ້.

ໃນລະບົບຫ່າງໄກສອກຫຼີກ, ດໍາເນີນການເພີ່ມຂຶ້ນ send ພຽງແຕ່ເປັນງ່າຍດາຍ. ທໍາອິດພວກເຮົາຂຽນລາຍການໃຫມ່ທັງຫມົດລວມຢູ່ໃນນ້ໍາ send, ແລະຫຼັງຈາກນັ້ນເພີ່ມຕົວຊີ້ໃສ່ບລັອກເຫຼົ່ານັ້ນ. Voila, ພວກເຮົາມີ @2 ໃນ​ລະ​ບົບ​ໃຫມ່​!

ZFS asynchronous incremental replication ແມ່ນການປັບປຸງອັນໃຫຍ່ຫຼວງຕໍ່ກັບວິທີການທີ່ບໍ່ແມ່ນພາບຖ່າຍກ່ອນຫນ້າເຊັ່ນ rsync. ໃນທັງສອງກໍລະນີ, ພຽງແຕ່ມີການປ່ຽນແປງຂໍ້ມູນຖືກໂອນ - ແຕ່ rsync ຕ້ອງທໍາອິດ ອ່ານ ຈາກແຜ່ນຂໍ້ມູນທັງຫມົດທັງສອງດ້ານເພື່ອກວດເບິ່ງຜົນລວມແລະປຽບທຽບມັນ. ໃນທາງກົງກັນຂ້າມ, ການຈໍາລອງ ZFS ອ່ານບໍ່ມີຫຍັງນອກ ເໜືອ ຈາກຕົ້ນໄມ້ຕົວຊີ້ - ແລະທ່ອນໄມ້ໃດໆທີ່ບໍ່ມີຢູ່ໃນຮູບພາບທີ່ແບ່ງປັນ.

ການບີບອັດໃນຕົວ

ກົນໄກການສຳເນົາ-on-write ຍັງເຮັດໃຫ້ລະບົບການບີບອັດໃນແຖວງ່າຍຂຶ້ນ. ໃນລະບົບໄຟລ໌ແບບດັ້ງເດີມ, ການບີບອັດແມ່ນມີບັນຫາ - ທັງສະບັບເກົ່າແລະສະບັບໃຫມ່ຂອງຂໍ້ມູນທີ່ດັດແກ້ຢູ່ໃນພື້ນທີ່ດຽວກັນ.

ຖ້າພວກເຮົາພິຈາລະນາຊິ້ນສ່ວນຂອງຂໍ້ມູນຢູ່ໃນກາງຂອງໄຟລ໌ທີ່ເລີ່ມຕົ້ນຊີວິດເປັນ megabyte ຂອງສູນຈາກ 0x00000000 ແລະອື່ນໆ, ມັນເປັນເລື່ອງງ່າຍຫຼາຍທີ່ຈະບີບອັດມັນໄປຫາພາກສ່ວນຫນຶ່ງໃນແຜ່ນ. ແຕ່ຈະເກີດຫຍັງຂຶ້ນຖ້າພວກເຮົາແທນທີ່ megabyte ຂອງສູນນັ້ນດ້ວຍ megabyte ຂອງຂໍ້ມູນ incompressible ເຊັ່ນ JPEG ຫຼື pseudo-random noise? ໂດຍບໍ່ຄາດຄິດ, ຂໍ້ມູນ megabyte ນີ້ຈະບໍ່ຕ້ອງການຫນຶ່ງ, ແຕ່ 256 4 KiB ຂະແຫນງການ, ແລະໃນສະຖານທີ່ນີ້ຢູ່ໃນແຜ່ນພຽງແຕ່ຫນຶ່ງຂະແຫນງການຖືກສະຫງວນ.

ZFS ບໍ່ມີບັນຫານີ້, ຍ້ອນວ່າບັນທຶກທີ່ຖືກດັດແກ້ຖືກຂຽນຢູ່ສະເຫມີກັບພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້ - ຕັນຕົ້ນສະບັບພຽງແຕ່ຄອບຄອງຫນຶ່ງ 4 KiB, ແລະບັນທຶກໃຫມ່ຈະຄອບຄອງ 256, ແຕ່ນີ້ບໍ່ແມ່ນບັນຫາ - ຊິ້ນສ່ວນທີ່ຖືກດັດແປງບໍ່ດົນມານີ້ຈາກ " ກາງ" ຂອງໄຟລ໌ຈະຖືກຂຽນໃສ່ພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້ໂດຍບໍ່ຄໍານຶງວ່າຂະຫນາດຂອງມັນມີການປ່ຽນແປງຫຼືບໍ່, ດັ່ງນັ້ນສໍາລັບ ZFS ນີ້ແມ່ນສະຖານະການປົກກະຕິ.

ການບີບອັດ ZFS ເດີມຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ, ແລະລະບົບຈະໃຫ້ລະບົບ pluggable algorithms—ປະຈຸບັນແມ່ນ LZ4, gzip (1-9), LZJB, ແລະ ZLE.

• LZ4 ແມ່ນລະບົບການຖ່າຍທອດທີ່ໃຫ້ການບີບອັດແລະການບີບອັດໄວທີ່ສຸດ ແລະຜົນປະໂຫຍດປະສິດທິພາບສໍາລັບກໍລະນີການນໍາໃຊ້ສ່ວນໃຫຍ່ - ເຖິງແມ່ນວ່າຢູ່ໃນ CPU ທີ່ຊ້າພໍສົມຄວນ.
• GZIP ເປັນສູດການຄິດໄລ່ທີ່ເຄົາລົບທີ່ຜູ້ໃຊ້ Unix ທຸກຄົນຮູ້ ແລະມັກ. ມັນສາມາດປະຕິບັດໄດ້ດ້ວຍລະດັບການບີບອັດ 1-9, ໂດຍອັດຕາສ່ວນການບີບອັດແລະການນໍາໃຊ້ CPU ເພີ່ມຂຶ້ນເມື່ອມັນເຂົ້າໃກ້ລະດັບ 9. ສູດການຄິດໄລ່ແມ່ນເຫມາະສົມກັບທຸກຂໍ້ຄວາມ (ຫຼືອື່ນໆທີ່ມີການບີບອັດສູງ), ແຕ່ຖ້າບໍ່ດັ່ງນັ້ນມັກຈະເຮັດໃຫ້ເກີດບັນຫາ CPU - ໃຊ້ມັນ. ດ້ວຍຄວາມລະມັດລະວັງ, ໂດຍສະເພາະໃນລະດັບທີ່ສູງຂຶ້ນ.
• LZJB ແມ່ນສູດການຄິດໄລ່ຕົ້ນສະບັບໃນ ZFS. ມັນລ້າສະໄຫມແລະບໍ່ຄວນໃຊ້ອີກຕໍ່ໄປ, LZ4 ລື່ນກາຍມັນໃນທຸກທາງ.
• ZLE - ການເຂົ້າລະຫັດລະດັບສູນ, ການເຂົ້າລະຫັດລະດັບສູນ. ມັນບໍ່ສໍາຜັດກັບຂໍ້ມູນປົກກະຕິທັງຫມົດ, ແຕ່ບີບອັດລໍາດັບຂະຫນາດໃຫຍ່ຂອງສູນ. ເປັນປະໂຫຍດສໍາລັບຊຸດຂໍ້ມູນທີ່ບໍ່ສາມາດບີບອັດໄດ້ຢ່າງສົມບູນ (ເຊັ່ນ: JPEG, MP4, ຫຼືຮູບແບບອື່ນໆທີ່ຖືກບີບອັດແລ້ວ) ຍ້ອນວ່າມັນບໍ່ສົນໃຈຂໍ້ມູນທີ່ບໍ່ສາມາດບີບອັດໄດ້ແຕ່ຈະບີບອັດພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້ໃນບັນທຶກຜົນໄດ້ຮັບ.

ພວກເຮົາແນະນໍາໃຫ້ບີບອັດ LZ4 ສໍາລັບເກືອບທຸກກໍລະນີການນໍາໃຊ້; ການລົງໂທດການປະຕິບັດໃນເວລາທີ່ພົບຂໍ້ມູນ incompressible ແມ່ນຂະຫນາດນ້ອຍຫຼາຍ, ແລະ ການຂະຫຍາຍຕົວ ຜົນກະທົບຕໍ່ປະສິດທິພາບສຳລັບຂໍ້ມູນທົ່ວໄປແມ່ນມີຄວາມສຳຄັນຫຼາຍ. ການຄັດລອກຮູບພາບເຄື່ອງ virtual ສຳລັບການຕິດຕັ້ງລະບົບປະຕິບັດການໃໝ່ Windows (ລະບົບປະຕິບັດການທີ່ຕິດຕັ້ງໃໝ່, ຍັງບໍ່ມີຂໍ້ມູນພາຍໃນເທື່ອ) compression=lz4 ຜ່ານ 27% ໄວກວ່າກັບ compression=none, ໃນ ການ​ທົດ​ສອບ​ໃນ​ປີ 2015​.

ARC - cache ການທົດແທນການປັບຕົວ

ZFS ເປັນລະບົບໄຟລ໌ທີ່ທັນສະໄຫມດຽວທີ່ພວກເຮົາຮູ້ວ່າໃຊ້ກົນໄກການອ່ານຖານຄວາມຈໍາຂອງຕົນເອງ, ແທນທີ່ຈະອີງໃສ່ cache ຫນ້າຂອງລະບົບປະຕິບັດການເພື່ອເກັບສໍາເນົາຂອງບລັອກທີ່ອ່ານບໍ່ດົນມານີ້ຢູ່ໃນ RAM.

ເຖິງແມ່ນວ່າ cache ພື້ນເມືອງບໍ່ແມ່ນບໍ່ມີບັນຫາຂອງມັນ - ZFS ບໍ່ສາມາດຕອບສະຫນອງຄໍາຮ້ອງຂໍການຈັດສັນຫນ່ວຍຄວາມຈໍາໃຫມ່ໄດ້ໄວເທົ່າທີ່ kernel, ດັ່ງນັ້ນສິ່ງທ້າທາຍໃຫມ່. malloc() ກ່ຽວກັບການຈັດສັນຫນ່ວຍຄວາມຈໍາອາດຈະລົ້ມເຫລວຖ້າມັນຕ້ອງການ RAM ທີ່ປະຈຸບັນຄອບຄອງໂດຍ ARC. ແຕ່ມີເຫດຜົນທີ່ດີທີ່ຈະໃຊ້ cache ຂອງທ່ານເອງ, ຢ່າງຫນ້ອຍສໍາລັບຕອນນີ້.

ລະບົບປະຕິບັດການທີ່ທັນສະໄໝທັງໝົດທີ່ຮູ້ຈັກກັນດີ, ລວມທັງ MacOS, Windows, Linux ແລະ BSD ໃຊ້ອັລກໍຣິທຶມ LRU (Least Recently Used) ເພື່ອຈັດຕັ້ງປະຕິບັດແຄຊໜ້າ. ນີ້ແມ່ນອັລກໍຣິທຶມເບື້ອງຕົ້ນທີ່ຍ້າຍບລັອກທີ່ຖືກແຄຊ "ໄປທາງເທິງຂອງຄິວ" ຫຼັງຈາກອ່ານແຕ່ລະຄັ້ງ ແລະ ຂັບໄລ່ບລັອກ "ໄປທາງລຸ່ມຂອງຄິວ" ຕາມຄວາມຕ້ອງການເພື່ອເພີ່ມການພາດແຄຊໃໝ່ (ບລັອກທີ່ຄວນຈະຖືກອ່ານຈາກແຜ່ນແທນທີ່ຈະຈາກແຄຊ) ໄປທາງເທິງ.

algorithm ປົກກະຕິແລ້ວເຮັດວຽກໄດ້ດີ, ແຕ່ໃນລະບົບທີ່ມີຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່, LRU ໄດ້ຢ່າງງ່າຍດາຍນໍາໄປສູ່ການ thrashing - ຂັບໄລ່ຕັນທີ່ຈໍາເປັນເລື້ອຍໆເພື່ອສ້າງພື້ນທີ່ສໍາລັບຕັນທີ່ບໍ່ເຄີຍຖືກອ່ານຈາກ cache ອີກເທື່ອຫນຶ່ງ.

ARC ເປັນ algorithm naive ຫຼາຍຫນ້ອຍທີ່ສາມາດຄິດວ່າເປັນ cache "ນ້ໍາຫນັກ". ແຕ່ລະຄັ້ງທີ່ມີການອ່ານບລັອກທີ່ຖືກເກັບໄວ້, ມັນ "ໜັກ" ເລັກນ້ອຍແລະຍາກທີ່ຈະຂັບໄລ່ - ແລະເຖິງແມ່ນວ່າຫຼັງຈາກການຂັບໄລ່ບລັອກ. ຕິດຕາມ ພາຍໃນໄລຍະເວລາທີ່ແນ່ນອນ. ບລັອກທີ່ຖືກຂັບໄລ່ແຕ່ຫຼັງຈາກນັ້ນຕ້ອງໄດ້ຮັບການອ່ານຄືນເຂົ້າໄປໃນ cache ຍັງຈະກາຍເປັນ "ຫນັກກວ່າ".

ຜົນໄດ້ຮັບສຸດທ້າຍຂອງທັງຫມົດນີ້ແມ່ນ cache ທີ່ມີອັດຕາສ່ວນ hits ສູງກວ່າຫຼາຍ, ອັດຕາສ່ວນລະຫວ່າງ cache hits (ອ່ານຈາກ cache) ແລະ cache misses (ອ່ານຈາກ disk). ນີ້ແມ່ນສະຖິຕິທີ່ສໍາຄັນທີ່ສຸດ - ບໍ່ພຽງແຕ່ cache hits ຕົນເອງໄດ້ຮັບຄໍາສັ່ງຂອງຂະຫນາດໄວ, cache misses ຍັງສາມາດໃຫ້ບໍລິການໄວຂຶ້ນ, ເນື່ອງຈາກວ່າ cache hits ຫຼາຍ, ການຮ້ອງຂໍ disk concurrent ຫນ້ອຍແລະ latency ຕ່ໍາສໍາລັບການ misses ທີ່ຍັງເຫຼືອທີ່ຕ້ອງ. ໃຫ້ບໍລິການດ້ວຍແຜ່ນ.

ສະຫລຸບ

ຫຼັງຈາກການຮຽນຮູ້ຄວາມຫມາຍພື້ນຖານຂອງ ZFS - ວິທີການ copy-on-write ເຮັດວຽກ, ເຊັ່ນດຽວກັນກັບຄວາມສໍາພັນລະຫວ່າງສະນຸກເກີການເກັບຮັກສາ, ອຸປະກອນ virtual, ຕັນ, ຂະແຫນງການ, ແລະໄຟລ໌ - ພວກເຮົາພ້ອມທີ່ຈະປຶກສາຫາລືການປະຕິບັດຕົວຈິງກັບຕົວເລກທີ່ແທ້ຈິງ.

ໃນພາກຕໍ່ໄປ, ພວກເຮົາຈະພິຈາລະນາເບິ່ງປະສິດທິພາບຕົວຈິງຂອງ pools ທີ່ມີ mirrored vdevs ແລະ RAIDz, ເມື່ອທຽບກັບກັນແລະກັນ, ເຊັ່ນດຽວກັນກັບການປຽບທຽບກັບ topologies kernel RAID ແບບດັ້ງເດີມ. Linuxທີ່ພວກເຮົາຄົ້ນຄວ້າ ກ່ອນຫນ້ານີ້.

ໃນຕອນທໍາອິດ, ພວກເຮົາຕ້ອງການທີ່ຈະກວມເອົາພຽງແຕ່ພື້ນຖານ - the ZFS topologies ດ້ວຍຕົນເອງ - ແຕ່ຫຼັງຈາກນັ້ນ ດັ່ງກ່າວ ໃຫ້ພວກເຮົາກຽມພ້ອມທີ່ຈະເວົ້າກ່ຽວກັບການຕິດຕັ້ງແລະການປັບແຕ່ງແບບພິເສດຂອງ ZFS, ລວມທັງການນໍາໃຊ້ປະເພດ vdev auxiliary ເຊັ່ນ L2ARC, SLOG ແລະການຈັດສັນພິເສດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com