ການສໍາພາດຄັ້ງທີສອງກັບ Eduard Shishkin, ນັກພັດທະນາຂອງ Reiser4 FS

ການສໍາພາດຄັ້ງທີສອງກັບ Eduard Shishkin, ຜູ້ພັດທະນາລະບົບໄຟລ໌ Reiser4, ໄດ້ຖືກຈັດພີມມາ.

ເພື່ອເລີ່ມຕົ້ນ, ກະລຸນາເຕືອນຜູ້ອ່ານວ່າເຈົ້າເຮັດວຽກຢູ່ໃສແລະໃຜ.

ຂ້ອຍເຮັດວຽກເປັນສະຖາປະນິກການເກັບຮັກສາຫຼັກຢູ່ Huawei Technologies, ສູນຄົ້ນຄວ້າເຢຍລະມັນ. ໃນພະແນກ virtualization ຂ້າພະເຈົ້າຈັດການກັບລັກສະນະຕ່າງໆຂອງການເກັບຮັກສາຂໍ້ມູນ. ກິດຈະກໍາຂອງຂ້ອຍບໍ່ກ່ຽວຂ້ອງກັບລະບົບປະຕິບັດການສະເພາະ.

ຕອນນີ້ເຈົ້າກໍາລັງເຮັດກັບສາຂາຫຼັກບໍ?

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

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

ຂ້າພະເຈົ້າບໍ່ເຄີຍເຫັນການປ່ຽນແປງໃດໆສໍາລັບການທີ່ດີກວ່າ. ບັນຫາຕົ້ນຕໍຂອງຊຸມຊົນແມ່ນການທົດແທນວິທະຍາສາດດ້ວຍເຕັກໂນໂລຢີທາງດ້ານການເມືອງ, ຄວາມສໍາພັນສ່ວນບຸກຄົນ, ຄວາມຄິດເຫັນສ່ວນໃຫຍ່, ປະຊາກອນ, ຄໍາແນະນໍາຈາກ "ສຽງພາຍໃນ," ການປະນີປະນອມທີ່ເສື່ອມໂຊມ, ສິ່ງອື່ນນອກເຫນືອຈາກວິທະຍາສາດ. ວິ​ທະ​ຍາ​ສາດ​ຄອມ​ພິວ​ເຕີ​, ສິ່ງ​ໃດ​ຫນຶ່ງ​ອາດ​ຈະ​ເວົ້າ​ວ່າ​, ເປັນ​ວິ​ທະ​ຍາ​ສາດ​ທໍາ​ອິດ​ແລະ​ສໍາ​ຄັນ​ທີ່​ສຸດ​. ແລະຖ້າຜູ້ໃດຜູ້ນຶ່ງເລີ່ມປະກາດມູນຄ່າຂອງຕົນເອງສໍາລັບ 2x2, ແຕກຕ່າງຈາກ 4, ພາຍໃຕ້ທຸງ "ວິທີ Linux", ຫຼືພາຍໃຕ້ທຸງອື່ນໆ, ຫຼັງຈາກນັ້ນ, ມັນອາດຈະບໍ່ມີສິ່ງໃດນອກເຫນືອຈາກອັນຕະລາຍ.

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

ທ່ານປະເມີນຄວາມຄືບຫນ້າໃນການພັດທະນາ Btrfs ແນວໃດ? FS ນີ້ໄດ້ຮັບການກໍາຈັດພະຍາດໃນໄວເດັກບໍ? ເຈົ້າຕັ້ງມັນໃຫ້ຕົວເອງແນວໃດ - ເປັນ FS "ສໍາລັບເຮືອນ" ຫຼືສໍາລັບການນໍາໃຊ້ຂອງບໍລິສັດເຊັ່ນກັນ?

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

ມັນເບິ່ງຄືວ່ານີ້ (ທົດສອບສໍາລັບ Linux kernel 5.12). script ຖືກເປີດຕົວໃນລະບົບທີ່ຕິດຕັ້ງໃຫມ່, ເຊິ່ງໃນ loop ສ້າງໄຟລ໌ທີ່ມີຊື່ທີ່ແນ່ນອນໃນ home directory, ຂຽນຂໍ້ມູນໃຫ້ພວກເຂົາຢູ່ໃນບາງ offsets, ແລະຫຼັງຈາກນັ້ນລຶບໄຟລ໌ເຫຼົ່ານີ້. ຫຼັງຈາກນາທີຂອງການເຮັດວຽກ script ນີ້, ບໍ່ມີຫຍັງຜິດປົກກະຕິເກີດຂຶ້ນ. ຫຼັງຈາກຫ້ານາທີ, ສ່ວນຂອງພື້ນທີ່ຄອບຄອງຢູ່ໃນການແບ່ງສ່ວນເພີ່ມຂຶ້ນເລັກນ້ອຍ. ຫຼັງຈາກສອງຫາສາມຊົ່ວໂມງມັນໄປຮອດ 50% (ມີມູນຄ່າເບື້ອງຕົ້ນ 15%). ແລະຫຼັງຈາກຫ້າຫຼືຫົກຊົ່ວໂມງຂອງການເຮັດວຽກ, ສະຄິບຂັດກັບຄວາມຜິດພາດ "ບໍ່ມີພື້ນທີ່ຫວ່າງໃນພາທິຊັນ." ຫຼັງ​ຈາກ​ນີ້​, ທ່ານ​ບໍ່​ສາ​ມາດ​ທີ່​ຈະ​ຂຽນ​ເຖິງ​ແມ່ນ​ວ່າ​ໄຟລ​໌ 4K ກັບ​ການ​ແບ່ງ​ປັນ​ຂອງ​ທ່ານ​.

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

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

ທ່ານ​ຈະ​ບໍ່​ສາ​ມາດ​ເອົາ​ລະ​ບົບ​ໄຟລ​໌​ຕົ້ນ​ຕໍ​ອື່ນໆ​ທີ່​ຈະ​ໂຈມ​ຕີ​ດັ່ງ​ກ່າວ (ບໍ່​ວ່າ​ພວກ​ເຂົາ​ເຈົ້າ​ຈະ​ບອກ​ທ່ານ​)​. ຂ້າພະເຈົ້າໄດ້ອະທິບາຍເຖິງສາເຫດຂອງບັນຫາໃນເວລາດົນນານກ່ອນຫນ້ານີ້: ນີ້ແມ່ນການບິດເບືອນທັງຫມົດຂອງແນວຄວາມຄິດ B-tree ໃນ Btrfs, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ spontaneous ຫຼື degenerate ໂດຍເຈດຕະນາ. ໂດຍສະເພາະ, ພາຍໃຕ້ການໂຫຼດບາງຢ່າງ, ລະບົບໄຟລ໌ຂອງທ່ານຈະ "ແຕກແຍກ" ຢ່າງຕໍ່ເນື່ອງໃນລະຫວ່າງການປະຕິບັດງານຂອງມັນເອງ, ໂດຍບໍ່ມີການຊ່ວຍເຫຼືອຈາກພາຍນອກ. ມັນເປັນທີ່ຊັດເຈນວ່າຂະບວນການພື້ນຖານ "ກົດ" ທຸກປະເພດຈະຊ່ວຍປະຢັດມື້ພຽງແຕ່ຢູ່ໃນ desktop ແຕ່ລະຄົນ.

ຢູ່ໃນເຊີບເວີລວມ, ຜູ້ໂຈມຕີຈະສາມາດ "ນຳໜ້າ" ພວກມັນໄດ້ສະເໝີ. ຜູ້ເບິ່ງແຍງລະບົບຈະບໍ່ສາມາດກໍານົດໄດ້ວ່າໃຜຂົ່ມເຫັງລາວຢ່າງແທ້ຈິງ. ວິທີທີ່ໄວທີ່ສຸດທີ່ຈະແກ້ໄຂບັນຫານີ້ໃນ Btrfs ແມ່ນເພື່ອຟື້ນຟູໂຄງສ້າງຂອງຕົ້ນໄມ້ B-tee ປົກກະຕິ, i.e. ການອອກແບບຮູບແບບດິສກ໌ຄືນໃຫມ່ແລະຂຽນຄືນບາງສ່ວນທີ່ສໍາຄັນຂອງລະຫັດ Btrfs. ນີ້ຈະໃຊ້ເວລາ 8-10 ປີ, ລວມທັງການດີບັກ, ສະຫນອງໃຫ້ວ່ານັກພັດທະນາປະຕິບັດຕາມບົດຄວາມຕົ້ນສະບັບກ່ຽວກັບ algorithms ແລະໂຄງສ້າງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງຢ່າງເຂັ້ມງວດ, ແລະບໍ່ໄດ້ຫຼິ້ນເກມ "ໂທລະສັບແຕກ", ຕາມປະເພນີ (ແລະຊຸກຍູ້ໃຫ້) ໃນ "Linux. ທາງ”.

ໃນທີ່ນີ້ພວກເຮົາຍັງຈໍາເປັນຕ້ອງເພີ່ມເວລາທີ່ຕ້ອງການສໍາລັບນັກພັດທະນາເພື່ອເຂົ້າໃຈທັງຫມົດນີ້. ນີ້ແມ່ນບ່ອນທີ່ມັນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ. ໃນກໍລະນີໃດກໍ່ຕາມ, 10 ປີແມ່ນບໍ່ພຽງພໍສໍາລັບພວກເຂົາທີ່ຈະເຂົ້າໃຈ. ແລ້ວ, ຈົນກ່ວານັ້ນ, ທ່ານບໍ່ສາມາດຫວັງວ່າສໍາລັບການມະຫັດສະຈັນ. ມັນຈະບໍ່ເກີດຂຶ້ນໃນຮູບແບບຂອງທາງເລືອກໃນການຕິດຕັ້ງ "ທີ່ທ່ານແລະຂ້ອຍບໍ່ຮູ້ກ່ຽວກັບ," ຫຼືໃນຮູບແບບຂອງ patch ທີ່ເປັນ "ພຽງແຕ່ເປັນເລື່ອງຂອງທຸລະກິດ" ການກະກຽມ. ສໍາລັບແຕ່ລະ "ແກ້ໄຂ" ທີ່ເລັ່ງດ່ວນຂ້າພະເຈົ້າຈະນໍາສະເຫນີສະຖານະການໃຫມ່ຂອງ degeneration. B-trees ແມ່ນຫນຶ່ງໃນຫົວຂໍ້ທີ່ຂ້ອຍມັກ, ແລະຂ້ອຍຕ້ອງເວົ້າວ່າໂຄງສ້າງເຫຼົ່ານີ້ບໍ່ທົນທານຕໍ່ເສລີພາບກັບຕົວເອງ!

