ການເກັບຮັກສາຂໍ້ມູນທົນທານແລະ APIs ໄຟລ໌ Linux

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

ໃນບົດຂຽນນີ້, ຂ້ອຍຄົ້ນຫາກົນໄກການເກັບຮັກສາທີ່ຄົງທີ່ທີ່ສະຫນອງໃຫ້ໂດຍ API ໄຟລ໌ Linux. ມັນເບິ່ງຄືວ່າທຸກສິ່ງທຸກຢ່າງຄວນຈະງ່າຍດາຍຢູ່ທີ່ນີ້: ໂປຼແກຼມເອີ້ນຄໍາສັ່ງ write(), ແລະຫຼັງຈາກຄໍາສັ່ງນີ້ສໍາເລັດ, ຂໍ້ມູນຈະຖືກບັນທຶກໄວ້ຢ່າງປອດໄພໃສ່ແຜ່ນ. ແຕ່ write() ພຽງແຕ່ຄັດລອກຂໍ້ມູນແອັບພລິເຄຊັນໄປຫາ kernel cache ທີ່ຕັ້ງຢູ່ໃນ RAM. ເພື່ອບັງຄັບໃຫ້ລະບົບຂຽນຂໍ້ມູນໃສ່ແຜ່ນ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ບາງກົນໄກເພີ່ມເຕີມ.

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

ຄຸນສົມບັດຂອງການໃຊ້ຟັງຊັນ write().

ໂທລະບົບ write() ກໍານົດຢູ່ໃນມາດຕະຖານ IEEE POSIX ເປັນຄວາມພະຍາຍາມຂຽນຂໍ້ມູນໃສ່ຕົວອະທິບາຍໄຟລ໌. ຫຼັງ​ຈາກ​ສໍາ​ເລັດ​ສົບ​ຜົນ​ສໍາ​ເລັດ​ write() ການປະຕິບັດການອ່ານຂໍ້ມູນຕ້ອງກັບຄືນຢ່າງແທ້ຈິງ bytes ທີ່ຖືກຂຽນໄວ້ກ່ອນຫນ້ານີ້, ດໍາເນີນການນີ້ເຖິງແມ່ນວ່າຂໍ້ມູນຖືກເຂົ້າເຖິງຈາກຂະບວນການຫຼືຫົວຂໍ້ອື່ນໆ (ຈົ່ງເບິ່ງ, ພາກສ່ວນທີ່ກ່ຽວຂ້ອງຂອງມາດຕະຖານ POSIX). ມັນເປັນ, ໃນພາກກ່ຽວກັບວິທີກະທູ້ພົວພັນກັບການດໍາເນີນການໄຟລ໌ປົກກະຕິ, ມີບັນທຶກທີ່ບອກວ່າຖ້າສອງ threads ແຕ່ລະໂທຫາຫນ້າທີ່ເຫຼົ່ານີ້, ແຕ່ລະການໂທຈະຕ້ອງເບິ່ງຜົນສະທ້ອນທີ່ກໍານົດຂອງການໂທອື່ນ, ຫຼືບໍ່ມີເລີຍ. ຜົນສະທ້ອນ. ນີ້ນໍາໄປສູ່ການສະຫລຸບວ່າການດໍາເນີນງານ I/O ໄຟລ໌ທັງຫມົດຕ້ອງລັອກຊັບພະຍາກອນທີ່ພວກເຂົາກໍາລັງປະຕິບັດ.

ນີ້ຫມາຍຄວາມວ່າການດໍາເນີນງານ write() ມັນແມ່ນປະລໍາມະນູ? ຈາກທັດສະນະດ້ານວິຊາການ, ແມ່ນແລ້ວ. ການປະຕິບັດການອ່ານຂໍ້ມູນຕ້ອງສົ່ງຄືນທັງ ໝົດ ຫຼືບໍ່ມີຫຍັງຂອງສິ່ງທີ່ຂຽນດ້ວຍ write(). ແຕ່ການດໍາເນີນງານ write(), ຕາມມາດຕະຖານ, ບໍ່ຈໍາເປັນຕ້ອງສິ້ນສຸດດ້ວຍການຂຽນລົງທຸກສິ່ງທີ່ຖືກຂໍໃຫ້ຂຽນລົງ. ນາງໄດ້ຖືກອະນຸຍາດໃຫ້ຂຽນພຽງແຕ່ສ່ວນຫນຶ່ງຂອງຂໍ້ມູນ. ຕົວຢ່າງ, ພວກເຮົາອາດຈະມີສອງກະທູ້ແຕ່ລະອັນຕໍ່ທ້າຍ 1024 bytes ກັບໄຟລ໌ທີ່ອະທິບາຍໂດຍຕົວອະທິບາຍໄຟລ໌ດຽວກັນ. ຈາກມຸມເບິ່ງຂອງມາດຕະຖານ, ຜົນໄດ້ຮັບທີ່ຍອມຮັບໄດ້ແມ່ນເວລາທີ່ແຕ່ລະການດໍາເນີນງານການຂຽນສາມາດເພີ່ມພຽງແຕ່ຫນຶ່ງ byte ກັບໄຟລ໌. ການປະຕິບັດງານເຫຼົ່ານີ້ຈະຍັງຄົງເປັນປະລໍາມະນູ, ແຕ່ຫຼັງຈາກທີ່ພວກເຂົາສໍາເລັດ, ຂໍ້ມູນທີ່ເຂົາເຈົ້າຂຽນໃສ່ໄຟລ໌ຈະຖືກປະສົມ. ທີ່ນີ້ ການສົນທະນາທີ່ຫນ້າສົນໃຈຫຼາຍກ່ຽວກັບຫົວຂໍ້ນີ້ກ່ຽວກັບ Stack Overflow.