ຂ້ອຍຈະວາງ Btrfs ສໍາລັບຕົວເອງແນວໃດ? ເປັນສິ່ງທີ່ບໍ່ສາມາດເອີ້ນວ່າລະບົບໄຟລ໌ຢ່າງແທ້ຈິງ, ໃຫ້ໃຊ້ຢ່າງດຽວ. ເນື່ອງຈາກວ່າ, ຕາມຄໍານິຍາມ, FS ແມ່ນລະບົບຍ່ອຍຂອງ OS ທີ່ຮັບຜິດຊອບໃນການຄຸ້ມຄອງຊັບພະຍາກອນ "ພື້ນທີ່ດິດ", ເຊິ່ງພວກເຮົາບໍ່ເຫັນໃນກໍລະນີຂອງ Btrfs. ດີ, ຈິນຕະນາການວ່າເຈົ້າມາຮ້ານເພື່ອຊື້ໂມງເພື່ອບໍ່ໃຫ້ໄປເຮັດວຽກຊ້າ, ແລະແທນທີ່ຈະເປັນໂມງ, ເຂົາເຈົ້າໄດ້ຂາຍປີ້ງໄຟຟ້າທີ່ມີເຄື່ອງຈັບເວລາສູງສຸດ 30 ນາທີ. ດັ່ງນັ້ນ, ສະຖານະການກັບ Btrfs ແມ່ນຮ້າຍແຮງກວ່າເກົ່າ.

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

ຂ້າພະເຈົ້າຢາກຮ້ອງຂໍໃຫ້ມີຄໍາເຫັນກ່ຽວກັບການຢຸດເຊົາການສະຫນັບສະຫນູນ Btrfs ໃນ RHEL.

ບໍ່ມີຫຍັງພິເສດທີ່ຈະສະແດງຄວາມຄິດເຫັນຢູ່ທີ່ນີ້, ທຸກສິ່ງທຸກຢ່າງແມ່ນຈະແຈ້ງຫຼາຍ. ພວກເຂົາຍັງມີມັນເປັນ "ຕົວຢ່າງເຕັກໂນໂລຢີ". ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າບໍ່ໄດ້ຜ່ານ "ຕົວຢ່າງ" ນີ້. ຢ່າປ່ອຍໃຫ້ປ້າຍນີ້ຕິດຢູ່ຕະຫຼອດ! ແຕ່ພວກເຂົາບໍ່ສາມາດເປີດຕົວຜະລິດຕະພັນທີ່ມີການອອກແບບທີ່ມີຂໍ້ບົກພ່ອງໂດຍການສະຫນັບສະຫນູນຢ່າງເຕັມທີ່. RHEL ແມ່ນວິສາຫະກິດ, ນັ້ນແມ່ນ, ກໍານົດການພົວພັນສິນຄ້າ - ເງິນ. Red Hat ບໍ່ສາມາດຂົ່ມເຫັງຜູ້ໃຊ້ຄືກັບທີ່ພວກເຂົາເຮັດຢູ່ໃນບັນຊີລາຍຊື່ທາງໄປສະນີ Btrfs. ພຽງແຕ່ຈິນຕະນາການສະຖານະການ: ລູກຄ້າຜູ້ທີ່ຈ່າຍເງິນທີ່ຫາໄດ້ຍາກຂອງລາວສໍາລັບແຜ່ນດິດແລະທ່ານສໍາລັບການສະຫນັບສະຫນູນ, ຕ້ອງການເຂົ້າໃຈວ່າພື້ນທີ່ດິດຂອງລາວໄປໃສຫຼັງຈາກທີ່ລາວບໍ່ໄດ້ຂຽນຫຍັງລົງ. ເຈົ້າຈະຕອບລາວແນວໃດຕໍ່ເລື່ອງນີ້?

ຕື່ມອີກ. ລູກຄ້າຂອງ Red Hat ປະກອບມີທະນາຄານຂະຫນາດໃຫຍ່ທີ່ມີຊື່ສຽງແລະການແລກປ່ຽນ. ຈິນຕະນາການສິ່ງທີ່ຈະເກີດຂື້ນຖ້າພວກເຂົາຖືກໂຈມຕີ DoS ໂດຍອີງໃສ່ຈຸດອ່ອນທີ່ໄດ້ກ່າວມາໃນ Btrfs. ເຈົ້າຄິດວ່າໃຜເປັນຜູ້ຮັບຜິດຊອບຕໍ່ເລື່ອງນີ້? ກັບຜູ້ທີ່ກໍາລັງຈະຊີ້ນິ້ວມືຂອງພວກເຂົາໃສ່ເສັ້ນຂອງໃບອະນຸຍາດ GPL, ບ່ອນທີ່ມັນຖືກຂຽນວ່າຜູ້ຂຽນບໍ່ຮັບຜິດຊອບຕໍ່ສິ່ງໃດ, ຂ້ອຍຈະເວົ້າທັນທີວ່າ: "ເຊື່ອງມັນໄປ!" Red Hat ຈະຕອບ, ແລະໃນແບບທີ່ມັນເບິ່ງຄືວ່າບໍ່ພຽງພໍ! ແຕ່ຂ້ອຍຮູ້ວ່າ Red Hat ບໍ່ໄດ້ປະເຊີນກັບບັນຫາແບບນີ້, ເນື່ອງຈາກທີມງານວິສະວະກອນ QA ທີ່ເຂັ້ມແຂງໂດຍສະເພາະທີ່ຂ້ອຍໄດ້ມີໂອກາດເຮັດວຽກຢ່າງໃກ້ຊິດໃນເວລາຂອງຂ້ອຍ.

ເປັນຫຍັງບາງບໍລິສັດສືບຕໍ່ສະຫນັບສະຫນູນ Btrfs ໃນຜະລິດຕະພັນວິສາຫະກິດຂອງພວກເຂົາ?

ກະລຸນາສັງເກດວ່າຄໍານໍາຫນ້າ "ວິສາຫະກິດ" ໃນຊື່ຜະລິດຕະພັນບໍ່ມີຄວາມຫມາຍຫຼາຍ. ວິ​ສາ​ຫະ​ກິດ​ແມ່ນ​ມາດ​ຕະ​ການ​ຂອງ​ຄວາມ​ຮັບ​ຜິດ​ຊອບ​ຝັງ​ຢູ່​ໃນ​ສາຍ​ພົວ​ພັນ​ສັນ​ຍາ​ກັບ​ລູກ​ຄ້າ. ຂ້ອຍຮູ້ພຽງແຕ່ວິສາຫະກິດໜຶ່ງທີ່ອີງໃສ່ GNU/Linux - RHEL. ທຸກສິ່ງທຸກຢ່າງອື່ນ, ຈາກທັດສະນະຂອງຂ້າພະເຈົ້າ, ໄດ້ຖືກນໍາສະເຫນີພຽງແຕ່ເປັນວິສາຫະກິດ, ແຕ່ບໍ່ແມ່ນຫນຶ່ງ. ແລະສຸດທ້າຍ, ຖ້າມີຄວາມຕ້ອງການບາງສິ່ງບາງຢ່າງ, ມັນຈະມີການສະຫນອງສະເຫມີ (ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນ "ສະຫນັບສະຫນູນ" ທີ່ໄດ້ກ່າວມາ). ມີຄວາມຕ້ອງການສໍາລັບທຸກສິ່ງທຸກຢ່າງຢ່າງແທ້ຈິງ, ລວມທັງ. ແລະຊອບແວທີ່ບໍ່ສາມາດໃຊ້ໄດ້. ຄວາມຕ້ອງການດັ່ງກ່າວຖືກສ້າງຕັ້ງຂື້ນແນວໃດແລະໃຜເປັນຜູ້ຈູດມັນແມ່ນຫົວຂໍ້ອື່ນ.

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

ເປັນຫຍັງຈຶ່ງມີຄວາມພະຍາຍາມຫຼາຍໃນການທໍາຄວາມສະອາດລະຫັດ XFS ບໍ່ດົນມານີ້? ຫຼັງຈາກທີ່ທັງຫມົດ, ໃນເບື້ອງຕົ້ນນີ້ແມ່ນລະບົບໄຟລ໌ພາກສ່ວນທີສາມ, ແລະ ext4 ມີຄວາມຫມັ້ນຄົງເປັນເວລາດົນນານແລະມີຄວາມຕໍ່ເນື່ອງຈາກສະບັບທີ່ມີຄວາມຫມັ້ນຄົງເທົ່າທຽມກັນກ່ອນຫນ້ານີ້. Red Hat ມີຄວາມສົນໃຈຫຍັງໃນ XFS? ມັນມີຄວາມຮູ້ສຶກທີ່ຈະພັດທະນາລະບົບໄຟລ໌ສອງຢ່າງທີ່ມີຈຸດປະສົງທີ່ຄ້າຍຄືກັນ - ext4 ແລະ XFS?

ຂ້ອຍບໍ່ຈື່ຫຍັງກະຕຸ້ນສິ່ງນີ້. ມັນເປັນໄປໄດ້ຂ້ອນຂ້າງວ່າການລິເລີ່ມມາຈາກລູກຄ້າ Red Hat. ຂ້າພະເຈົ້າຈື່ໄດ້ວ່າການຄົ້ນຄວ້າຂອງປະເພດນີ້ໄດ້ຖືກປະຕິບັດ: ໃນບາງລະບົບໄຟລ໌ຈາກຕົ້ນນ້ໍາ, ຈໍານວນອັນໃຫຍ່ຫຼວງຂອງວັດຖຸໄດ້ຖືກສ້າງຂື້ນຢູ່ໃນໄດເວີຊັ້ນສູງຂອງຄົນຮຸ່ນໃຫມ່. ອີງຕາມຜົນໄດ້ຮັບ, XFS behaved ດີກວ່າ ext4. ດັ່ງນັ້ນເຂົາເຈົ້າຈຶ່ງເລີ່ມສົ່ງເສີມມັນໃຫ້ດີທີ່ສຸດ. ໃນກໍລະນີໃດກໍ່ຕາມ, ຂ້າພະເຈົ້າຈະບໍ່ຊອກຫາສິ່ງທີ່ມີຄວາມຮູ້ສຶກຢູ່ທີ່ນີ້.

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

ທ່ານຄິດວ່າບັນຫາຂອງການລະເມີດຊັ້ນໄດ້ຖືກແກ້ໄຂ (ໃນແງ່ລົບ) ກັບການມາເຖິງຂອງຫນ້າທີ່ການເຂົ້າລະຫັດໃນ ext4, F2FS (ບໍ່ເວົ້າເຖິງ RAID ໃນ Btrfs)?

ໂດຍທົ່ວໄປແລ້ວ, ການແນະນໍາລະດັບໃດຫນຶ່ງແລະການຕັດສິນໃຈກ່ຽວກັບການບໍ່ລະເມີດຂອງພວກເຂົາແມ່ນປົກກະຕິແລ້ວເປັນນະໂຍບາຍ, ແລະຂ້າພະເຈົ້າບໍ່ປະຕິບັດຄໍາຄິດຄໍາເຫັນກ່ຽວກັບສິ່ງໃດແດ່ທີ່ນີ້. ຈຸດປະສົງຂອງການລະເມີດຊັ້ນແມ່ນມີຄວາມສົນໃຈຫນ້ອຍສໍາລັບທຸກຄົນ, ແຕ່ພວກເຮົາສາມາດພິຈາລະນາບາງສ່ວນຂອງພວກເຂົາໂດຍໃຊ້ຕົວຢ່າງຂອງການລະເມີດ "ຈາກຂ້າງເທິງ," ຄື, ການປະຕິບັດໃນ FS ຂອງຫນ້າທີ່ທີ່ມີຢູ່ແລ້ວໃນຊັ້ນບລັອກ. "ການລະເມີດ" ດັ່ງກ່າວເປັນເຫດຜົນພຽງແຕ່ມີຂໍ້ຍົກເວັ້ນທີ່ຫາຍາກ. ສໍາລັບແຕ່ລະກໍລະນີດັ່ງກ່າວ, ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງພິສູດສອງຢ່າງ: ມັນ ຈຳ ເປັນແທ້ໆ, ແລະການອອກແບບຂອງລະບົບຈະບໍ່ເປັນອັນຕະລາຍໂດຍການເຮັດແນວນັ້ນ.

ຕົວຢ່າງ, ການສະທ້ອນ, ເຊິ່ງມີປະເພນີເປັນກິດຈະກໍາສໍາລັບຊັ້ນບລັອກ, ເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະປະຕິບັດໃນລະດັບລະບົບໄຟລ໌. ສໍາລັບເຫດຜົນທີ່ແຕກຕ່າງກັນ. ຕົວຢ່າງ, "ງຽບ" ຂໍ້ມູນສໍ້ລາດບັງຫຼວງ (ບິດເບືອນ) ເກີດຂື້ນໃນແຜ່ນດິດ. ນີ້ແມ່ນເວລາທີ່ອຸປະກອນເຮັດວຽກຢ່າງຖືກຕ້ອງ, ແຕ່ຂໍ້ມູນຕັນແມ່ນເສຍຫາຍຢ່າງບໍ່ຄາດຄິດພາຍໃຕ້ອິດທິພົນຂອງ gamma quantum ແຂງທີ່ປ່ອຍອອກມາໂດຍ quasar ຫ່າງໄກ, ແລະອື່ນໆ. ສິ່ງທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນຖ້າບລັອກນີ້ກາຍເປັນບລັອກລະບົບ FS (superblock, bitmap block, storage tree node, ແລະອື່ນໆ), ເພາະວ່ານີ້ແນ່ນອນຈະນໍາໄປສູ່ການຕົກໃຈຂອງແກ່ນ.

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

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

Reiser4 ຖືກກ່າວຫາວ່າລະເມີດລະດັບ "ຈາກຂ້າງລຸ່ມນີ້". ອີງໃສ່ຄວາມຈິງທີ່ວ່າລະບົບໄຟລ໌ບໍ່ແມ່ນ monolithic, ເຊັ່ນດຽວກັບເຄື່ອງອື່ນໆ, ແຕ່ແບບໂມດູນ, ການສົມມຸດຕິຖານທີ່ບໍ່ມີຫຼັກຖານໄດ້ຖືກເຮັດໃຫ້ມັນເຮັດສິ່ງທີ່ລະດັບຂ້າງເທິງ (VFS) ຄວນເຮັດ.

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

ໃນທີ່ນີ້ພວກເຮົາຈໍາເປັນຕ້ອງກໍານົດວ່າການເສຍຊີວິດຂອງຜະລິດຕະພັນຊອບແວຫມາຍຄວາມວ່າແນວໃດ. ໃນອີກດ້ານຫນຶ່ງ, ພວກມັນຖືກນໍາໃຊ້ຢ່າງສໍາເລັດຜົນ (ນັ້ນແມ່ນສິ່ງທີ່ພວກເຂົາຖືກສ້າງຂຶ້ນ, ຫຼັງຈາກທີ່ທັງຫມົດ), ຊຶ່ງຫມາຍຄວາມວ່າພວກເຂົາມີຊີວິດຢູ່. ໃນທາງກົງກັນຂ້າມ, ຂ້ອຍບໍ່ສາມາດເວົ້າສໍາລັບ JFS (ຂ້ອຍບໍ່ຮູ້ຫຼາຍ), ແຕ່ ReiserFS (v3) ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະປັບຕົວກັບແນວໂນ້ມໃຫມ່ (ທົດສອບໃນການປະຕິບັດ). ນີ້ຫມາຍຄວາມວ່າໃນອະນາຄົດນັກພັດທະນາຈະເອົາໃຈໃສ່ບໍ່ແມ່ນມັນ, ແຕ່ກັບຜູ້ທີ່ງ່າຍຕໍ່ການປັບຕົວ. ຈາກດ້ານນີ້ມັນປາກົດວ່າ, ອະນິຈາ, ມັນຕາຍໃນສະຖາປັດຕະຍະກໍາ. ຂ້າພະເຈົ້າຈະບໍ່ດັດແປງແນວຄວາມຄິດຂອງ "ການລ້າສະໄຫມທາງດ້ານສິນທໍາ" ເລີຍ. ມັນໃຊ້ໄດ້ດີ, ສໍາລັບການຍົກຕົວຢ່າງ, ກັບ wardrobe, ແຕ່ບໍ່ແມ່ນກັບຜະລິດຕະພັນຊອບແວ. ມີແນວຄວາມຄິດຂອງ inferiority ແລະດີກວ່າໃນບາງສິ່ງບາງຢ່າງ. ຂ້າພະເຈົ້າສາມາດເວົ້າໄດ້ຢ່າງແທ້ຈິງວ່າ ReserFS v3 ປະຈຸບັນແມ່ນຕ່ໍາກວ່າ Reiser4 ໃນທຸກສິ່ງທຸກຢ່າງ, ແຕ່ໃນບາງປະເພດຂອງວຽກມັນດີກວ່າ FSs ອື່ນໆທັງຫມົດ.

ທ່ານຮູ້ກ່ຽວກັບການພັດທະນາຂອງ FS Tux3 ແລະ HAMMER/HAMMER2 (FS ສໍາລັບ DragonFly BSD) ບໍ?

ແມ່ນແລ້ວ, ພວກເຮົາຮູ້. ໃນ Tux3 ຂ້າພະເຈົ້າເຄີຍສົນໃຈກັບເຕັກໂນໂລຢີຂອງພາບຖ່າຍຂອງພວກເຂົາ (ອັນທີ່ເອີ້ນວ່າ "ຕົວຊີ້ສະບັບ"), ແຕ່ໃນ Reiser4 ສ່ວນຫຼາຍພວກເຮົາຈະໄປໃນເສັ້ນທາງທີ່ແຕກຕ່າງກັນ. ຂ້າພະເຈົ້າໄດ້ຄິດກ່ຽວກັບການສະຫນັບສະຫນູນພາບຖ່າຍເປັນເວລາດົນນານແລະຍັງບໍ່ທັນໄດ້ຕັດສິນໃຈທີ່ຈະປະຕິບັດພວກມັນສໍາລັບປະລິມານ Reiser4 ງ່າຍໆ. ຄວາມ​ຈິງ​ແລ້ວ​ແມ່ນ​ວ່າ​ເຕັກ​ນິກ​ການ​ໂຕ້​ຕອບ​ກະ​ສານ​ອ້າງ​ອີງ "ຂີ້​ກຽດ" ທີ່​ສະ​ເໜີ​ໂດຍ Ohad Rodeh ພຽງ​ແຕ່​ໃຊ້​ໄດ້​ກັບ​ຕົ້ນ​ໄມ້ B. ພວກເຮົາບໍ່ມີພວກມັນ. ສໍາລັບໂຄງສ້າງຂໍ້ມູນເຫຼົ່ານັ້ນທີ່ຖືກນໍາໃຊ້ໃນ Reiesr4, ຕົວນັບ "lazy" ບໍ່ໄດ້ຖືກກໍານົດ - ເພື່ອແນະນໍາພວກເຂົາ, ມັນຈໍາເປັນຕ້ອງແກ້ໄຂບັນຫາ algorithmic ບາງຢ່າງ, ເຊິ່ງບໍ່ມີໃຜໄດ້ປະຕິບັດເທື່ອ.

ອີງຕາມການ HAMMER: ຂ້າພະເຈົ້າໄດ້ອ່ານບົດຄວາມຈາກຜູ້ສ້າງ. ບໍ່​ຫນ້າ​ສົນ​ໃຈ. ອີກເທື່ອຫນຶ່ງ, B-trees. ໂຄງສ້າງຂໍ້ມູນນີ້ລ້າສະໄຫມຢ່າງສິ້ນຫວັງ. ພວກເຮົາປະຖິ້ມມັນໃນສະຕະວັດທີ່ຜ່ານມາ.

ທ່ານປະເມີນຄວາມຕ້ອງການທີ່ເພີ່ມຂຶ້ນສໍາລັບກຸ່ມເຄືອຂ່າຍ FSs ເຊັ່ນ CephFS/GlusterFS/etc ແນວໃດ? ຄວາມຕ້ອງການນີ້ຫມາຍເຖິງການປ່ຽນແປງບູລິມະສິດຂອງນັກພັດທະນາໄປສູ່ເຄືອຂ່າຍ FS ແລະຄວາມສົນໃຈບໍ່ພຽງພໍກັບ FS ທ້ອງຖິ່ນບໍ?

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

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