fsync() ແລະ fdatasync() ຟັງຊັນ

ວິ​ທີ​ທີ່​ງ່າຍ​ທີ່​ສຸດ​ເພື່ອ flush ຂໍ້​ມູນ​ກັບ​ແຜ່ນ​ແມ່ນ​ການ​ໂທ​ຫາ​ຫນ້າ​ທີ່​ fsync(). ຟັງຊັນນີ້ຂໍໃຫ້ລະບົບປະຕິບັດການໂອນບລັອກທີ່ຖືກດັດແປງທັງຫມົດຈາກແຄດໄປຫາແຜ່ນ. ນີ້ປະກອບມີ metadata ໄຟລ໌ທັງຫມົດ (ເວລາເຂົ້າເຖິງ, ເວລາດັດແກ້ໄຟລ໌, ແລະອື່ນໆ). ຂ້າພະເຈົ້າເຊື່ອວ່າ metadata ນີ້ບໍ່ຄ່ອຍຈໍາເປັນ, ດັ່ງນັ້ນຖ້າທ່ານຮູ້ວ່າມັນບໍ່ສໍາຄັນສໍາລັບທ່ານ, ທ່ານສາມາດນໍາໃຊ້ຫນ້າທີ່ fdatasync(). ການ ຊ່ວຍເຫຼືອ on the fdatasync() ມັນໄດ້ຖືກກ່າວວ່າໃນລະຫວ່າງການປະຕິບັດຫນ້ານີ້, ຈໍານວນ metadata ດັ່ງກ່າວຖືກບັນທຶກໄວ້ໃນແຜ່ນທີ່ "ຈໍາເປັນສໍາລັບການປະຕິບັດທີ່ຖືກຕ້ອງຂອງການປະຕິບັດການອ່ານຂໍ້ມູນຕໍ່ໄປນີ້." ແລະນີ້ແມ່ນສິ່ງທີ່ແອັບພລິເຄຊັນສ່ວນໃຫຍ່ສົນໃຈ.

ບັນຫາຫນຶ່ງທີ່ສາມາດເກີດຂື້ນຢູ່ທີ່ນີ້ແມ່ນວ່າກົນໄກເຫຼົ່ານີ້ບໍ່ໄດ້ຮັບປະກັນວ່າໄຟລ໌ຈະຖືກຄົ້ນພົບຫຼັງຈາກຄວາມລົ້ມເຫຼວທີ່ເປັນໄປໄດ້. ໂດຍສະເພາະ, ເມື່ອສ້າງໄຟລ໌ໃຫມ່, ທ່ານຈໍາເປັນຕ້ອງໂທຫາ fsync() ສໍາລັບໄດເລກະທໍລີທີ່ປະກອບດ້ວຍມັນ. ຖ້າ​ບໍ່​ດັ່ງ​ນັ້ນ​, ຫຼັງ​ຈາກ​ຄວາມ​ລົ້ມ​ເຫຼວ​, ມັນ​ອາດ​ຈະ​ກາຍ​ເປັນ​ໄຟລ​໌​ນີ້​ບໍ່​ມີ​. ເຫດຜົນສໍາລັບການນີ້ແມ່ນຢູ່ໃນ UNIX, ເນື່ອງຈາກການນໍາໃຊ້ການເຊື່ອມຕໍ່ຍາກ, ໄຟລ໌ສາມາດມີຢູ່ໃນຫຼາຍໄດເລກະທໍລີ. ເພາະສະນັ້ນ, ໃນເວລາທີ່ໂທຫາ fsync() ບໍ່ມີທາງທີ່ໄຟລ໌ທີ່ຈະຮູ້ວ່າຂໍ້ມູນໄດເລກະທໍລີໃດຄວນຈະຖືກ flushed ໄປໃສ່ແຜ່ນ (ທີ່ນີ້ ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້). ເບິ່ງຄືວ່າລະບົບໄຟລ໌ ext4 ມີຄວາມສາມາດ ອັດຕະໂນມັດ ການນໍາໃຊ້ fsync() ໄປຫາໄດເລກະທໍລີທີ່ມີໄຟລ໌ທີ່ສອດຄ້ອງກັນ, ແຕ່ນີ້ອາດຈະບໍ່ເປັນກໍລະນີກັບລະບົບໄຟລ໌ອື່ນໆ.