ມັນສົມເຫດສົມຜົນແນວໃດໃນຫຼັກການທີ່ຈະປະຕິບັດລະບົບໄຟລ໌ເຄືອຂ່າຍໃນພື້ນທີ່ແກ່ນແທນທີ່ຈະຢູ່ໃນພື້ນທີ່ຜູ້ໃຊ້?

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

ຫຼັງຈາກນັ້ນ, stack ເຄືອຂ່າຍໃຊ້ເວລາຫຼາຍກວ່າ (ແລະ, ດັ່ງທີ່ພວກເຮົາຮູ້, ມັນຖືກປະຕິບັດຢູ່ໃນພື້ນທີ່ kernel). ຕໍ່ໄປ, server node ໄດ້ຮັບແພັກເກັດທີ່ມີຂໍ້ມູນຫຼື metadata ແລະສັ່ງໃຫ້ໂມດູນການເກັບຮັກສາ backend (i.e., FS ທ້ອງຖິ່ນທີ່ເຮັດວຽກຢູ່ໃນພື້ນທີ່ແກ່ນ) ເພື່ອບັນທຶກສິ່ງທັງຫມົດນີ້. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຫຼຸດລົງຄໍາຖາມທີ່ໂມດູນ "ສົ່ງ" ແລະ "ຮັບ" ຄວນເຮັດວຽກ. ຖ້າໂມດູນໃດ ໜຶ່ງ ແລ່ນຢູ່ໃນພື້ນທີ່ຜູ້ໃຊ້, ນີ້ຈະເຮັດໃຫ້ເກີດການສະຫຼັບສະພາບການຢ່າງຫລີກລ້ຽງ (ເນື່ອງຈາກຄວາມຕ້ອງການທີ່ຈະໃຊ້ການບໍລິການແກ່ນ). ຈໍານວນຂອງສະຫວິດດັ່ງກ່າວແມ່ນຂຶ້ນກັບລາຍລະອຽດການປະຕິບັດ.

ຖ້າ​ຫາກ​ວ່າ​ມີ​ສະ​ຫຼັບ​ດັ່ງ​ກ່າວ​ຈໍາ​ນວນ​ຫຼາຍ​, ຫຼັງ​ຈາກ​ນັ້ນ​ການ​ຜ່ານ​ການ​ເກັບ​ຮັກ​ສາ (ປະ​ສິດ​ທິ​ພາບ I/O​) ຈະ​ຫຼຸດ​ລົງ​. ຖ້າບ່ອນເກັບຂໍ້ມູນ backend ຂອງທ່ານປະກອບດ້ວຍແຜ່ນຊ້າ, ທ່ານຈະບໍ່ສັງເກດເຫັນການຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ແຕ່ຖ້າທ່ານມີຮາດດິດໄວ (SSD, NVRAM, ແລະອື່ນໆ), ຫຼັງຈາກນັ້ນການປ່ຽນສະພາບການກາຍເປັນ "ຄໍຂວດ" ແລະ, ໂດຍການປະຫຍັດການປ່ຽນສະພາບການ, ການປະຕິບັດສາມາດເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ວິທີການມາດຕະຖານເພື່ອປະຫຍັດເງິນແມ່ນການຍ້າຍໂມດູນເຂົ້າໄປໃນພື້ນທີ່ເມັດ. ຕົວຢ່າງ, ພວກເຮົາພົບວ່າການເຄື່ອນຍ້າຍເຄື່ອງແມ່ຂ່າຍ 9p ຈາກ QEMU ໄປຫາແກ່ນໃນເຄື່ອງໂຮດເຮັດໃຫ້ການປະຕິບັດ VirtFS ເພີ່ມຂຶ້ນສາມເທົ່າ.

ນີ້, ແນ່ນອນ, ບໍ່ແມ່ນເຄືອຂ່າຍ FS, ແຕ່ມັນສະທ້ອນໃຫ້ເຫັນເຖິງຄວາມສໍາຄັນຂອງສິ່ງຕ່າງໆຢ່າງສົມບູນ. ຂໍ້ເສຍຂອງການເພີ່ມປະສິດທິພາບນີ້ແມ່ນບັນຫາການພົກພາ. ສໍາລັບບາງຄົນ, ອັນສຸດທ້າຍອາດຈະສໍາຄັນ. ຕົວຢ່າງ, GlusterFS ບໍ່ມີໂມດູນໃນ kernel ເລີຍ. ຂໍຂອບໃຈກັບສິ່ງນີ້, ຕອນນີ້ມັນເຮັດວຽກຢູ່ໃນຫຼາຍເວທີ, ລວມທັງ NetBSD.

ແນວຄວາມຄິດໃດທີ່ FSs ທ້ອງຖິ່ນສາມາດກູ້ຢືມຈາກເຄືອຂ່າຍແລະໃນທາງກັບກັນ?

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

ແຕ່ FSs ທ້ອງຖິ່ນມີຫຼາຍທີ່ຈະຮຽນຮູ້ຈາກເຄືອຂ່າຍ. ກ່ອນອື່ນ ໝົດ, ທ່ານຄວນຮຽນຮູ້ຈາກພວກເຂົາວິທີການລວບລວມປະລິມານຢ່າງມີເຫດຜົນໃນລະດັບສູງ. ໃນປັດຈຸບັນອັນທີ່ເອີ້ນວ່າ ລະບົບໄຟລ໌ທ້ອງຖິ່ນ "ຂັ້ນສູງ" ລວບລວມປະລິມານຢ່າງມີເຫດຜົນສະເພາະໂດຍໃຊ້ເຕັກໂນໂລຢີ "ອຸປະກອນ virtual" ທີ່ຢືມມາຈາກ LVM (ການລະເມີດການຕິດເຊື້ອແບບດຽວກັນທີ່ໄດ້ຖືກປະຕິບັດຄັ້ງທໍາອິດໃນ ZFS). ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ການແປທີ່ຢູ່ virtual (ຕົວເລກບລັອກ) ເຂົ້າໄປໃນຕົວຈິງແລະກັບຄືນໄປບ່ອນແມ່ນເກີດຂື້ນໃນລະດັບຕໍ່າ (i.e., ຫຼັງຈາກລະບົບໄຟລ໌ໄດ້ອອກຄໍາຮ້ອງຂໍ I / O).

ກະລຸນາຮັບຊາບວ່າການເພີ່ມ ແລະເອົາອຸປະກອນອອກໃສ່ປະລິມານຢ່າງມີເຫດຜົນ (ບໍ່ແມ່ນກະຈົກ) ຈັດວາງຢູ່ໃນຊັ້ນບຼັອກເຮັດໃຫ້ບັນຫາທີ່ຜູ້ສະໜອງ “ຄຸນສົມບັດ” ດັ່ງກ່າວມິດງຽບຢູ່. ຂ້ອຍເວົ້າກ່ຽວກັບການແບ່ງສ່ວນໃນອຸປະກອນທີ່ແທ້ຈິງ, ເຊິ່ງສາມາດບັນລຸຄຸນຄ່າທີ່ມະຫັດສະຈັນ, ໃນຂະນະທີ່ຢູ່ໃນອຸປະກອນ virtual ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ. ຢ່າງໃດກໍຕາມ, ມີຄົນຈໍານວນຫນ້ອຍທີ່ມີຄວາມສົນໃຈໃນອຸປະກອນ virtual: ທຸກຄົນມີຄວາມສົນໃຈໃນສິ່ງທີ່ເກີດຂຶ້ນໃນອຸປະກອນທີ່ແທ້ຈິງຂອງທ່ານ. ແຕ່ ZFS ຄ້າຍຄື FS (ເຊັ່ນດຽວກັນກັບ FS ໃດໆທີ່ສົມທົບກັບ LVM) ເຮັດວຽກພຽງແຕ່ກັບອຸປະກອນ virtual disk (ຈັດສັນທີ່ຢູ່ virtual disk ຈາກບັນດາຟຣີ, defragment ອຸປະກອນ virtual ເຫຼົ່ານີ້, ແລະອື່ນໆ). ແລະພວກເຂົາບໍ່ຮູ້ວ່າຈະເກີດຫຍັງຂຶ້ນຢູ່ໃນອຸປະກອນຕົວຈິງ!

ຕອນນີ້ຈິນຕະນາການວ່າທ່ານມີສູນ fragmentation ໃນອຸປະກອນ virtual (ນັ້ນແມ່ນ, ທ່ານມີພຽງແຕ່ຫນຶ່ງຂອບເຂດຂະຫນາດໃຫຍ່ທີ່ມີຊີວິດຢູ່), ທ່ານເພີ່ມແຜ່ນໃນປະລິມານຢ່າງມີເຫດຜົນຂອງທ່ານ, ແລະຫຼັງຈາກນັ້ນເອົາແຜ່ນ Random ອື່ນອອກຈາກປະລິມານຢ່າງມີເຫດຜົນຂອງທ່ານແລະຫຼັງຈາກນັ້ນ rebalance. ແລະຫຼາຍເທື່ອ. ມັນບໍ່ຍາກທີ່ຈະຈິນຕະນາການວ່າໃນອຸປະກອນສະເໝືອນຈິງເຈົ້າຈະຍັງມີຊີວິດຢູ່ຄືກັນ, ແຕ່ໃນອຸປະກອນຕົວຈິງທ່ານຈະບໍ່ເຫັນຫຍັງດີ.

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

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

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

ບັນຫາອີກອັນຫນຶ່ງແມ່ນຢູ່ໃນການລໍຖ້າອັນທີ່ເອີ້ນວ່າ. ລະບົບໄຟລ໌ "Write-Anywhere" (ນີ້ຍັງປະກອບມີ Reiser4, ຖ້າທ່ານລະບຸຮູບແບບການເຮັດທຸລະກໍາທີ່ເຫມາະສົມໃນລະຫວ່າງການຕິດຕັ້ງ). ລະບົບໄຟລ໌ດັ່ງກ່າວຕ້ອງສະຫນອງເຄື່ອງມື defragmentation ທີ່ບໍ່ເຄີຍມີມາກ່ອນໃນພະລັງງານຂອງພວກເຂົາ. ແລະຜູ້ຈັດການລະດັບສຽງຕ່ໍາບໍ່ໄດ້ຊ່ວຍຢູ່ທີ່ນີ້, ແຕ່ພຽງແຕ່ໄດ້ຮັບໃນທາງ. ຄວາມຈິງແລ້ວແມ່ນວ່າມີຜູ້ຈັດການດັ່ງກ່າວ, FS ຂອງທ່ານຈະເກັບຮັກສາແຜນທີ່ຂອງທ່ອນໄມ້ທີ່ບໍ່ເສຍຄ່າຂອງອຸປະກອນດຽວ - virtual ຫນຶ່ງ. ດັ່ງນັ້ນ, ທ່ານພຽງແຕ່ສາມາດ defragment ອຸປະກອນ virtual. ນີ້ຫມາຍຄວາມວ່າ defragmenter ຂອງທ່ານຈະເຮັດວຽກເປັນເວລາດົນນານ, ຍາວໃນຊ່ອງດຽວຂະຫນາດໃຫຍ່ຂອງທີ່ຢູ່ virtual.

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

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

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

ຫຼັງຈາກນັ້ນ, ທ່ານເພີ່ມອຸປະກອນ C ໃນປະລິມານຂອງທ່ານ, ແລະສຸດທ້າຍ rollback ລະບົບຂອງທ່ານເພື່ອ snapshot S. ຄໍາຖາມ: ຈໍານວນໄຟລ໌ແລະອຸປະກອນມີປະລິມານຢ່າງມີເຫດຜົນຫຼັງຈາກ rollback ກັບ S? ມັນຈະມີ 100 ໄຟລ໌, ຕາມທີ່ເຈົ້າອາດຈະຄາດເດົາໄດ້, ແຕ່ຈະມີ 3 ອຸປະກອນ - ເຫຼົ່ານີ້ແມ່ນອຸປະກອນດຽວກັນ A, B ແລະ C, ເຖິງແມ່ນວ່າໃນເວລາທີ່ snapshot ໄດ້ຖືກສ້າງຂື້ນມີພຽງແຕ່ສອງອຸປະກອນໃນລະບົບ (A ແລະ B. ). ການປະຕິບັດການເພີ່ມອຸປະກອນ C ບໍ່ໄດ້ກັບຄືນ, ແລະຖ້າຫາກວ່າທ່ານໃນປັດຈຸບັນເອົາອຸປະກອນ C ອອກຈາກຄອມພິວເຕີ, ມັນຈະເສຍຫາຍຂໍ້ມູນຂອງທ່ານ, ສະນັ້ນກ່ອນທີ່ຈະລຶບທ່ານຈະຕ້ອງທໍາອິດປະຕິບັດການລາຄາແພງເພື່ອເອົາອຸປະກອນອອກຈາກປະລິມານເຫດຜົນ rebalance, ເຊິ່ງ. ຈະກະແຈກກະຈາຍຂໍ້ມູນທັງໝົດຈາກອຸປະກອນ C ໄປໃສ່ອຸປະກອນ A ແລະ B. ແຕ່ຖ້າ FS ຂອງທ່ານຮອງຮັບການຖ່າຍພາບທົ່ວໂລກ, ການປັບສົມດຸນດັ່ງກ່າວຈະບໍ່ຈຳເປັນ, ແລະ ຫຼັງຈາກມ້ວນຄືນໄປຫາ S ທັນທີ, ທ່ານສາມາດເອົາອຸປະກອນ C ອອກຈາກຄອມພິວເຕີໄດ້ຢ່າງປອດໄພ.

ດັ່ງນັ້ນ, ການຖ່າຍຮູບທົ່ວໂລກແມ່ນດີເພາະວ່າພວກມັນຊ່ວຍໃຫ້ທ່ານສາມາດຫລີກລ່ຽງການໂຍກຍ້າຍຄ່າໃຊ້ຈ່າຍ (ເພີ່ມ) ຂອງອຸປະກອນຈາກປະລິມານຢ່າງມີເຫດຜົນ (ເຖິງປະລິມານຢ່າງມີເຫດຜົນ) ທີ່ມີຂໍ້ມູນຈໍານວນຫລາຍ (ແນ່ນອນ, ຖ້າທ່ານຈື່ "snapshot" ລະບົບຂອງທ່ານ. ໃນ​ເວ​ລາ​ທີ່​ເຫມາະ​ສົມ). ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າການສ້າງພາບຖ່າຍແລະການມ້ວນຄືນລະບົບໄຟລ໌ໃຫ້ພວກເຂົາເປັນການດໍາເນີນງານທັນທີ. ຄໍາຖາມອາດຈະເກີດຂື້ນ: ມັນເປັນໄປໄດ້ແນວໃດທີ່ຈະກັບຄືນການດໍາເນີນງານໃນປະລິມານຢ່າງມີເຫດຜົນທີ່ໃຊ້ເວລາສາມມື້? ແຕ່​ເປັນ​ໄປ​ໄດ້! ສະໜອງໃຫ້ລະບົບໄຟລ໌ຂອງທ່ານຖືກອອກແບບຢ່າງຖືກຕ້ອງ. ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ມາ​ເຖິງ​ກັບ​ຄວາມ​ຄິດ​ຂອງ "ຮູບ​ພາບ 3D​" ດັ່ງ​ກ່າວ​ສາມ​ປີ​ກ່ອນ​ຫນ້າ​ນີ້​, ແລະ​ໃນ​ປີ​ທີ່​ຜ່ານ​ມາ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຮັບ​ສິດ​ທິ​ບັດ​ເຕັກ​ນິກ​ການ​ນີ້​.

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

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

ຕົວຢ່າງຂອງ algorithms ທີ່ຂີ້ຮ້າຍຢ່າງແທ້ຈິງແມ່ນຕົວແປ DHT ໃນລະບົບໄຟລ໌ GlusterFS ແລະອັນທີ່ເອີ້ນວ່າແຜນທີ່ CRUSH ໃນລະບົບໄຟລ໌ Ceph. ບໍ່ມີ algorithms ໃດໆທີ່ຂ້ອຍເຫັນພໍໃຈຂ້ອຍໃນແງ່ຂອງຄວາມລຽບງ່າຍແລະການຂະຫຍາຍທີ່ດີ. ສະນັ້ນຂ້າພະເຈົ້າຕ້ອງຈື່ຈໍາພຶດຊະຄະນິດແລະ invent ທຸກສິ່ງທຸກຢ່າງດ້ວຍຕົນເອງ. ໃນປີ 2015, ໃນຂະນະທີ່ທົດລອງກັບ bundle ຫຼາຍກວ່າຟັງຊັນ hash, ຂ້າພະເຈົ້າໄດ້ມາກັບແລະສິດທິບັດບາງສິ່ງບາງຢ່າງທີ່ເຫມາະສົມກັບຂ້າພະເຈົ້າ. ຕອນນີ້ຂ້ອຍສາມາດເວົ້າໄດ້ວ່າຄວາມພະຍາຍາມທີ່ຈະປະຕິບັດທັງຫມົດນີ້ປະສົບຜົນສໍາເລັດ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ເຫັນ​ບັນ​ຫາ​ໃດໆ​ກ່ຽວ​ກັບ​ການ​ຂະ​ຫຍາຍ​ຕົວ​ໃນ​ວິ​ທີ​ການ​ໃຫມ່​.

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

ການປ່ຽນແປງໃນລະບົບຍ່ອຍອຸປະກອນຂອງ kernel block (ຕົວຢ່າງ, ຮູບລັກສະນະຂອງ blk-mq) ມີຜົນກະທົບແນວໃດຕໍ່ຄວາມຕ້ອງການຂອງການປະຕິບັດ FS?

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

ການປະກົດຕົວຂອງສື່ປະເພດໃຫມ່ (ຕົວຢ່າງ, SMR, ຫຼືສະຖານທີ່ທົ່ວໆໄປຂອງ SSDs) ຫມາຍເຖິງສິ່ງທ້າທາຍໃຫມ່ພື້ນຖານສໍາລັບການອອກແບບລະບົບໄຟລ໌ບໍ?

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

ມີຈັກຄົນໃນປັດຈຸບັນທີ່ເຮັດວຽກກັບລະຫັດ Reiser4 ນອກຈາກທ່ານ?

ໜ້ອຍກວ່າທີ່ຂ້ອຍຕ້ອງການ, ແຕ່ຂ້ອຍບໍ່ປະສົບກັບການຂາດແຄນຊັບພະຍາກອນຢ່າງຮ້າຍແຮງ. ຂ້ອຍພໍໃຈກັບຈັງຫວະການພັດທະນາຂອງ Reiser4 ຫຼາຍກວ່າ. ຂ້ອຍຈະບໍ່ "ຂັບມ້າ" - ນີ້ບໍ່ແມ່ນພື້ນທີ່ທີ່ຖືກຕ້ອງ. ນີ້, "ຖ້າທ່ານຂັບລົດຢ່າງງຽບໆ, ເຈົ້າຈະສືບຕໍ່ໄປ!" ລະບົບໄຟລ໌ທີ່ທັນສະໄຫມແມ່ນລະບົບຍ່ອຍ kernel ທີ່ສັບສົນທີ່ສຸດ, ການຕັດສິນໃຈອອກແບບທີ່ບໍ່ຖືກຕ້ອງສາມາດຍົກເລີກການເຮັດວຽກຂອງມະນຸດຫຼາຍປີຕໍ່ມາ.

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

ມີບໍລິສັດໃດສະແດງຄວາມເຕັມໃຈທີ່ຈະສະຫນັບສະຫນູນການພັດທະນາຂອງ Reiser4?

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

ຄຸນສົມບັດໃດທີ່ຂາດຫາຍໄປຈາກ Reiser4?

ບໍ່ມີຟັງຊັນ "ປັບຂະຫນາດ" ສໍາລັບປະລິມານທີ່ງ່າຍດາຍ, ຄ້າຍຄືກັນກັບທີ່ພົບໃນ ReiserFS (v3). ນອກຈາກນັ້ນ, ການດໍາເນີນງານໄຟລ໌ທີ່ມີທຸງ DIRECT_IO ຈະບໍ່ເຈັບປວດ. ຕໍ່ໄປ, ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະສາມາດແຍກປະລິມານເຂົ້າໄປໃນ "ປະລິມານຍ່ອຍ semantic", ທີ່ບໍ່ມີຂະຫນາດຄົງທີ່, ແລະທີ່ສາມາດຕິດຕັ້ງເປັນປະລິມານເອກະລາດ. ບັນຫາເຫຼົ່ານີ້ແມ່ນດີສໍາລັບຜູ້ເລີ່ມຕົ້ນທີ່ຕ້ອງການທົດລອງໃຊ້ "ສິ່ງທີ່ແທ້ຈິງ."