ກົນໄກນີ້ອາດຈະຖືກປະຕິບັດແຕກຕ່າງກັນໃນລະບົບໄຟລ໌ທີ່ແຕກຕ່າງກັນ. ຂ້ອຍ​ໃຊ້ blktrace ເພື່ອຮຽນຮູ້ກ່ຽວກັບການດໍາເນີນງານຂອງແຜ່ນໃດທີ່ໃຊ້ໃນລະບົບໄຟລ໌ ext4 ແລະ XFS. ທັງສອງອອກຄໍາສັ່ງຂຽນປົກກະຕິໃສ່ແຜ່ນສໍາລັບທັງເນື້ອໃນຂອງໄຟລ໌ແລະວາລະສານລະບົບໄຟລ໌, flush cache, ແລະອອກໂດຍການປະຕິບັດ FUA (Force Unit Access, ຂຽນຂໍ້ມູນໂດຍກົງໃສ່ແຜ່ນ, bypassing the cache) ຂຽນໃສ່ວາລະສານ. ພວກເຂົາເຈົ້າອາດຈະເຮັດແນວນີ້ເພື່ອຢືນຢັນວ່າການເຮັດທຸລະກໍາໄດ້ເກີດຂຶ້ນ. ໃນໄດຣຟ໌ທີ່ບໍ່ຮອງຮັບ FUA, ອັນນີ້ເຮັດໃຫ້ເກີດການລ້າງແຄດສອງອັນ. ການທົດລອງຂອງຂ້ອຍໄດ້ສະແດງໃຫ້ເຫັນວ່າ fdatasync() ໄວຂຶ້ນເລັກນ້ອຍ fsync(). ປະໂຫຍດ blktrace ຊີ້​ໃຫ້​ເຫັນ​ວ່າ​ fdatasync() ໂດຍປົກກະຕິຈະຂຽນຂໍ້ມູນໜ້ອຍລົງໃສ່ແຜ່ນ (ໃນ ext4 fsync() ຂຽນ 20 KiB, ແລະ fdatasync() - 16 ກິບ). ນອກຈາກນີ້, ຂ້າພະເຈົ້າໄດ້ພົບເຫັນວ່າ XFS ແມ່ນໄວກວ່າ ext4 ເລັກນ້ອຍ. ແລະໃນທີ່ນີ້ດ້ວຍການຊ່ວຍເຫຼືອ blktrace ການຄຸ້ມຄອງເພື່ອຊອກຫາວ່າ fdatasync() ລ້າງຂໍ້ມູນໜ້ອຍລົງໃສ່ແຜ່ນ (4 KiB ໃນ XFS).

ສະຖານະການທີ່ບໍ່ຊັດເຈນທີ່ເກີດຂື້ນໃນເວລາທີ່ໃຊ້ fsync()

ຂ້ອຍສາມາດຄິດເຖິງສາມສະຖານະການທີ່ບໍ່ຊັດເຈນກ່ຽວກັບ fsync()ທີ່ຂ້າພະເຈົ້າໄດ້ພົບໃນການປະຕິບັດ.

ກໍ​ລະ​ນີ​ທໍາ​ອິດ​ທີ່​ເກີດ​ຂຶ້ນ​ໃນ​ປີ 2008​. ຫຼັງຈາກນັ້ນ, ການໂຕ້ຕອບ Firefox 3 froze ຖ້າໄຟລ໌ຈໍານວນຫລາຍຖືກຂຽນໃສ່ແຜ່ນ. ບັນຫາແມ່ນວ່າການປະຕິບັດການໂຕ້ຕອບໄດ້ນໍາໃຊ້ຖານຂໍ້ມູນ SQLite ເພື່ອເກັບຂໍ້ມູນກ່ຽວກັບລັດຂອງມັນ. ຫຼັງຈາກການປ່ຽນແປງທີ່ເກີດຂື້ນໃນການໂຕ້ຕອບແຕ່ລະຄົນ, ຫນ້າທີ່ຖືກເອີ້ນວ່າ fsync(), ເຊິ່ງໃຫ້ການຄໍ້າປະກັນທີ່ດີຂອງການເກັບຮັກສາຂໍ້ມູນທີ່ຫມັ້ນຄົງ. ໃນລະບົບໄຟລ໌ ext3 ຫຼັງຈາກນັ້ນຖືກນໍາໃຊ້, ຫນ້າທີ່ fsync() ຖິ້ມຫນ້າ "ເປື້ອນ" ທັງຫມົດໃນລະບົບໃສ່ແຜ່ນ, ແລະບໍ່ພຽງແຕ່ຫນ້າທີ່ກ່ຽວຂ້ອງກັບໄຟລ໌ທີ່ສອດຄ້ອງກັນ. ນີ້ຫມາຍຄວາມວ່າການຄລິກໃສ່ປຸ່ມໃນ Firefox ສາມາດກະຕຸ້ນໃຫ້ຂໍ້ມູນ megabytes ຖືກຂຽນໃສ່ແຜ່ນແມ່ເຫຼັກ, ເຊິ່ງອາດຈະໃຊ້ເວລາຫຼາຍວິນາທີ. ການແກ້ໄຂບັນຫາ, ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈຈາກ ມັນ ວັດສະດຸແມ່ນການໂອນວຽກກັບຖານຂໍ້ມູນໄປຫາວຽກພື້ນຖານທີ່ບໍ່ກົງກັນ. ນີ້ຫມາຍຄວາມວ່າ Firefox ກ່ອນຫນ້ານີ້ໄດ້ປະຕິບັດຂໍ້ກໍານົດການເກັບຮັກສາທີ່ເຂັ້ມງວດກວ່າຄວາມຕ້ອງການຢ່າງແທ້ຈິງ, ແລະລັກສະນະຂອງລະບົບໄຟລ໌ ext3 ພຽງແຕ່ເຮັດໃຫ້ບັນຫານີ້ຮ້າຍແຮງຂຶ້ນ.

ບັນຫາທີສອງເກີດຂຶ້ນໃນປີ 2009. ຫຼັງຈາກນັ້ນ, ຫຼັງຈາກລະບົບຂັດຂ້ອງ, ຜູ້ໃຊ້ຂອງລະບົບໄຟລ໌ ext4 ໃຫມ່ໄດ້ປະເຊີນກັບຄວາມຈິງທີ່ວ່າໄຟລ໌ທີ່ສ້າງຂຶ້ນໃຫມ່ຈໍານວນຫຼາຍມີຄວາມຍາວສູນ, ແຕ່ນີ້ບໍ່ໄດ້ເກີດຂຶ້ນກັບລະບົບໄຟລ໌ ext3 ເກົ່າ. ໃນວັກທີ່ຜ່ານມາ, ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບວິທີການ ext3 flushed ຂໍ້ມູນຫຼາຍເກີນໄປໃສ່ແຜ່ນ, ເຊິ່ງເຮັດໃຫ້ສິ່ງຕ່າງໆຊ້າລົງຫຼາຍ. fsync(). ເພື່ອປັບປຸງສະຖານະການ, ໃນ ext4 ພຽງແຕ່ຫນ້າທີ່ເປື້ອນທີ່ກ່ຽວຂ້ອງກັບໄຟລ໌ສະເພາະໃດຫນຶ່ງແມ່ນ flushed ກັບແຜ່ນ. ແລະຂໍ້ມູນຈາກໄຟລ໌ອື່ນໆຍັງຄົງຢູ່ໃນຫນ່ວຍຄວາມຈໍາເປັນເວລາດົນກວ່າກັບ ext3. ນີ້ແມ່ນເຮັດເພື່ອປັບປຸງການປະຕິບັດ (ໂດຍຄ່າເລີ່ມຕົ້ນ, ຂໍ້ມູນຈະຢູ່ໃນສະຖານະນີ້ເປັນເວລາ 30 ວິນາທີ, ທ່ານສາມາດປັບຄ່ານີ້ໄດ້ໂດຍໃຊ້ dirty_expire_centisecs; ທີ່ນີ້ ທ່ານສາມາດຊອກຫາເອກະສານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້). ນີ້ຫມາຍຄວາມວ່າຈໍານວນຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນສາມາດສູນເສຍ irretrievably ຫຼັງຈາກຄວາມລົ້ມເຫຼວ. ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ນີ້​ແມ່ນ​ການ​ນໍາ​ໃຊ້​ fsync() ໃນແອັບພລິເຄຊັນທີ່ຕ້ອງການຮັບປະກັນການເກັບຮັກສາຂໍ້ມູນທີ່ມີຄວາມຫມັ້ນຄົງແລະປົກປ້ອງພວກເຂົາຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ຈາກຜົນສະທ້ອນຂອງຄວາມລົ້ມເຫລວ. ຟັງຊັນ fsync() ເຮັດວຽກມີປະສິດທິພາບຫຼາຍເມື່ອໃຊ້ ext4 ກ່ວາເມື່ອໃຊ້ ext3. ຂໍ້ເສຍຂອງວິທີການນີ້ແມ່ນວ່າການນໍາໃຊ້ຂອງມັນ, ເຊັ່ນດຽວກັບກ່ອນ, ຊ້າລົງໃນການປະຕິບັດການດໍາເນີນການບາງຢ່າງເຊັ່ນ: ການຕິດຕັ້ງໂຄງການ. ເບິ່ງລາຍລະອຽດກ່ຽວກັບເລື່ອງນີ້ ທີ່ນີ້ и ທີ່ນີ້.