ແລະສຸດທ້າຍ, ຂ້າພະເຈົ້າຢາກຈະມີປະລິມານທີ່ມີເຫດຜົນຂອງເຄືອຂ່າຍທີ່ມີການປະຕິບັດແລະການບໍລິຫານທີ່ງ່າຍດາຍ (ສູດການຄິດໄລ່ທີ່ທັນສະໄຫມອະນຸຍາດໃຫ້ນີ້). ແຕ່ສິ່ງທີ່ Reiser4 ບໍ່ເຄີຍມີແນ່ນອນແມ່ນ RAID-Z, scrubs, free space caches, 128-bit variables and other nonsense marketing that comes up against the backdrop of a shortage of idea among developers of some file systems .

ທຸກສິ່ງທຸກຢ່າງທີ່ອາດຈະຕ້ອງການຖືກປະຕິບັດໂດຍ plugins?

ຖ້າພວກເຮົາເວົ້າພຽງແຕ່ໃນແງ່ຂອງການໂຕ້ຕອບແລະ plugins (ໂມດູນ) ທີ່ປະຕິບັດພວກມັນ, ຫຼັງຈາກນັ້ນບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງ. ແຕ່ຖ້າທ່ານຍັງແນະນໍາຄວາມສໍາພັນໃນການໂຕ້ຕອບເຫຼົ່ານີ້, ຫຼັງຈາກນັ້ນ, ໃນບັນດາສິ່ງອື່ນໆ, ທ່ານຈະມີແນວຄວາມຄິດຂອງ polymorphisms ສູງກວ່າ, ທີ່ທ່ານສາມາດໄດ້ຮັບແລ້ວ. ຈິນຕະນາການວ່າທ່ານ froze ລະບົບ runtime ຮັດກຸມວັດຖຸ, ປ່ຽນຄ່າຂອງຕົວຊີ້ຄໍາແນະນໍາເພື່ອຊີ້ໄປຫາ plugin ອື່ນທີ່ປະຕິບັດການໂຕ້ຕອບ X ດຽວກັນ, ແລະຫຼັງຈາກນັ້ນ unfroze ລະບົບເພື່ອໃຫ້ມັນດໍາເນີນການຕໍ່ໄປ.

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

ດັ່ງນັ້ນ, ດ້ວຍຄວາມຊ່ອຍເຫລືອຂອງ plugins ແລະ polymorphisms ສູງດັ່ງກ່າວ, ທ່ານສາມາດອະທິບາຍລັກສະນະທີ່ຮູ້ຈັກ, ເຊັ່ນດຽວກັນກັບ "ຄາດຄະເນ" ທີ່ບໍ່ເຄີຍໄດ້ກ່າວເຖິງ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ພິ​ສູດ​ຢ່າງ​ເຂັ້ມ​ງວດ​ນີ້​, ແຕ່​ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ບໍ່​ຮູ້​ເຖິງ​ຕົວ​ຢ່າງ​ທີ່​ກົງ​ກັນ​ຂ້າມ​. ໂດຍທົ່ວໄປ, ຄໍາຖາມນີ້ໄດ້ເຕືອນຂ້ອຍກ່ຽວກັບ "ໂຄງການ Erlangen" ຂອງ Felix Klein. ໃນເວລາຫນຶ່ງລາວໄດ້ພະຍາຍາມເປັນຕົວແທນຂອງເລຂາຄະນິດທັງຫມົດເປັນສາຂາຂອງ algebra (ໂດຍສະເພາະ, ທິດສະດີກຸ່ມ).

ຕອນນີ້ໄປຫາຄໍາຖາມຕົ້ນຕໍ - ສິ່ງຕ່າງໆຈະໄປກັບການສົ່ງເສີມ Reiser4 ແນວໃດ? ມີສິ່ງພິມໃດໆກ່ຽວກັບສະຖາປັດຕະຍະກໍາຂອງລະບົບໄຟລ໌ນີ້ທີ່ເຈົ້າເວົ້າກ່ຽວກັບການສໍາພາດຫຼ້າສຸດບໍ? ຄຳຖາມນີ້ມີຄວາມກ່ຽວຂ້ອງແນວໃດຈາກທັດສະນະຂອງເຈົ້າ?

ໂດຍ​ທົ່ວ​ໄປ, ພວກ​ເຮົາ​ໄດ້​ຮ້ອງ​ຂໍ​ໃຫ້​ມີ​ການ​ລວມ​ຢູ່​ໃນ​ສາ​ຂາ​ຕົ້ນ​ຕໍ​ສໍາ​ລັບ​ສາມ​ປີ​. ຄໍາເຫັນສຸດທ້າຍຂອງ Reiser ໃນກະທູ້ສາທາລະນະທີ່ຄໍາຮ້ອງຂໍດຶງໄດ້ຖືກເຮັດຍັງຄົງບໍ່ມີຄໍາຕອບ. ດັ່ງນັ້ນຄໍາຖາມເພີ່ມເຕີມທັງຫມົດບໍ່ແມ່ນສໍາລັບພວກເຮົາ. ຂ້າພະເຈົ້າສ່ວນບຸກຄົນບໍ່ເຂົ້າໃຈວ່າເປັນຫຍັງພວກເຮົາຈໍາເປັນຕ້ອງ "ລວມ" ເຂົ້າໄປໃນລະບົບປະຕິບັດການສະເພາະ. ໃນ Linux, ແສງສະຫວ່າງບໍ່ໄດ້ converge ຄ້າຍຄື wedge. ດັ່ງນັ້ນ, ມີ repository ແຍກຕ່າງຫາກເຊິ່ງຈະມີສາຂາ-ports ຫຼາຍສໍາລັບ OSes ທີ່ແຕກຕ່າງກັນ. ຜູ້ທີ່ຕ້ອງການມັນສາມາດ clone ທ່າເຮືອທີ່ສອດຄ້ອງກັນແລະເຮັດສິ່ງທີ່ທ່ານຕ້ອງການກັບມັນ (ແນ່ນອນ, ພາຍໃນໃບອະນຸຍາດ). ແລ້ວ, ຖ້າໃຜຜູ້ຫນຶ່ງບໍ່ຕ້ອງການມັນ, ມັນບໍ່ແມ່ນບັນຫາຂອງຂ້ອຍ. ໃນຈຸດນີ້, ຂ້າພະເຈົ້າສະເຫນີໃຫ້ພິຈາລະນາຄໍາຖາມຂອງ "ການສົ່ງເສີມການເຂົ້າໄປໃນ Linux kernel ຕົ້ນຕໍ" ຕາມການຕົກລົງ.

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

ມີຫຍັງໃຫມ່ໃນ Reiser4 ໃນໄລຍະສອງສາມປີຜ່ານມາ?

ຄວາມໝັ້ນຄົງທີ່ລໍຄອຍມາດົນນານໃນທີ່ສຸດກໍກາຍເປັນຈິງ. ຫນຶ່ງໃນສຸດທ້າຍທີ່ຈະປາກົດແມ່ນ bug ທີ່ນໍາໄປສູ່ການ "ຍົກເລີກ" ໄດເລກະທໍລີ. ຄວາມຫຍຸ້ງຍາກແມ່ນວ່າມັນພຽງແຕ່ປາກົດຢູ່ກັບພື້ນຫລັງຂອງການ collision hash ຊື່ແລະມີສະຖານທີ່ສະເພາະໃດຫນຶ່ງຂອງການບັນທຶກໄດເລກະທໍລີໃນ node ຕົ້ນໄມ້. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າຍັງບໍ່ສາມາດແນະນໍາ Reiser4 ສໍາລັບການຜະລິດ: ສໍາລັບນີ້, ທ່ານຈໍາເປັນຕ້ອງເຮັດວຽກບາງຢ່າງທີ່ມີການໂຕ້ຕອບຢ່າງຫ້າວຫັນກັບຜູ້ບໍລິຫານລະບົບການຜະລິດ.

ພວກເຮົາສຸດທ້າຍໄດ້ຈັດການເພື່ອປະຕິບັດແນວຄວາມຄິດອັນຍາວນານຂອງພວກເຮົາ - ຮູບແບບການເຮັດທຸລະກໍາທີ່ແຕກຕ່າງກັນ. ກ່ອນຫນ້ານີ້, Reiser4 ພຽງແຕ່ແລ່ນຫນຶ່ງແບບ hardcoded Macdonald-Reiser. ນີ້ສ້າງບັນຫາການອອກແບບ. ໂດຍສະເພາະ, ພາບຖ່າຍແມ່ນເປັນໄປບໍ່ໄດ້ໃນຮູບແບບການເຮັດທຸລະກໍາດັ່ງກ່າວ - ພວກມັນຈະຖືກທໍາລາຍໂດຍອົງປະກອບປະລໍາມະນູທີ່ເອີ້ນວ່າ "OVERWRITE SET". Reiser4 ປະຈຸບັນສະຫນັບສະຫນູນສາມຮູບແບບການເຮັດທຸລະກໍາ. ໃນຫນຶ່ງຂອງພວກເຂົາ (Write-Anywhere), ອົງປະກອບປະລໍາມະນູ OVERWRITE SET ປະກອບມີພຽງແຕ່ຫນ້າລະບົບ (ຮູບພາບຂອງແຜ່ນບິດ, ແລະອື່ນໆ), ເຊິ່ງບໍ່ສາມາດ "ຖ່າຍຮູບ" (ບັນຫາໄກ່ແລະໄຂ່).