ບັນຫາທີສາມກ່ຽວກັບ fsync(), ມີ​ຕົ້ນ​ກໍາ​ເນີດ​ໃນ​ປີ 2018​. ຫຼັງຈາກນັ້ນ, ພາຍໃນກອບຂອງໂຄງການ PostgreSQL, ມັນພົບເຫັນວ່າຖ້າຫາກວ່າຫນ້າທີ່ fsync() ພົບຂໍ້ຜິດພາດ, ມັນຫມາຍຫນ້າ "ເປື້ອນ" ເປັນ "ສະອາດ". ດັ່ງນັ້ນ, ການໂທດັ່ງຕໍ່ໄປນີ້ fsync() ເຂົາເຈົ້າບໍ່ໄດ້ເຮັດຫຍັງກັບໜ້າດັ່ງກ່າວ. ດ້ວຍເຫດຜົນນີ້, ຫນ້າທີ່ດັດແກ້ໄດ້ຖືກເກັບໄວ້ໃນຫນ່ວຍຄວາມຈໍາແລະບໍ່ເຄີຍຖືກຂຽນໄວ້ໃນແຜ່ນ. ນີ້ແມ່ນໄພພິບັດທີ່ແທ້ຈິງ, ນັບຕັ້ງແຕ່ແອັບພລິເຄຊັນຈະຄິດວ່າຂໍ້ມູນບາງຢ່າງຖືກຂຽນໄວ້ໃນແຜ່ນ, ແຕ່ໃນຄວາມເປັນຈິງມັນຈະບໍ່ເປັນ. ຄວາມລົ້ມເຫຼວດັ່ງກ່າວ fsync() ແມ່ນຫາຍາກ, ຄໍາຮ້ອງສະຫມັກໃນສະຖານະການດັ່ງກ່າວສາມາດເຮັດໄດ້ເກືອບບໍ່ມີຫຍັງທີ່ຈະຕໍ່ສູ້ກັບບັນຫາ. ທຸກມື້ນີ້, ເມື່ອເຫດການນີ້ເກີດຂຶ້ນ, PostgreSQL ແລະແອັບພລິເຄຊັນອື່ນໆຂັດຂ້ອງ. ມັນເປັນ, ໃນເອກະສານ "ຄໍາຮ້ອງສະຫມັກສາມາດຟື້ນຕົວຈາກຄວາມລົ້ມເຫຼວຂອງ fsync ໄດ້ບໍ?", ບັນຫານີ້ໄດ້ຖືກຄົ້ນຫາຢ່າງລະອຽດ. ໃນປັດຈຸບັນການແກ້ໄຂທີ່ດີທີ່ສຸດຕໍ່ກັບບັນຫານີ້ແມ່ນການໃຊ້ Direct I/O ກັບທຸງ O_SYNC ຫຼືດ້ວຍທຸງ O_DSYNC. ດ້ວຍວິທີການນີ້, ລະບົບຈະລາຍງານຂໍ້ຜິດພາດທີ່ອາດຈະເກີດຂື້ນໃນລະຫວ່າງການປະຕິບັດການຂຽນສະເພາະ, ແຕ່ວິທີການນີ້ຕ້ອງການຄໍາຮ້ອງສະຫມັກໃນການຄຸ້ມຄອງ buffers ຕົວຂອງມັນເອງ. ອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ ທີ່ນີ້ и ທີ່ນີ້.

ການເປີດໄຟລ໌ໂດຍໃຊ້ທຸງ O_SYNC ແລະ O_DSYNC

ໃຫ້ກັບຄືນໄປຫາການສົນທະນາຂອງກົນໄກ Linux ທີ່ສະຫນອງການເກັບຮັກສາຂໍ້ມູນທີ່ຫມັ້ນຄົງ. ຄື, ພວກເຮົາເວົ້າກ່ຽວກັບການໃຊ້ທຸງຊາດ O_SYNC ຫຼືທຸງ O_DSYNC ເມື່ອເປີດໄຟລ໌ໂດຍໃຊ້ການໂທລະບົບ ເປີດ(). ດ້ວຍວິທີການນີ້, ແຕ່ລະການປະຕິບັດການຂຽນຂໍ້ມູນຖືກປະຕິບັດຄືກັບວ່າຫຼັງຈາກແຕ່ລະຄໍາສັ່ງ write() ລະບົບແມ່ນໃຫ້ຄໍາສັ່ງຕາມຄວາມເຫມາະສົມ fsync() и fdatasync(). ການ ຂໍ້ມູນຈໍາເພາະຂອງ POSIX ອັນນີ້ເອີ້ນວ່າ "ການສຳເລັດຄວາມສົມບູນຂອງໄຟລ໌ synchronized I/O" ແລະ "ການສໍາເລັດຂໍ້ມູນຄວາມສົມບູນ". ປະໂຫຍດຕົ້ນຕໍຂອງວິທີການນີ້ແມ່ນເພື່ອຮັບປະກັນຄວາມສົມບູນຂອງຂໍ້ມູນ, ທ່ານພຽງແຕ່ຕ້ອງການໂທຫາລະບົບດຽວ, ແທນທີ່ຈະເປັນສອງ (ຕົວຢ່າງ -. write() и fdatasync()). ຂໍ້ເສຍຫຼັກຂອງວິທີການນີ້ແມ່ນວ່າການຂຽນທັງຫມົດໂດຍໃຊ້ຕົວອະທິບາຍໄຟລ໌ທີ່ສອດຄ້ອງກັນຈະຖືກ synchronized, ເຊິ່ງສາມາດຈໍາກັດຄວາມສາມາດໃນການສ້າງໂຄງສ້າງລະຫັດຄໍາຮ້ອງສະຫມັກ.

ໃຊ້ Direct I/O ກັບທຸງ O_DIRECT

ໂທລະບົບ open() ສະຫນັບສະຫນູນທຸງ O_DIRECT, ເຊິ່ງຖືກອອກແບບເພື່ອຂ້າມແຄດຂອງລະບົບປະຕິບັດການເພື່ອປະຕິບັດການ I/O ໂດຍການຕິດຕໍ່ພົວພັນໂດຍກົງກັບແຜ່ນ. ນີ້, ໃນຫຼາຍໆກໍລະນີ, ຫມາຍຄວາມວ່າການຂຽນຄໍາສັ່ງທີ່ອອກໂດຍໂຄງການຈະຖືກແປໂດຍກົງເຂົ້າໄປໃນຄໍາສັ່ງທີ່ມີຈຸດປະສົງເພື່ອເຮັດວຽກກັບແຜ່ນ. ແຕ່ໂດຍທົ່ວໄປ, ກົນໄກນີ້ບໍ່ແມ່ນການທົດແທນຫນ້າທີ່ fsync() ຫຼື fdatasync(). ຄວາມຈິງແລ້ວແມ່ນວ່າແຜ່ນຕົວມັນເອງສາມາດເຮັດໄດ້ ເລື່ອນ ຫຼື cache ຄໍາສັ່ງຂຽນຂໍ້ມູນທີ່ສອດຄ້ອງກັນ. ແລະ, ເພື່ອເຮັດໃຫ້ບັນຫາຮ້າຍແຮງກວ່າເກົ່າ, ໃນບາງກໍລະນີພິເສດ, ການດໍາເນີນງານ I/O ປະຕິບັດໃນເວລາທີ່ໃຊ້ທຸງ O_DIRECT, ອອກອາກາດ ເຂົ້າໄປໃນການດໍາເນີນງານແບບດັ້ງເດີມ. ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະແກ້ໄຂບັນຫານີ້ແມ່ນການໃຊ້ທຸງເພື່ອເປີດໄຟລ໌ O_DSYNC, ຊຶ່ງຫມາຍຄວາມວ່າແຕ່ລະການປະຕິບັດການຂຽນຈະຖືກປະຕິບັດຕາມໂດຍການໂທຫາ fdatasync().

ມັນໄດ້ຫັນອອກວ່າລະບົບໄຟລ໌ XFS ບໍ່ດົນມານີ້ໄດ້ເພີ່ມ "ເສັ້ນທາງໄວ" ສໍາລັບ O_DIRECT|O_DSYNC- ການ​ບັນ​ທຶກ​ຂໍ້​ມູນ​. ຖ້າບລັອກຖືກຂຽນຄືນໂດຍໃຊ້ O_DIRECT|O_DSYNC, ຫຼັງຈາກນັ້ນ XFS, ແທນທີ່ຈະ flushing cache, ຈະປະຕິບັດຄໍາສັ່ງຂຽນ FUA ຖ້າອຸປະກອນສະຫນັບສະຫນູນມັນ. ຂ້າພະເຈົ້າໄດ້ກວດສອບນີ້ໂດຍການໃຊ້ປະໂຫຍດ blktrace ໃນລະບົບ Linux 5.4/Ubuntu 20.04. ວິທີການນີ້ຄວນຈະມີປະສິດທິພາບຫຼາຍຂຶ້ນ, ນັບຕັ້ງແຕ່ເມື່ອນໍາໃຊ້, ຈໍານວນຂໍ້ມູນຫນ້ອຍຖືກຂຽນໃສ່ແຜ່ນດິດແລະການດໍາເນີນງານຫນຶ່ງແມ່ນຖືກນໍາໃຊ້, ແທນທີ່ຈະເປັນສອງ (ການຂຽນແລະລ້າງແຄດ). ຂ້ອຍພົບລິ້ງຫາ patch 2018 kernel, ເຊິ່ງປະຕິບັດກົນໄກນີ້. ມີການສົນທະນາບາງຢ່າງກ່ຽວກັບການນໍາໃຊ້ການເພີ່ມປະສິດທິພາບນີ້ກັບລະບົບໄຟລ໌ອື່ນໆ, ແຕ່ເທົ່າທີ່ຂ້ອຍຮູ້, XFS ແມ່ນລະບົບໄຟລ໌ດຽວທີ່ສະຫນັບສະຫນູນນີ້ຈົນເຖິງປະຈຸບັນ.

ຟັງຊັນ sync_file_range()