ດັ່ງ​ນັ້ນ​ຮູບ​ພາບ​ໃນ​ປັດ​ຈຸ​ບັນ​ສາ​ມາດ​ຮັບ​ຮູ້​ໃນ​ວິ​ທີ​ການ​ທີ່​ດີ​ທີ່​ສຸດ​. ໃນຮູບແບບການເຮັດທຸລະກໍາອື່ນ, ຫນ້າທີ່ດັດແກ້ທັງຫມົດໄປພຽງແຕ່ OVERWRITE SET (ນັ້ນແມ່ນ, ມັນເປັນສິ່ງຈໍາເປັນທີ່ບໍລິສຸດວາລະສານ). ຮູບແບບນີ້ແມ່ນສໍາລັບຜູ້ທີ່ຈົ່ມກ່ຽວກັບການແຕກແຍກຢ່າງໄວວາຂອງ Reiser4 partitions. ໃນ​ປັດ​ຈຸ​ບັນ​ໃນ​ຮູບ​ແບບ​ນີ້​ການ​ແບ່ງ​ປັນ​ຂອງ​ທ່ານ​ຈະ fragment ບໍ່​ໄວ​ກ​່​ວາ​ກັບ ReiserFS (v3​)​. ທັງສາມຕົວແບບທີ່ມີຢູ່, ດ້ວຍການຈອງບາງ, ຮັບປະກັນການທໍາງານຂອງປະລໍາມະນູ, ແຕ່ແບບຈໍາລອງທີ່ມີການສູນເສຍປະລໍາມະນູແລະຮັກສາພຽງແຕ່ຄວາມສົມບູນຂອງສ່ວນຍັງສາມາດເປັນປະໂຫຍດ. ຮູບແບບດັ່ງກ່າວສາມາດເປັນປະໂຫຍດສໍາລັບທຸກປະເພດຂອງຄໍາຮ້ອງສະຫມັກ (ຖານຂໍ້ມູນ, ແລະອື່ນໆ), ເຊິ່ງໄດ້ປະຕິບັດບາງຫນ້າທີ່ເຫຼົ່ານີ້ແລ້ວ. ມັນງ່າຍຫຼາຍທີ່ຈະເພີ່ມຕົວແບບເຫຼົ່ານີ້ໃສ່ Reiser4, ແຕ່ຂ້ອຍບໍ່ໄດ້ເຮັດມັນ, ເພາະວ່າບໍ່ມີໃຜຖາມຂ້ອຍ, ແລະຂ້ອຍກໍ່ບໍ່ຕ້ອງການມັນ.

ການກວດສອບເມຕາເດຕາປະກົດຂຶ້ນ ແລະເມື່ອບໍ່ດົນມານີ້ຂ້າພະເຈົ້າໄດ້ເສີມພວກມັນດ້ວຍກະຈົກ "ເສດຖະກິດ" (ອຸປະກອນທີ່ຍັງບໍ່ຄົງທີ່). ຖ້າ checksum ຂອງ block ໃດລົ້ມເຫລວ, Reiser4 ຈະອ່ານບລັອກທີ່ສອດຄ້ອງກັນທັນທີຈາກອຸປະກອນ replica. ໃຫ້ສັງເກດວ່າ ZFS ແລະ Btrfs ບໍ່ສາມາດເຮັດໄດ້: ການອອກແບບບໍ່ອະນຸຍາດໃຫ້ມັນ. ຢູ່ທີ່ນັ້ນ, ທ່ານຕ້ອງດໍາເນີນຂະບວນການສະແກນພື້ນຫລັງພິເສດທີ່ເອີ້ນວ່າ "scrub" ແລະລໍຖ້າມັນໄປຫາຕັນທີ່ມີບັນຫາ. ນັກຂຽນໂປລແກລມເອີ້ນເຫດການດັ່ງກ່າວເປັນຕົວເລກ "crutches."

ແລະສຸດທ້າຍ, ປະລິມານທີ່ມີເຫດຜົນຫຼາຍຢ່າງໄດ້ປະກົດຕົວ, ສະເຫນີທຸກສິ່ງທຸກຢ່າງທີ່ ZFS, Btrfs, block layer, ເຊັ່ນດຽວກັນກັບການປະສົມປະສານ FS+LVM ໃນຫຼັກການບໍ່ສາມາດສະຫນອງ - ຂະຫນານຂະຫນານ, O(1) ທີ່ຢູ່ disk allocator, ການເຄື່ອນຍ້າຍຂໍ້ມູນໂປ່ງໃສລະຫວ່າງ subvolumes. ສຸດທ້າຍຍັງມີການໂຕ້ຕອບຜູ້ໃຊ້. ຕອນນີ້ທ່ານສາມາດຍ້າຍຂໍ້ມູນທີ່ຮ້ອນທີ່ສຸດໄປໃສ່ໄດທີ່ມີປະສິດຕິພາບສູງສຸດໃນປະລິມານຂອງທ່ານໄດ້ຢ່າງງ່າຍດາຍ.

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

ເຖິງຕອນນັ້ນຂ້ອຍສາມາດປະຕິບັດແນວຄວາມຄິດຂອງຂ້ອຍໄດ້ 10 ເປີເຊັນຢ່າງໃດກໍ່ຕາມ, ຂ້ອຍໄດ້ປະສົບຜົນສໍາເລັດໃນສິ່ງທີ່ຂ້ອຍຖືວ່າເປັນສິ່ງທີ່ຍາກທີ່ສຸດ - ການເຊື່ອມຕໍ່ປະລິມານຢ່າງມີເຫດຜົນກັບຂັ້ນຕອນ flash ທີ່ປະຕິບັດການປະຕິບັດທັງຫມົດທີ່ເລື່ອນລົງໃນ reiser4. ທັງໝົດນີ້ຍັງຢູ່ໃນສາຂາ “format41” ທົດລອງ.

Reiser4 ຜ່ານ xfstests ບໍ?

ຢ່າງຫນ້ອຍມັນໄດ້ເຮັດສໍາລັບຂ້ອຍໃນເວລາທີ່ຂ້ອຍກໍາລັງກະກຽມການປ່ອຍຄັ້ງສຸດທ້າຍ.

ມັນເປັນໄປໄດ້ໃນຫຼັກການທີ່ຈະເຮັດໃຫ້ Reiser4 ເປັນເຄືອຂ່າຍ (ກຸ່ມ) FS ໂດຍໃຊ້ plugins?

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

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