Linux ມີການໂທຫາລະບົບ sync_file_range(), ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດລ້າງພຽງແຕ່ສ່ວນຫນຶ່ງຂອງໄຟລ໌ໄປຫາແຜ່ນ, ແທນທີ່ຈະເປັນໄຟລ໌ທັງຫມົດ. ການໂທນີ້ເລີ່ມການ flush ຂໍ້ມູນ asynchronous ແລະບໍ່ໄດ້ລໍຖ້າໃຫ້ມັນສໍາເລັດ. ແຕ່ຢູ່ໃນໃບຢັ້ງຢືນ sync_file_range() ທີມງານໄດ້ຖືກກ່າວວ່າ "ເປັນອັນຕະລາຍຫຼາຍ". ມັນບໍ່ໄດ້ຖືກແນະນໍາໃຫ້ໃຊ້ມັນ. ຄຸນນະສົມບັດແລະອັນຕະລາຍ sync_file_range() ອະທິບາຍໄດ້ດີຫຼາຍໃນ ນີ້ ວັດສະດຸ. ໂດຍສະເພາະ, ການໂທນີ້ປາກົດວ່າໃຊ້ RocksDB ເພື່ອຄວບຄຸມເວລາທີ່ kernel ລ້າງຂໍ້ມູນເປື້ອນໄປຫາແຜ່ນ. ແຕ່ໃນເວລາດຽວກັນ, ເພື່ອຮັບປະກັນການເກັບຮັກສາຂໍ້ມູນທີ່ມີຄວາມຫມັ້ນຄົງ, ມັນຍັງຖືກນໍາໃຊ້ fdatasync(). ການ ລະຫັດ RocksDB ມີບາງຄໍາເຫັນທີ່ຫນ້າສົນໃຈກ່ຽວກັບຫົວຂໍ້ນີ້. ຕົວຢ່າງ, ມັນປາກົດວ່າການໂທ sync_file_range() ເມື່ອໃຊ້ ZFS, ມັນບໍ່ໄດ້ລ້າງຂໍ້ມູນໃສ່ແຜ່ນ. ປະສົບການບອກຂ້ອຍວ່າລະຫັດທີ່ບໍ່ຄ່ອຍໄດ້ໃຊ້ມີແນວໂນ້ມທີ່ຈະມີແມງໄມ້. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າຈະແນະນໍາໃຫ້ໃຊ້ການໂທລະບົບນີ້ເວັ້ນເສຍແຕ່ມີຄວາມຈໍາເປັນຢ່າງແທ້ຈິງ.

ການໂທລະບົບທີ່ຊ່ວຍຮັບປະກັນຂໍ້ມູນຄົງຄ້າງ

ຂ້ອຍໄດ້ສະຫຼຸບແລ້ວວ່າມີສາມວິທີການທີ່ສາມາດໃຊ້ເພື່ອປະຕິບັດການ I/O ທີ່ຮັບປະກັນຂໍ້ມູນຄົງທີ່. ພວກເຂົາທັງຫມົດຮຽກຮ້ອງໃຫ້ມີການໂທຫາຫນ້າທີ່ fsync() ສໍາລັບໄດເລກະທໍລີທີ່ໄຟລ໌ຖືກສ້າງຂຶ້ນ. ເຫຼົ່ານີ້ແມ່ນວິທີການ:

1. ໂທຫາຫນ້າທີ່ fdatasync() ຫຼື fsync() ຫຼັງ​ຈາກ​ການ​ທໍາ​ງານ​ write() (ມັນດີກວ່າທີ່ຈະໃຊ້ fdatasync()).
2. ເຮັດວຽກກັບຕົວອະທິບາຍໄຟລ໌ທີ່ເປີດດ້ວຍທຸງ O_DSYNC ຫຼື O_SYNC (ດີກວ່າ - ມີທຸງ O_DSYNC).
3. ການນໍາໃຊ້ຄໍາສັ່ງ pwritev2() ກັບທຸງ RWF_DSYNC ຫຼື RWF_SYNC (ມັກດ້ວຍທຸງ RWF_DSYNC).

ບັນທຶກການປະຕິບັດ

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

1. ການຂຽນທັບຂໍ້ມູນໄຟລ໌ໄວກວ່າການຕື່ມຂໍ້ມູນໃສ່ໄຟລ໌ (ຜົນປະໂຫຍດປະສິດທິພາບສາມາດເປັນ 2-100%). ການຕື່ມຂໍ້ມູນໃສ່ໄຟລ໌ຕ້ອງການການປ່ຽນແປງເພີ່ມເຕີມຕໍ່ກັບ metadata ຂອງໄຟລ໌, ເຖິງແມ່ນວ່າຫຼັງຈາກການໂທລະບົບ fallocate(), ແຕ່ຂະຫນາດຂອງຜົນກະທົບນີ້ອາດຈະແຕກຕ່າງກັນ. ຂ້າພະເຈົ້າແນະນໍາໃຫ້, ສໍາລັບການປະຕິບັດທີ່ດີທີ່ສຸດ, ໂທຫາ fallocate() ເພື່ອຈັດສັນພື້ນທີ່ທີ່ຕ້ອງການລ່ວງໜ້າ. ຫຼັງຈາກນັ້ນ, ຊ່ອງນີ້ຕ້ອງໄດ້ຮັບການເຕັມໄປດ້ວຍສູນແລະເອີ້ນວ່າ fsync(). ນີ້ຈະຮັບປະກັນວ່າຕັນທີ່ສອດຄ້ອງກັນໃນລະບົບໄຟລ໌ຖືກຫມາຍເປັນ "ຈັດສັນ" ແທນທີ່ຈະ "ບໍ່ໄດ້ຈັດສັນ". ນີ້ເຮັດໃຫ້ການປັບປຸງປະສິດທິພາບຂະຫນາດນ້ອຍ (ປະມານ 2%). ນອກຈາກນັ້ນ, ບາງແຜ່ນອາດມີການເຂົ້າເຖິງບລັອກທໍາອິດຊ້າກວ່າແຜ່ນອື່ນ. ນີ້ຫມາຍຄວາມວ່າການຕື່ມຊ່ອງໃສ່ກັບສູນສາມາດນໍາໄປສູ່ການປັບປຸງທີ່ສໍາຄັນ (ປະມານ 100%). ໂດຍສະເພາະ, ນີ້ສາມາດເກີດຂຶ້ນກັບແຜ່ນ AWS EBS (ນີ້ແມ່ນຂໍ້ມູນທີ່ບໍ່ເປັນທາງການ, ຂ້ອຍບໍ່ສາມາດຢືນຢັນໄດ້). ເຊັ່ນດຽວກັນສໍາລັບການເກັບຮັກສາ GCP Persistent Disk (ແລະນີ້ແມ່ນຂໍ້ມູນຢ່າງເປັນທາງການແລ້ວ, ຢືນຢັນໂດຍການທົດສອບ). ຜູ້ຊ່ຽວຊານອື່ນໆໄດ້ເຮັດເຊັ່ນດຽວກັນ ການສັງເກດການ, ກ່ຽວຂ້ອງກັບແຜ່ນຕ່າງໆ.
2. ການໂທລະບົບຫນ້ອຍ, ການປະຕິບັດທີ່ສູງຂຶ້ນ (ການເພີ່ມສາມາດປະມານ 5%). ເບິ່ງຄືວ່າເປັນສິ່ງທ້າທາຍ open() ກັບທຸງ O_DSYNC ຫຼືໂທຫາ pwritev2() ກັບທຸງ RWF_SYNC ໄວກວ່າການໂທ fdatasync(). ຂ້າພະເຈົ້າສົງໃສວ່າຈຸດນີ້ແມ່ນວ່າວິທີການນີ້ມີບົດບາດໃນຄວາມຈິງທີ່ວ່າການໂທຫາລະບົບຫນ້ອຍຕ້ອງໄດ້ປະຕິບັດເພື່ອແກ້ໄຂບັນຫາດຽວກັນ (ຫນຶ່ງໂທແທນທີ່ຈະສອງ). ແຕ່ຄວາມແຕກຕ່າງໃນການປະຕິບັດແມ່ນນ້ອຍຫຼາຍ, ດັ່ງນັ້ນທ່ານສາມາດບໍ່ສົນໃຈມັນຢ່າງສົມບູນແລະນໍາໃຊ້ບາງສິ່ງບາງຢ່າງໃນຄໍາຮ້ອງສະຫມັກທີ່ຈະບໍ່ສັບສົນຕາມເຫດຜົນຂອງມັນ.

ຖ້າທ່ານສົນໃຈຫົວຂໍ້ຂອງການເກັບຮັກສາຂໍ້ມູນແບບຍືນຍົງ, ນີ້ແມ່ນບາງອຸປະກອນທີ່ເປັນປະໂຫຍດ:

• ວິທີການເຂົ້າເຖິງ I/O — ພາບ​ລວມ​ຂອງ​ພື້ນ​ຖານ​ຂອງ​ກົນ​ໄກ​ການ​ປ້ອນ​ຂໍ້​ມູນ / ຜົນ​ຜະ​ລິດ​.
• ຮັບປະກັນຂໍ້ມູນເຖິງແຜ່ນ — ເລື່ອງ​ກ່ຽວ​ກັບ​ສິ່ງ​ທີ່​ເກີດ​ຂຶ້ນ​ກັບ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ວິ​ທີ​ການ​ຈາກ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ກັບ​ແຜ່ນ​ໄດ້​.
• ເມື່ອໃດທີ່ທ່ານຄວນ fsync ໄດເລກະທໍລີທີ່ບັນຈຸ - ຄໍາຕອບຂອງຄໍາຖາມຂອງເວລາທີ່ຈະນໍາໃຊ້ fsync() ສໍາລັບໄດເລກະທໍລີ. ເພື່ອສະຫຼຸບມັນ, ມັນປາກົດວ່າທ່ານຈໍາເປັນຕ້ອງເຮັດມັນໃນເວລາສ້າງໄຟລ໌ໃຫມ່, ແລະເຫດຜົນສໍາລັບການແນະນໍານີ້ແມ່ນວ່າໃນ Linux ສາມາດມີການອ້າງອີງຫຼາຍໄຟລ໌ດຽວກັນ.
• SQL Server ໃນ Linux: FUA Internals — ນີ້ແມ່ນຄໍາອະທິບາຍກ່ຽວກັບວິທີການເກັບຮັກສາຂໍ້ມູນຄົງທີ່ຖືກປະຕິບັດຢູ່ໃນ SQL Server ໃນເວທີ Linux. ມີການປຽບທຽບທີ່ຫນ້າສົນໃຈລະຫວ່າງການໂທລະບົບ Windows ແລະ Linux ຢູ່ທີ່ນີ້. ຂ້ອຍເກືອບແນ່ໃຈວ່າມັນແມ່ນຍ້ອນເອກະສານນີ້ທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ກ່ຽວກັບການເພີ່ມປະສິດທິພາບ FUA ຂອງ XFS.

ທ່ານໄດ້ສູນເສຍຂໍ້ມູນທີ່ເຈົ້າຄິດວ່າຖືກເກັບໄວ້ຢ່າງປອດໄພຢູ່ໃນແຜ່ນບໍ?

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