ຖ້າບໍ່ມີຫຍັງເຮັດວຽກກັບ Reiser4 ໃນ Linux, ຂ້ອຍຢາກສະເຫນີ FS ສໍາລັບ FreeBSD (ອ້າງອີງຈາກການສໍາພາດທີ່ຜ່ານມາ: "...FreeBSD ... ມີຮາກທາງວິຊາການ ... ແລະນີ້ຫມາຍຄວາມວ່າມີລະດັບສູງຂອງຄວາມເປັນໄປໄດ້ຂອງພວກເຮົາ. ຈະຊອກຫາພາສາທົ່ວໄປກັບນັກພັດທະນາ”) ?

ດັ່ງນັ້ນ, ດັ່ງທີ່ພວກເຮົາຫາກໍ່ຄົ້ນພົບ, ທຸກສິ່ງທຸກຢ່າງໄດ້ເຮັດວຽກຢ່າງສົມບູນແລ້ວກັບ Linux: ມີພອດ Reiser4 ທີ່ເຮັດວຽກແຍກຕ່າງຫາກສໍາລັບມັນໃນຮູບແບບຂອງສາຂາຕົ້ນສະບັບຂອງ repository ຂອງພວກເຮົາ. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ໄດ້​ລືມ​ກ່ຽວ​ກັບ FreeBSD​! ຂໍ້ສະເໜີ! ຂ້ອຍພ້ອມທີ່ຈະເຮັດວຽກຢ່າງໃກ້ຊິດກັບຜູ້ທີ່ຮູ້ພາຍໃນຂອງ FreeBSD ໄດ້ດີ. ໂດຍວິທີທາງການ: ສິ່ງທີ່ຂ້ອຍມັກກ່ຽວກັບຊຸມຊົນຂອງພວກເຂົາແມ່ນວ່າການຕັດສິນໃຈມີການປັບປຸງໂດຍສະພາຜູ້ຊ່ຽວຊານເອກະລາດ, ເຊິ່ງບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບການຫຼອກລວງຂອງລັດຖະບານຕໍ່ບຸກຄົນຖາວອນ.

ທ່ານໃຫ້ຄະແນນຊຸມຊົນຜູ້ໃຊ້ Linux ແນວໃດໃນມື້ນີ້? ມັນໄດ້ກາຍເປັນ "ປ໊ອບ" ຫຼາຍຂຶ້ນບໍ?

ເນື່ອງຈາກລັກສະນະຂອງການເຮັດວຽກຂອງຂ້ອຍ, ມັນຂ້ອນຂ້າງຍາກສໍາລັບຂ້ອຍທີ່ຈະປະເມີນເລື່ອງນີ້. ຜູ້ໃຊ້ສ່ວນໃຫຍ່ມາຫາຂ້ອຍດ້ວຍບົດລາຍງານ bug ແລະການຮ້ອງຂໍການແກ້ໄຂສ່ວນ. ຜູ້ໃຊ້ເປັນຜູ້ໃຊ້. ບາງ​ຄົນ​ມີ​ຄວາມ​ຮູ້​ຫຼາຍ, ບາງ​ຄົນ​ມີ​ຫນ້ອຍ. ທຸກຄົນໄດ້ຮັບການປິ່ນປົວຄືກັນ. ດີ, ຖ້າຜູ້ໃຊ້ບໍ່ສົນໃຈຄໍາແນະນໍາຂອງຂ້ອຍ, ຫຼັງຈາກນັ້ນຂໍໂທດຂ້ອຍ: ຄໍາສັ່ງທີ່ບໍ່ສົນໃຈຈະຖືກໃສ່ໃນສ່ວນຂອງຂ້ອຍເຊັ່ນກັນ.

ມັນເປັນໄປໄດ້ທີ່ຈະຄາດຄະເນການພັດທະນາຂອງລະບົບໄຟລ໌ສໍາລັບຫ້າຫາສິບປີຂ້າງຫນ້າ? ທ່ານຄິດວ່າສິ່ງທ້າທາຍຕົ້ນຕໍທີ່ນັກພັດທະນາ FS ອາດຈະປະເຊີນກັບຫຍັງ?

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

ແຕ່ລະ patch ພຽງແຕ່ເຮັດໃຫ້ບັນຫາຂອງມັນຮ້າຍແຮງຂຶ້ນ. ດີ. ແລະມີ "ຜູ້ປະກາດຂ່າວປະເສີດ" ປະເພດຕ່າງໆສະ ເໝີ ສໍາລັບຜູ້ທີ່ "ທຸກຢ່າງເຮັດວຽກ." ໂດຍພື້ນຖານແລ້ວ, ເຫຼົ່ານີ້ແມ່ນນັກຮຽນໃນໂຮງຮຽນແລະນັກຮຽນຂ້າມການບັນຍາຍ. ພຽງແຕ່ຈິນຕະນາການ: ມັນເຮັດວຽກສໍາລັບລາວ, ແຕ່ອາຈານບໍ່ໄດ້. ອັນ​ນີ້​ເປັນ​ການ​ຟ້າວ​ເຕັ້ນ​ adrenaline! ຈາກທັດສະນະຂອງຂ້ອຍ, ອັນຕະລາຍທີ່ສຸດແມ່ນເກີດມາຈາກ "ຊ່າງຫັດຖະກໍາ" ຜູ້ທີ່ຟ້າວທີ່ຈະກະຕືລືລົ້ນ "screw" ລັກສະນະທີ່ປະເສີດຂອງ Btrfs ເຂົ້າໄປໃນຊັ້ນຕ່າງໆເຊັ່ນ systemd, docker, ແລະອື່ນໆ. - ນີ້ແລ້ວຄ້າຍຄືກັບ metastases.

ຕອນນີ້ໃຫ້ພະຍາຍາມເຮັດການພະຍາກອນສໍາລັບຫ້າຫາສິບປີ. ຂ້າພະເຈົ້າໄດ້ລະບຸໄວ້ໂດຍຫຍໍ້ກ່ຽວກັບສິ່ງທີ່ພວກເຮົາຈະເຮັດໃນ Reiser4. ສິ່ງທ້າທາຍຕົ້ນຕໍສໍາລັບນັກພັດທະນາ FS ທ້ອງຖິ່ນຕັ້ງແຕ່ຕົ້ນນ້ໍາຈະເປັນ (ແມ່ນແລ້ວ, ມັນໄດ້ກາຍເປັນແລ້ວ) ຄວາມບໍ່ສາມາດທີ່ຈະເຮັດວຽກທີ່ເຫມາະສົມກັບເງິນເດືອນ. ໂດຍບໍ່ມີຄວາມຄິດໃດໆໃນຂົງເຂດການເກັບຮັກສາຂໍ້ມູນ, ພວກເຂົາຈະສືບຕໍ່ພະຍາຍາມແກ້ໄຂ VFS, XFS ແລະ ext4 ທີ່ໂຊກບໍ່ດີເຫຼົ່ານີ້. ສະຖານະການກັບ VFS ເບິ່ງຄືວ່າເປັນເລື່ອງຕະຫລົກໂດຍສະເພາະຕໍ່ກັບພື້ນຫລັງນີ້, reminiscent ຂອງຄວາມທັນສະໄຫມ frenzied ຂອງຮ້ານອາຫານທີ່ບໍ່ມີພໍ່ຄົວ, ແລະບໍ່ມີພໍ່ຄົວຄາດວ່າຈະມີ.

ຕອນນີ້ລະຫັດ VFS, ໂດຍບໍ່ມີເງື່ອນໄຂໃດໆ, ລັອກຫນ້າຫນ່ວຍຄວາມຈໍາຫຼາຍໆຄັ້ງໃນເວລາດຽວກັນແລະເຊື້ອເຊີນ FS ທີ່ຢູ່ເບື້ອງຕົ້ນໃຫ້ດໍາເນີນການກັບພວກມັນ. ນີ້ໄດ້ຖືກນໍາສະເຫນີເພື່ອປັບປຸງການປະຕິບັດຂອງ Ext4 ໃນການດໍາເນີນງານການລຶບ, ແຕ່ເປັນທີ່ເຂົ້າໃຈງ່າຍ, locking concurrent ດັ່ງກ່າວແມ່ນບໍ່ເຫມາະສົມກັບຮູບແບບການເຮັດທຸລະກໍາແບບພິເສດ. ນັ້ນແມ່ນ, ທ່ານຈະບໍ່ສາມາດເພີ່ມການສະຫນັບສະຫນູນສໍາລັບບາງລະບົບໄຟລ໌ smart ໃນ kernel. ຂ້ອຍບໍ່ຮູ້ວ່າສະຖານະການຢູ່ໃນພື້ນທີ່ອື່ນໆຂອງ Linux ແມ່ນຫຍັງ, ແຕ່ເທົ່າທີ່ລະບົບໄຟລ໌ກ່ຽວຂ້ອງ, ການພັດທະນາໃດໆຢູ່ທີ່ນີ້ບໍ່ຫນ້າຈະເຂົ້າກັນໄດ້ກັບນະໂຍບາຍທີ່ປະຕິບັດຕາມໂດຍ Torvalds ໃນທາງປະຕິບັດ (ໂຄງການທາງວິຊາການຖືກໄລ່ອອກ, ແລະ scammers ຜູ້ທີ່. ບໍ່​ມີ​ຄວາມ​ຄິດ​ວ່າ​ເປັນ​ໄມ້​ຢືນ​ຕົ້ນ B , ການ​ປ່ອຍ​ສິນ​ເຊື່ອ​ທີ່​ມີ​ທີ່​ສິ້ນ​ສຸດ​ຂອງ​ຄວາມ​ໄວ້​ວາງ​ໃຈ​ແມ່ນ​ອອກ​)​. ເພາະສະນັ້ນ, ຫຼັກສູດໄດ້ຖືກຕັ້ງໄວ້ສໍາລັບການທໍາລາຍຊ້າ. ແນ່ນອນ, ພວກເຂົາຈະພະຍາຍາມສຸດຄວາມສາມາດເພື່ອຜ່ານມັນໄປເປັນ "ການພັດທະນາ."

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

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

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

ຕໍ່ໄປຜູ້ທີ່ "ໂຊກບໍ່ດີ": ພວກເຂົາຈະນັບການສູນເສຍ, ຈັດການກັບຜົນສະທ້ອນຂອງການນໍາໃຊ້ຜະລິດຕະພັນຊອບແວທີ່ບໍ່ສາມາດໃຊ້ເຂົ້າໃນການຜະລິດ, "ແລະອື່ນໆ. ມີຫຼາຍຫຼາຍຂອງພວກເຂົາ. ດີ, ຢູ່ທີ່ຖານຂອງ pyramid ມີຈໍານວນຜູ້ພັດທະນາຈໍານວນຫລາຍ " sawing" ລະຫັດທີ່ບໍ່ມີປະໂຫຍດ. ພວກເຂົາເປັນຜູ້ສູນເສຍທີ່ໃຫຍ່ທີ່ສຸດ, ເພາະວ່າເວລາທີ່ເສຍໄປບໍ່ສາມາດກັບຄືນມາໄດ້. pyramids ດັ່ງກ່າວແມ່ນມີປະໂຫຍດຫຼາຍຕໍ່ Torvalds ແລະຜູ້ຮ່ວມງານຂອງລາວ. ແລະຫຼາຍ pyramids ເຫຼົ່ານີ້, ທີ່ດີກວ່າສໍາລັບພວກເຂົາ. ເພື່ອລ້ຽງ pyramids ດັ່ງກ່າວ, ສິ່ງໃດແດ່ສາມາດເອົາເຂົ້າໄປໃນຫຼັກ. ແນ່ນອນ, ໃນສາທາລະນະພວກເຂົາເວົ້າກົງກັນຂ້າມ. ແຕ່​ຂ້າ​ພະ​ເຈົ້າ​ຕັດ​ສິນ​ບໍ່​ແມ່ນ​ໂດຍ​ຄໍາ​ສັບ​ຕ່າງໆ​ແຕ່​ໂດຍ​ການ​ກະ​ທໍາ​.

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

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

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

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

ຫນ້າທໍາອິດ, ທ່ານຈະຕ້ອງການເປັນເອກະລາດເອົາຊະນະບັນຫາທີ່ຂ້າພະເຈົ້າຈະສະເຫນີ. ຫຼັງຈາກນັ້ນ, ຫມັ້ນໃຈວ່າຄວາມຈິງຈັງຂອງຄວາມຕັ້ງໃຈຂອງເຈົ້າ, ຂ້ອຍຈະເລີ່ມຕົ້ນຊ່ວຍ. ຕາມປະເພນີ, ພວກເຮົາໃຊ້ພຽງແຕ່ການພັດທະນາຂອງຕົນເອງ. ຂໍ້ຍົກເວັ້ນແມ່ນວິທີການບີບອັດແລະບາງຫນ້າທີ່ hash. ພວກເຮົາບໍ່ສົ່ງນັກພັດທະນາໄປປະຊຸມ, ແລະຫຼັງຈາກນັ້ນພວກເຮົາບໍ່ໄດ້ນັ່ງແລະປະສົມປະສານແນວຄວາມຄິດຂອງຄົນອື່ນ ("ບາງທີສິ່ງທີ່ຈະເກີດຂຶ້ນ"), ຕາມປະເພນີໃນການເລີ່ມຕົ້ນສ່ວນໃຫຍ່.

ພວກເຮົາພັດທະນາ algorithms ທັງຫມົດດ້ວຍຕົນເອງ. ປະຈຸບັນຂ້ອຍມີຄວາມສົນໃຈໃນດ້ານພຶດຊະຄະນິດ ແລະ ລັກສະນະປະສົມປະສານຂອງວິທະຍາສາດການເກັບຮັກສາຂໍ້ມູນ. ໂດຍສະເພາະ, ຂອບເຂດຈໍາກັດ, asymptotics, ຫຼັກຖານສະແດງຄວາມບໍ່ສະເຫມີພາບ. ຍັງມີການເຮັດວຽກສໍາລັບນັກຂຽນໂປລແກລມທໍາມະດາ, ແຕ່ຂ້ອຍຕ້ອງເຕືອນເຈົ້າທັນທີ: ຄໍາແນະນໍາທັງຫມົດທີ່ຈະ "ເບິ່ງ FS ອື່ນແລະເຮັດເຊັ່ນດຽວກັນ" ແມ່ນຖືກລະເລີຍ. Patches ແນໃສ່ການເຊື່ອມໂຍງທີ່ໃກ້ຊິດກັບ Linux ຜ່ານ VFS ກໍ່ຈະໄປທີ່ນັ້ນ.

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

ແຫຼ່ງຂໍ້ມູນ: opennet.ru