هن بهار ۾ اسان اڳ ۾ ئي ڪجهه تعارفي موضوع تي بحث ڪيو آهي، مثال طور. и . انهن مان ٻئي ۾، اسان ZFS ۾ مختلف ملٽي ڊسڪ ٽوپولاجي جي ڪارڪردگي جو مطالعو جاري رکڻ جو واعدو ڪيو. هي ايندڙ نسل جو فائيل سسٽم آهي جيڪو هاڻي هر هنڌ تان لڳايو پيو وڃي ڪرڻ .
خير، اڄ جو بهترين ڏينهن آهي ZFS سان واقفيت حاصل ڪرڻ لاءِ، شوقين پڙهندڙن. بس ڄاڻو ته OpenZFS ڊولپر Matt Ahrens جي عاجز تشخيص ۾، "اهو واقعي ڏکيو آهي."
پر ان کان اڳ جو اسان انگن تي وڃون ٿا - ۽ اتي ٿيندو، مان واعدو ڪريان ٿو - اٺ ڊسڪ ZFS ترتيب جي سڀني قسمن لاء، اسان کي ڳالهائڻ جي ضرورت آهي. ڪيئن عام طور تي، ZFS ڊسڪ تي ڊيٽا محفوظ ڪري ٿو.
Zpool، vdev ۽ ڊوائيس
هن مڪمل تلاءَ جي ڊراگرام ۾ ٽي معاون وي ڊي ويز شامل آهن، هر طبقي مان هڪ، ۽ RAIDz2 لاءِ چار
هتي عام طور تي بي ترتيب وي ڊي وي جي قسمن ۽ سائزن جو تلاءُ ٺاهڻ جو ڪو سبب ناهي - پر جيڪڏهن توهان چاهيو ته، توهان کي ائين ڪرڻ کان روڪڻ جي ڪا به شيءِ ناهي.
حقيقت ۾ ZFS فائل سسٽم کي سمجهڻ لاء، توهان کي ان جي حقيقي جوڙجڪ تي ويجهي نظر وٺڻ جي ضرورت آهي. پهريون، ZFS روايتي حجم ۽ فائل سسٽم جي انتظام جي تہن کي متحد ڪري ٿو. ٻيو، اهو هڪ ٽرانزيڪشنل ڪاپي-تي-لکڻ واري ميڪانيزم کي استعمال ڪري ٿو. انهن خاصيتن جو مطلب آهي ته سسٽم بنيادي طور تي روايتي فائل سسٽم ۽ RAID صفن کان بلڪل مختلف آهي. سمجھڻ لاءِ بنيادي بلڊنگ بلاڪ جو پھريون سيٽ آھن اسٽوريج پول (zpool)، ورچوئل ڊيوائس (vdev) ۽ حقيقي ڊيوائس (ڊوائيس).
زول
zpool اسٽوريج تلاء جي اعلي ترين ZFS جوڙجڪ آهي. هر تلاء ۾ هڪ يا وڌيڪ مجازي ڊوائيسز شامل آهن. موڙ ۾، انهن مان هر هڪ هڪ يا وڌيڪ حقيقي ڊوائيسز (ڊوائيس) تي مشتمل آهي. مجازي تلاءَ پاڻمرادو يونٽ آهن. ھڪڙي جسماني ڪمپيوٽر ٻن يا وڌيڪ الڳ تلاء تي مشتمل ٿي سگھي ٿو، پر ھر ھڪ مڪمل طور تي ٻين کان آزاد آھي. تلاءَ ورچوئل ڊوائيسز شيئر نٿا ڪري سگهن.
ZFS redundancy مجازي ڊوائيس جي سطح تي آهي، نه پول جي سطح تي. تلاءَ جي سطح تي بلڪل ڪا به بيڪار نه آهي- جيڪڏهن هڪ vdev يا وقف ٿيل vdev گم ٿي وڃي ته ان سان گڏ سڄو تلاءُ به گم ٿي ويندو.
جديد اسٽوريج پول هڪ ورچوئل ڊيوائس جي ڪيش يا لاگ جي نقصان کان بچي سگهن ٿا - جيتوڻيڪ اهي شايد ٿورڙي مقدار ۾ گندي ڊيٽا وڃائي سگهن ٿا جيڪڏهن اهي پاور بند ٿيڻ يا سسٽم جي حادثي دوران vdev لاگ وڃائي وڃن ٿا.
هتي هڪ عام غلط فڪر آهي ته ZFS "ڊيٽا پٽي" سڄي تلاء ۾ لکيل آهن. اهو سچ ناهي. Zpool هڪ مذاقي RAID0 ناهي، اهو هڪ وڌيڪ مضحکہ خیز آهي هڪ پيچيده متغير ورهائڻ واري ميڪانيزم سان.
سڀ کان وڌيڪ حصو لاء، رڪارڊ موجود مجازي ڊوائيسز جي وچ ۾ ورهايل آهن دستياب مفت جاء جي مطابق، تنهن ڪري نظريي ۾ اهي سڀئي هڪ ئي وقت ڀريا ويندا. ZFS جا وڌيڪ تازو ورزن موجوده vdev استعمال (ڊسپوزل) کي نظر ۾ رکندا آهن - جيڪڏهن هڪ ورچوئل ڊيوائس ٻئي جي ڀيٽ ۾ تمام گهڻي مصروف آهي (مثال طور، پڙهڻ جي لوڊ جي ڪري)، اهو عارضي طور تي لکڻ لاءِ ڇڏيو ويندو، ان جي باوجود سڀ کان وڌيڪ خالي جاءِ جو تناسب. .
جديد ZFS لکڻ جي تخصيص جي طريقن ۾ ٺهيل ريسائڪلنگ ڊيٽڪشن ميڪنزم دير سان گھٽائي سگھي ٿو ۽ غير معمولي تيز لوڊ جي دورن ۾ ان پٽ کي وڌائي سگھي ٿو - پر اهو نٿو ٿئي. ڪارٽ بلاڪ هڪ تلاءَ ۾ سست HDDs ۽ تيز SSDs جي غير ارادي ميلاپ لاءِ. اهڙو غير برابري وارو تلاءُ اڃا به سست رفتار ڊوائيس جي رفتار تي هلندو، يعني ڄڻ ته اهو مڪمل طور تي اهڙين ڊوائيسز مان ٺهيل هو.
vdev
هر اسٽوريج پول هڪ يا وڌيڪ مجازي ڊوائيسز (vdev) تي مشتمل آهي. موڙ ۾، هر وي ڊي ۾ هڪ يا وڌيڪ حقيقي ڊوائيسز شامل آهن. اڪثر ورچوئل ڊيوائسز استعمال ڪيون وينديون آهن سادو ڊيٽا اسٽوريج لاءِ، پر اتي ڪيترائي وي ڊيو مددگار طبقا آهن، جن ۾ ڪيچ، لاگ، ۽ اسپيشل شامل آهن. انهن vdev قسمن مان هر هڪ کي پنج ٽوپولاجيز مان هڪ ٿي سگهي ٿو: سنگل ڊيوائس، RAIDz1، RAIDz2، RAIDz3 يا آئيني.
RAIDz1، RAIDz2 ۽ RAIDz3 خاص قسم جا آھن جن کي پراڻا ماڻھو ڊبل (ڊيگنل) برابري RAID سڏيندا آھن. 1، 2 ۽ 3 حوالو ڏنو ويو آهي ته ڪيترا برابري بلاڪ هر ڊيٽا لين کي مختص ڪيا ويا آهن. برابري مهيا ڪرڻ لاءِ الڳ ڊسڪ رکڻ جي بدران، ورچوئل RAIDz ڊيوائسز برابري کي اڌ برابر برابر ڊسڪ ۾ ورهائي ٿو. هڪ RAIDz سري ڪيتريون ئي ڊسڪون وڃائي سگھن ٿيون جيئن ان ۾ برابري بلاڪ آهن؛ جيڪڏهن اهو هڪ ٻيو وڃائي ٿو، اهو ناڪام ٿيندو ۽ ان سان گڏ اسٽوريج پول وٺي ويندو.
آئيني مجازي ڊوائيسز ۾ (عڪس vdev)، هر بلاڪ هر ڊوائيس تي vdev ۾ ذخيرو ٿيل آهي. جيتوڻيڪ ٻه-وائڊ آئينا سڀ کان وڌيڪ عام آهن، هڪ آئيني ۾ ڪنهن به قسم جي ڊوائيسز جو تعداد شامل ٿي سگھي ٿو- وڏي تنصيب ۾، ٽرپل اڪثر ڪري استعمال ڪيا ويندا آهن پڙهڻ جي ڪارڪردگي ۽ غلطي رواداري کي بهتر ڪرڻ لاء. هڪ وي ڊيو آئيني ڪنهن به ناڪامي کان بچي سگهي ٿو جيستائين وي ڊي وي ۾ گهٽ ۾ گهٽ هڪ ڊوائيس هلندي رهي.
اڪيلو vdevs فطري طور تي خطرناڪ آهن. اهڙي هڪ مجازي ڊيوائس هڪ ناڪامي کان بچي نه سگهندي - ۽ جيڪڏهن اسٽوريج يا هڪ خاص vdev طور استعمال ڪيو وڃي، ته پوء ان جي ناڪامي سڄي تلاء جي تباهي کي ڏسندي. هتي تمام گهڻو، تمام محتاط ٿي.
CACHE، LOG، ۽ اسپيشل ورچوئل ڊيوائسز مٿي ڏنل ٽوپولوجيز مان ڪنھن ۾ به ٺاھي سگھجن ٿيون - پر ياد رکو ته ھڪ خاص ورچوئل ڊيوائس وڃائڻ جو مطلب آھي پول کي وڃائڻ، تنھنڪري ھڪ بيڪار ٽوپولاجيءَ جي سفارش ڪئي وئي آھي.
اوزار
اهو شايد ZFS ۾ سمجهڻ لاء آسان ترين اصطلاح آهي - اهو لفظي طور تي هڪ بلاڪ بي ترتيب واري رسائي ڊوائيس آهي. ياد رهي ته مجازي ڊوائيسز انفرادي ڊوائيسز مان ٺهيل آهن، ۽ هڪ تلاء مجازي ڊوائيسز مان ٺهيل آهي.
ڊسڪ، يا ته مقناطيسي يا مضبوط حالت، سڀ کان وڌيڪ عام بلاڪ ڊوائيسز آهن جيڪي vdev جي بلڊنگ بلاڪ طور استعمال ڪيا ويا آهن. بهرحال، ڪنهن به ڊوائيس سان بيان ڪندڙ /dev ۾ ڪندو - تنهنڪري سڄو هارڊويئر RAID صفون الڳ ڊوائيسز طور استعمال ڪري سگھجن ٿيون.
هڪ سادي خام فائل هڪ تمام اهم متبادل بلاڪ ڊوائيسز مان هڪ آهي جنهن مان هڪ vdev ٺاهي سگهجي ٿو. مان ٽيسٽ پول پول ڪمانڊ کي چيڪ ڪرڻ ۽ ڏسڻ لاءِ هڪ تمام آسان طريقو آهي پول يا ڏنل ٽوپولاجيءَ جي ورچوئل ڊيوائس ۾ ڪيتري جاءِ موجود آهي.
توهان صرف چند سيڪنڊن ۾ اسپارس فائلن مان ٽيسٽ پول ٺاهي سگهو ٿا - پر پوءِ مڪمل پول ۽ ان جي اجزاء کي حذف ڪرڻ نه وساريو
اچو ته چئو ته توهان هڪ اٺ-ڊسڪ سرور چاهيو ٿا ۽ 10 TB (~ 9300 GiB) ڊسڪ استعمال ڪرڻ جو ارادو ڪيو - پر توهان کي پڪ ناهي ته ڪهڙي ٽوپولوجي توهان جي ضرورتن کي بهتر بڻائي ٿي. مٿي ڏنل مثال ۾، اسان سيڪنڊن جي معاملي ۾ اسپارس فائلن مان هڪ ٽيسٽ پول ٺاهيندا آهيون - ۽ هاڻي اسان ڄاڻون ٿا ته اٺ 2 TB ڊسڪ جو هڪ RAIDz10 vdev 50 TiB استعمال جي قابل گنجائش فراهم ڪري ٿو.
ڊوائيسز جو هڪ ٻيو خاص طبقو SPARE آهي. Hot-swap ڊوائيسز، باقاعده ڊوائيسز جي برعڪس، هڪ واحد ورچوئل ڊيوائس جي بجاءِ پوري پول سان تعلق رکن ٿا. جيڪڏهن پول ۾ ڪو به وي ڊيو ناڪام ٿئي ٿو ۽ هڪ اضافي ڊوائيس پول سان ڳنڍيل آهي ۽ دستياب آهي، پوء اهو خودڪار طور تي متاثر ٿيل وي ڊيو ۾ شامل ٿيندو.
هڪ دفعو متاثر ٿيل وي ڊيو سان ڳنڍيل آهي، متبادل ڊيوائس وصول ڪرڻ شروع ڪري ٿو نقل يا ڊيٽا جي تعميرات جيڪا غائب ڊوائيس تي هجڻ گهرجي. روايتي RAID ۾ هن کي "ٻيهر تعمير" سڏيو ويندو آهي، ۽ ZFS ۾ اهو "resilvering" آهي.
اهو نوٽ ڪرڻ ضروري آهي ته متبادل ڊوائيسز مستقل طور تي ناڪام ڊوائيسز کي تبديل نه ڪندا آهن. اهو صرف هڪ عارضي متبادل آهي جيڪو وقت گھٽائڻ لاءِ جيڪو وي ڊي وي کي خراب ٿيڻ ۾ وٺندو آهي. منتظم کان پوءِ ناڪامي vdev ڊيوائس کي تبديل ڪري ٿو، فالتو ان مستقل ڊيوائس کي بحال ڪيو ويندو آهي، ۽ SPARE vdev کان ڌار ٿي ويندو آهي ۽ پوري تلاءَ لاءِ اسپيئر ٿيڻ ڏانهن موٽندو آهي.
ڊيٽا سيٽ، بلاڪ ۽ شعبا
اسان جي ZFS سفر ۾ سمجھڻ لاءِ بلڊنگ بلاڪ جو ايندڙ سيٽ هارڊويئر سان گهٽ ۽ وڌيڪ ان سان لاڳاپيل آهي ته ڊيٽا ڪيئن منظم ۽ محفوظ ٿيل آهي. اسان ھتي ڪجھ پرت ھٽائي رھيا آھيون - جھڙوڪ metaslab - تفصيلن کي بي ترتيب ٿيڻ کان بچڻ لاءِ جڏهن ته مجموعي ڍانچي جي سمجھ کي برقرار رکندي.
ڊيٽا سيٽ
جڏهن اسان پهريون ڀيرو هڪ ڊيٽا سيٽ ٺاهيندا آهيون، اهو ڏيکاري ٿو تمام موجود تلاء جي جڳهه. پوء اسان ڪوٽا مقرر ڪيو - ۽ جبل پوائنٽ کي تبديل ڪريو. جادو!
Zvol گهڻو ڪري صرف هڪ ڊيٽا سيٽ آهي جيڪو ان جي فائل سسٽم جي پرت مان ڪڍيو ويو آهي، جنهن کي اسين هتي مڪمل طور تي عام ext4 فائل سسٽم سان تبديل ڪندا آهيون.
ZFS ڊيٽا سيٽ تقريبن هڪ معياري نصب ٿيل فائل سسٽم وانگر آهي. هڪ باقاعده فائيل سسٽم وانگر، پهرين نظر ۾ اهو ظاهر ٿئي ٿو "صرف هڪ ٻيو فولڊر." پر صرف باقاعده نصب ٿيل فائل سسٽم وانگر، هر ZFS ڊيٽا سيٽ کي بنيادي ملڪيتن جو پنهنجو سيٽ آهي.
سڀ کان پهريان، هڪ ڊيٽا سيٽ شايد هڪ مقرر ڪيل ڪوٽا هجي. جيڪڏهن توهان انسٽال ڪريو zfs set quota=100G poolname/datasetname، ته پوءِ توهان نصب ٿيل فولڊر ۾ لکڻ جي قابل نه هوندا /poolname/datasetname 100 GiB کان وڌيڪ.
هر لڪير جي شروعات ۾ سليش جي موجودگي ۽ غير موجودگي کي نوٽيس ڪريو؟ هر ڊيٽا سيٽ جي پنهنجي جڳهه آهي ZFS جي جوڙجڪ ۽ سسٽم ماؤنٽ وارين درجي ۾. ZFS جي جوڙجڪ ۾ ڪو به اڳوڻو سليش نه آهي - توهان پول جي نالي سان شروع ڪريو ۽ پوء هڪ ڊيٽا سيٽ کان ٻئي ڏانهن رستو. مثال طور، pool/parent/child نالي جي ڊيٽا سيٽ لاءِ child والدين جي ڊيٽا سيٽ جي تحت parent هڪ تخليقي نالي سان هڪ تلاء ۾ pool.
ڊفالٽ طور، ڊيٽا سيٽ جو مائونٽ پوائنٽ ان جي نالي جي برابر هوندو ZFS hierarchy ۾، هڪ معروف سليش سان - پول جو نالو 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 فائل سسٽم سان، ۽ پوءِ ان فائل سسٽم کي مائونٽ ڪريو - ھاڻي توھان وٽ ھڪڙو ext4 فائل سسٽم آھي، پر ZFS جي سڀني حفاظتي خصوصيتن سان! اهو هڪ ڪمپيوٽر تي بيوقوف لڳي سگهي ٿو، پر هڪ iSCSI ڊوائيس برآمد ڪرڻ وقت هڪ پس منظر جي طور تي گهڻو وڌيڪ احساس پيدا ڪري ٿو.
بلاڪز
ھڪڙي فائل ھڪڙي يا وڌيڪ بلاڪ جي نمائندگي ڪئي وئي آھي. هر بلاڪ هڪ مجازي ڊوائيس تي ذخيرو ٿيل آهي. بلاڪ سائيز عام طور تي پيٽرولر جي برابر آهي رڪارڊ ڪرڻ، پر گھٽائي سگھجي ٿو 2^ شفٽ، جيڪڏھن اھو ميٽا ڊيٽا يا ھڪڙي ننڍڙي فائل تي مشتمل آھي.
اسان واقعي حقيقت آهي اسان وڏي ڪارڪردگي جي سزا جي باري ۾ مذاق نه ڪري رهيا آهيو جيڪڏهن توهان تمام گهٽ شفٽ سيٽ ڪيو
هڪ ZFS پول ۾، سڀ ڊيٽا، ميٽاداٽا سميت، بلاڪ ۾ محفوظ ٿيل آهي. هر ڊيٽا سيٽ لاء وڌ ۾ وڌ بلاڪ سائيز ملڪيت ۾ بيان ڪيو ويو آهي recordsize (رڪارڊ سائيز). رڪارڊ جي سائيز تبديل ٿي سگهي ٿي، پر اهو ڪنهن به بلاڪ جي سائيز يا هنڌ کي تبديل نه ڪندو جيڪي اڳ ۾ ئي ڊيٽا سيٽ تي لکيا ويا آهن - اهو صرف نون بلاڪ کي متاثر ڪري ٿو جيئن اهي لکيل آهن.
جيستائين ٻي صورت ۾ بيان نه ڪيو وڃي، موجوده ڊفالٽ داخلا سائيز 128 KiB آهي. اهو هڪ قسم جو سخت واپار آهي جتي ڪارڪردگي مڪمل نه هوندي، پر اهو اڪثر ڪيسن ۾ خوفناڪ نه ٿيندو. Recordsize 4K کان 1M تائين ڪنهن به قيمت تي سيٽ ڪري سگھجي ٿو (اضافي سيٽنگن سان recordsize توهان اڃا به وڌيڪ انسٽال ڪري سگهو ٿا، پر اهو گهٽ ۾ گهٽ هڪ سٺو خيال آهي).
ڪو به بلاڪ صرف هڪ فائل جي ڊيٽا ڏانهن اشارو ڪري ٿو- توهان ٻه مختلف فائلن کي هڪ بلاڪ ۾ نچوض نٿا ڪري سگهو. هر فائل هڪ يا وڌيڪ بلاڪ تي مشتمل آهي، ان جي سائيز تي منحصر آهي. جيڪڏهن فائل جي سائيز رڪارڊ سائيز کان ننڍو آهي، اهو هڪ ننڍڙو بلاڪ ۾ ذخيرو ڪيو ويندو - مثال طور، 2 KiB فائل سان هڪ بلاڪ صرف ڊسڪ تي هڪ 4 KiB شعبي تي قبضو ڪندو.
جيڪڏهن فائل ڪافي وڏي آهي ته ڪيترن ئي بلاڪن جي ضرورت آهي، ته پوءِ ان فائل ۾ سڀ داخلائون سائيز جون هونديون recordsize - آخري داخلا سميت، جنهن جو مکيه حصو ٿي سگهي ٿو .
zvol حجم ملڪيت نه آهي recordsize - ان جي بدران انهن جي برابر ملڪيت آهي volblocksize.
شعبا
آخري، سڀ کان بنيادي بلڊنگ بلاڪ سيڪٽر آھي. اهو سڀ کان ننڍڙو جسماني يونٽ آهي جيڪو هڪ ميزبان ڊوائيس تي لکيو يا پڙهي سگهجي ٿو. ڪيترن ئي ڏهاڪن تائين، سڀ کان وڌيڪ ڊسڪ 512-byte شعبا استعمال ڪيا ويا. انهن ڏينهن ۾، اڪثر ڊرائيو 4 KiB شعبن لاءِ ترتيب ڏنل آهن، ۽ ڪجهه - خاص طور تي SSDs - ترتيب ڏنل آهن 8 KiB شعبن لاءِ يا ان کان به وڌيڪ.
ZFS ۾ ھڪڙي خاصيت آھي جيڪا توھان کي دستي طور تي سيٽ ڪرڻ جي اجازت ڏئي ٿي شعبي جي سائيز. هي ملڪيت ashift. ڪجھھ مونجهاري سان، شفٽ ٻن جي طاقت آھي. مثال طور، ashift=9 يعني سيڪٽر سائيز 2^9، يا 512 بائيٽ.
ZFS آپريٽنگ سسٽم کان پڇي ٿو تفصيلي معلومات لاءِ هر بلاڪ ڊيوائس جي باري ۾ جڏهن اها نئين وي ڊيو ۾ شامل ڪئي وئي آهي، ۽ نظرياتي طور تي خودڪار طور تي ان معلومات جي بنياد تي مناسب طور تي شفٽ سيٽ ڪري ٿو. بدقسمتي سان، ونڊوز XP سان مطابقت برقرار رکڻ لاءِ ڪيتريون ئي ڊرائيوون پنهنجي شعبي جي سائيز جي باري ۾ ڪوڙ ڳالهائين ٿيون (جيڪو ٻين شعبي جي سائزن سان ڊرائيو کي سمجهڻ جي قابل نه هو).
هن جو مطلب اهو آهي ته اها انتهائي سفارش ڪئي وئي آهي ته ZFS منتظم انهن جي ڊوائيس جي حقيقي شعبي جي سائيز کي ڄاڻن ۽ دستي طور تي سيٽ ڪريو ashift. جيڪڏهن شفٽ تمام ننڍو مقرر ڪيو ويو آهي، پڙهڻ / لکڻ جي عملن جو تعداد astronomically وڌائي ٿو. تنهن ڪري، 512-byte "سيڪٽرز" کي حقيقي 4 KiB شعبي تي لکڻ جو مطلب آهي پهريون "سيڪٽر" لکڻو آهي، پوء 4 KiB شعبي کي پڙهو، ان کي ٻئي 512-بائيٽ "سيڪٽر" سان تبديل ڪريو، ان کي واپس نئين ڏانهن لکو. 4 KiB شعبي، ۽ ائين ئي هر داخلا لاء.
حقيقي دنيا ۾، اهڙي سزا سامسنگ EVO SSDs کي متاثر ڪري ٿي، جنهن لاء اهو لاڳو ٿيڻ گهرجي ashift=13، پر اهي SSDs انهن جي شعبي جي سائيز بابت ڪوڙ ڳالهائيندا آهن، ۽ تنهن ڪري ڊفالٽ مقرر ڪيو ويو آهي ashift=9. جيستائين هڪ تجربيڪار سسٽم ايڊمنسٽريٽر هن سيٽنگ کي تبديل ڪري، هي SSD ڪم ڪري ٿو وerيڪ سست باقاعده مقناطيسي HDD.
مقابلي لاءِ ، تمام وڏو هجڻ لاءِ ashift عملي طور تي ڪو به سزا نه آهي. ڪابه حقيقي ڪارڪردگي هٽ نه آهي، ۽ غير استعمال ٿيل جاء ۾ اضافو لامحدود آهي (يا صفر جيڪڏهن کمپريشن فعال آهي). تنهن ڪري، اسان سختي سان صلاح ڏيو ٿا ته اهي ڊرائيو جيڪي 512-byte شعبن کي استعمال ڪن ٿا انسٽال ڪريو ashift=12 يا اڃا به ashift=13مستقبل ۾ اعتماد سان ڏسڻ لاء.
ملڪيت ashift هر مجازي ڊوائيس لاء نصب ٿيل آهي vdev، ۽ پول لاء نه، جيئن ڪيترائي ماڻهو غلطيءَ سان سوچين ٿا - ۽ انسٽاليشن کان پوءِ تبديل نٿو ٿئي. جيڪڏهن توهان حادثاتي طور تي ماريو ashift جڏهن توهان پول ۾ هڪ نئون وي ڊيو شامل ڪيو ٿا، ته توهان ان تلاءَ کي گهٽ ڪارڪردگيءَ واري ڊيوائس سان خراب ڪري ڇڏيو آهي ۽، ضابطي جي طور تي، پول کي تباهه ڪرڻ ۽ ٻيهر شروع ڪرڻ کان سواءِ ٻيو ڪو به آپشن ناهي. جيتوڻيڪ vdev کي حذف ڪرڻ توهان کي ٽٽل سيٽنگ کان بچائي نه سگهندو ashift!
ڪاپي-تي-لکڻ ميڪانيزم
جيڪڏهن هڪ باقاعده فائيل سسٽم کي ڊيٽا کي ٻيهر لکڻ جي ضرورت آهي، اهو هر بلاڪ کي تبديل ڪري ٿو جتي اهو واقع آهي
ڪاپي تي لکندڙ فائل سسٽم بلاڪ جو نئون ورزن لکي ٿو ۽ پوءِ پراڻي ورزن کي ان لاڪ ڪري ٿو
خلاصي ۾، جيڪڏهن اسان بلاڪن جي حقيقي جسماني ترتيب کي نظر انداز ڪريون ٿا، اسان جو "ڊيٽا ڪميٽ" هڪ "ڊيٽا ورم" کي آسان بڻائي ٿو جيڪو دستياب خلا جي نقشي ۾ کاٻي کان ساڄي طرف منتقل ٿئي ٿو.
ھاڻي اسان چڱيءَ طرح ڄاڻ حاصل ڪري سگھون ٿا ته ڪاپي-آن-لکڻ سنيپ شاٽ ڪيئن ڪم ڪن ٿا - ھر بلاڪ ڪيترن ئي سنيپ شاٽس سان واسطو رکي سگھي ٿو، ۽ جاري رھندو جيستائين سڀئي لاڳاپيل سنيپ شاٽ ناس ٿي وڃن
ڪاپي آن رائٽ (CoW) ميڪانيزم جو بنيادي بنياد آهي جيڪو ZFS کي اهڙي شاندار سسٽم ٺاهي ٿو. بنيادي تصور سادو آهي - جيڪڏهن توهان هڪ روايتي فائل سسٽم کان پڇو ته فائل تبديل ڪرڻ لاء، اهو اهو ئي ڪندو جيڪو توهان پڇيو. جيڪڏهن توهان هڪ ڪاپي-آن-لکڻ واري فائل سسٽم کي ساڳيو ڪم ڪرڻ لاءِ پڇو، اهو چوندو ”ٺيڪ آهي“- پر اهو توهان سان ڪوڙ ڳالهائيندو.
ان جي بدران، ڪاپي تي لکندڙ فائل سسٽم تبديل ٿيل بلاڪ جو نئون ورزن لکي ٿو، ۽ پوءِ فائل جي ميٽا ڊيٽا کي اپڊيٽ ڪري ٿو پراڻي بلاڪ کي ختم ڪرڻ ۽ ان کي نئين بلاڪ سان جوڙيو جيڪو توهان لکيو آهي.
پراڻي بلاڪ کي ختم ڪرڻ ۽ نئين کي ڳنڍڻ هڪ آپريشن ۾ ڪيو ويو آهي، تنهنڪري ان ۾ مداخلت نه ٿي ڪري سگهجي - جيڪڏهن توهان پاور ري سيٽ ڪيو ته ائين ٿيڻ کان پوء، توهان وٽ فائل جو هڪ نئون نسخو آهي، ۽ جيڪڏهن توهان اڳ ۾ پاور ري سيٽ ڪيو، ته پوء توهان وٽ آهي. پراڻو نسخو. ڪنهن به صورت ۾، فائيل سسٽم ۾ ڪو به تڪرار نه ٿيندو.
ZFS ۾ ڪاپي-آن-لکڻ نه رڳو فائل سسٽم جي سطح تي، پر ڊسڪ مينيجمينٽ جي سطح تي پڻ. هن جو مطلب آهي ته ZFS رڪارڊ ۾ وائيٽ اسپيس لاء حساس ناهي () - ھڪڙو رجحان جڏھن پٽي صرف جزوي طور تي رڪارڊ ڪيو ويو ھو سسٽم جي خراب ٿيڻ کان اڳ، ريبوٽ کان پوء صف کي نقصان سان. هتي پٽي ايٽمي طور تي لکيل آهي، vdev هميشه ترتيب وار آهي، ۽ .
ZIL: ZFS ارادي لاگ
ZFS هڪ خاص طريقي سان هم وقت ساز لکڻين کي سنڀاليندو آهي - اهو انهن کي عارضي طور تي ذخيرو ڪري ٿو پر فوري طور تي ZIL ۾ ان کان اڳ مستقل طور تي انهن کي غير مطابقت واري لکڻين سان گڏ لکڻ کان اڳ.
عام طور تي، ZIL ڏانهن لکيل ڊيٽا ڪڏهن به ٻيهر نه پڙهيو آهي. پر اهو نظام جي ناڪامي کان پوء ممڪن آهي
هڪ SLOG، يا ثانوي LOG ڊوائيس، صرف هڪ خاص آهي - ۽ ترجيح طور تي تمام تيز - vdev جتي ZIL کي مکيه اسٽوريج کان الڳ طور تي محفوظ ڪري سگهجي ٿو.
حادثي کان پوء، ZIL ۾ تمام گندي ڊيٽا ٻيهر هلايو ويندو آهي - هن صورت ۾، ZIL SLOG تي آهي، تنهنڪري اهو آهي جتي اهو ٻيهر هلايو ويو آهي
لکت جا ٻه مکيه ڀاڱا آهن: هم وقت ساز ( هم وقت ساز ) ۽ هم وقت ساز ( async ). اڪثر ڪم جي لوڊ لاءِ، لکت جي وڏي اڪثريت غير هم وقتي هوندي آهي - فائل سسٽم انهن کي گڏ ڪرڻ ۽ بيچز ۾ جاري ڪرڻ جي اجازت ڏئي ٿو، ٽڪراءَ کي گھٽائي ٿو ۽ خاص طور تي وڌاءُ ذريعي.
هم وقت سازي رڪارڊنگ هڪ مڪمل طور تي مختلف معاملو آهي. جڏهن هڪ ايپليڪيشن هڪ هم وقت ساز لکڻ جي درخواست ڪري ٿي، اهو فائل سسٽم کي ٻڌائي ٿو: "توهان کي غير مستحڪم ميموري کي انجام ڏيڻ جي ضرورت آهي. بلڪل هاڻي۽ ان وقت تائين مان ڪجھ به نه ٿو ڪري سگهان. تنهن ڪري، هم وقت ساز لکندڙن کي فوري طور تي ڊسڪ تي پابند ٿيڻ گهرجي - ۽ جيڪڏهن اهو ٽڪراء وڌائي ٿو يا ان جي ذريعي گهٽائي ٿو، ته ائين ئي هجي.
ZFS هم وقت ساز لکتن کي باقاعده فائل سسٽم کان مختلف طور تي سنڀاليندو آهي- انهن کي فوري طور تي باقاعده اسٽوريج تي فلش ڪرڻ جي بدران، ZFS انهن کي هڪ خاص اسٽوريج ايريا ڏانهن ڪم ڪري ٿو جيڪو ZFS Intent Log، يا ZIL سڏيو ويندو آهي. چال اها آهي ته اهي رڪارڊ پڻ ميموري ۾ رهي، عام طور تي غير معمولي لکڻ جي درخواستن سان گڏ گڏ ڪيو وڃي، بعد ۾ اسٽوريج ۾ مڪمل طور تي عام TXGs (ٽرانزيڪشن گروپ) جي طور تي فلش ڪيو وڃي.
عام آپريشن دوران، ZIL لکيو ويو آهي ۽ ڪڏهن به ٻيهر نه پڙهي. جڏهن، ڪجهه لمحن کان پوء، ZIL کان رڪارڊ ريم کان باقاعده TXGs ۾ مکيه اسٽوريج لاء انجام ڏنو ويو آهي، اهي ZIL کان جدا ٿي ويا آهن. صرف هڪ وقت ZIL کان ڪجهه پڙهيو ويندو آهي جڏهن پول درآمد ڪندي.
جيڪڏهن ZFS ناڪام ٿئي ٿي - هڪ آپريٽنگ سسٽم حادثو يا بجلي بند ٿيڻ - جڏهن ته ZIL ۾ ڊيٽا موجود آهي، اها ڊيٽا ايندڙ پول درآمد دوران پڙهي ويندي (مثال طور، جڏهن ناڪامي سسٽم ٻيهر شروع ٿئي ٿي). ZIL ۾ جيڪو به آهي اهو پڙهيو ويندو، TXGs ۾ گروپ ڪيو ويندو، مکيه اسٽور سان واعدو ڪيو ويندو، ۽ پوءِ درآمد جي عمل دوران ZIL کان ڌار ڪيو ويندو.
vdev مددگار طبقن مان هڪ کي LOG يا SLOG سڏيو ويندو آهي، هڪ ثانوي LOG ڊوائيس. اهو هڪ ڪم آهي - هڪ تلاء فراهم ڪرڻ لاء هڪ الڳ ۽، ترجيح طور تي، تمام تيز، تمام تيز لکڻ جي مزاحمت سان، ZIL کي ذخيرو ڪرڻ لاء Vdev ڊوائيس، ZIL کي مکيه vdev اسٽوريج تي ذخيرو ڪرڻ جي بدران. ZIL پاڻ کي اسٽوريج جي جڳهه جي پرواهه ڪرڻ کان سواء ساڳيو ئي عمل ڪري ٿو، پر جيڪڏهن LOG سان وي ڊيو تمام اعلي لکڻ جي ڪارڪردگي آهي، پوء هم وقت سازي لکت تيز ٿي ويندي.
پول ۾ LOG سان vdev شامل ڪرڻ ڪم نٿو ڪري نه ٿي سگهي هم وقت سازي لکڻ جي ڪارڪردگي بهتر ڪريو - جيتوڻيڪ جيڪڏهن توهان زور ڀريو ته سڀني لکڻين کي ZIL سان zfs set sync=always، اهي اڃا تائين ڳنڍيل هوندا TXG ۾ مکيه اسٽوريج سان ساڳيءَ طرح ۽ ساڳئي رفتار تي جيئن لاگ کان سواءِ. صرف سڌي ڪارڪردگي بهتري آهي هم وقت سازي لکڻ جي دير (جيئن وڌيڪ لاگ اسپيڊ آپريشن کي تيز ڪري ٿي sync).
تنهن هوندي، هڪ ماحول ۾ جيڪو اڳ ۾ ئي هم وقت سازي لکڻ جي ضرورت آهي، vdev LOG اڻ سڌي طرح تيز ڪري سگهي ٿو غير مطابقت واري لکڻين ۽ اڻ پڙهيل پڙهڻ. ZIL رڪارڊز کي الڳ vdev LOG ۾ بند ڪرڻ جو مطلب آهي IOPS لاءِ پرائمري اسٽوريج تي گهٽ تڪرار، جيڪو ڪجهه حد تائين سڀني پڙهڻ ۽ لکڻ جي ڪارڪردگي کي بهتر بڻائي ٿو.
سنيپ شاٽ
ڪاپي-آن-لکڻ واري ميڪانيزم پڻ ZFS ايٽمي سنيپ شاٽ ۽ وڌندڙ غير مطابقت واري نقل لاءِ لازمي بنياد آهي. فعال فائل سسٽم ۾ ھڪڙو پوائنٽر وڻ آھي جيڪو موجوده ڊيٽا سان سڀني داخلن کي نشانو بڻائيندو آھي - جڏھن توھان ھڪڙو سنيپ شاٽ وٺو، توھان صرف ھن پوائنٽر وڻ جي ھڪڙي ڪاپي ٺاھيو.
جڏهن هڪ رڪارڊ فعال فائل سسٽم تي اوور رائٽ ڪيو ويندو آهي، ZFS پهريون ڀيرو بلاڪ جي نئين ورزن کي غير استعمال ٿيل جاء تي لکي ٿو. ان کان پوء بلاڪ جي پراڻي ورزن کي موجوده فائل سسٽم کان جدا ڪري ٿو. پر جيڪڏهن ڪجهه سنيپ شاٽ هڪ پراڻي بلاڪ جو حوالو ڏئي ٿو، اهو اڃا تائين اڻڄاتل رهي ٿو. پراڻو بلاڪ اصل ۾ خالي جاءِ جي طور تي بحال نه ٿيندو جيستائين سڀئي اسنيپ شاٽ ان بلاڪ جي حوالي سان تباهه نه ٿي وڃن!
نقل
منهنجي اسٽيم لائبريري 2015 ۾ 158 GiB هئي ۽ 126 فائلون شامل آهن. هي rsync لاءِ بهتر صورتحال جي بلڪل ويجهو آهي - نيٽ ورڪ تي ZFS نقل "صرف" 927٪ تيز هئي.
ساڳئي نيٽ ورڪ تي، هڪ واحد 40GB ونڊوز 7 ورچوئل مشين تصويري فائل کي نقل ڪرڻ هڪ مڪمل طور تي مختلف ڪهاڻي آهي. ZFS نقل rsync کان 289 ڀيرا وڌيڪ تيز آهي- يا "صرف" 161 ڀيرا وڌيڪ تيز جيڪڏهن توهان ڪافي ڄاڻو آهيو ته rsync کي --inplace سوئچ سان ڪال ڪريو.
جڏهن هڪ VM تصوير اسڪيل، rsync مسئلا ان سان ماپ ڪري ٿو. جديد VM تصوير لاءِ 1,9 TiB سائيز ايتري وڏي نه آهي- پر اهو ايترو وڏو آهي ته ZFS نقل rsync کان 1148 ڀيرا تيز آهي، جيتوڻيڪ rsync --inplace دليل سان.
هڪ دفعو توهان سمجھو ٿا ته سنيپ شاٽ ڪيئن ڪم ڪن ٿا، اهو آسان ٿي ويندو نقل جي جوهر کي سمجهڻ. جيئن ته هڪ سنيپ شاٽ صرف رڪارڊ پوائنٽن جو هڪ وڻ آهي، اهو ان جي پٺيان آهي جيڪڏهن اسان ڪندا آهيون 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, it compares two pointer trees. ڪو به اشارو جيڪي صرف موجود آهن @2واضح طور تي نون بلاڪن جو حوالو ڏيو - تنهنڪري اسان کي انهن بلاڪن جي مواد جي ضرورت پوندي.
ريموٽ سسٽم تي، پروسيسنگ وڌندڙ send بلڪل سادو. سڀ کان پهريان اسان لکون ٿا سڀئي نيون داخلائون وهڪرو ۾ شامل آهن send، ۽ پوءِ شامل ڪريو پوائنٽر انهن بلاڪن ڏانهن. Voila، اسان وٽ آهي @2 نئين نظام ۾!
ZFS غير سنيپ شاٽ تي مبني طريقن جهڙوڪ rsync جي ڀيٽ ۾ هڪ وڏو سڌارو آهي. ٻنهي صورتن ۾، صرف تبديل ٿيل ڊيٽا کي منتقل ڪيو ويو آهي - پر rsync پهريان لازمي آهي پڙهو ڊسڪ مان ٻنهي پاسن جي سڀني ڊيٽا کي چيڪ ڪرڻ ۽ ان جي مقابلي ڪرڻ لاء. ان جي ابتڙ، ZFS ريپليڪشن پوائنٽر وڻن کان سواء ٻيو ڪجهه نه پڙهي ٿو- ۽ ڪو به بلاڪ جيڪي مجموعي سنيپ شاٽ ۾ نمائندگي نه ڪيا ويا آهن.
تعمير ٿيل کمپريشن
ڪاپي-تي-لکڻ واري ميڪانيزم پڻ ٺهيل ڪمپريشن سسٽم کي آسان بڻائي ٿي. هڪ روايتي فائيل سسٽم ۾، ڪمپريشن مسئلو آهي - ٻئي پراڻو نسخو ۽ تبديل ٿيل ڊيٽا جو نئون نسخو ساڳئي جاء تي آهن.
جيڪڏهن توهان ڪنهن فائل جي وچ ۾ ڊيٽا جي هڪ ٽڪري تي غور ڪيو ته ان جي زندگي شروع ٿئي ٿي صفر جي ميگا بائيٽ جي طور تي 0x00000000 ۽ انهي تي - ان کي ڊسڪ تي هڪ واحد شعبي ۾ دٻائڻ تمام آسان آهي. پر ڇا ٿيندو جيڪڏهن اسان زيرو جي هن ميگا بائيٽ کي ميگا بائيٽ جي ناقابل استعمال ڊيٽا سان تبديل ڪريون، جهڙوڪ JPEG يا pseudo-random noise؟ اوچتو، ڊيٽا جي ميگا بائيٽ کي هڪ نه، پر 256 4 KiB شعبن جي ضرورت هوندي، ۽ صرف هڪ شعبي ان ڊسڪ اسپيس ۾ محفوظ ڪيو ويو.
ZFS وٽ اهو مسئلو ناهي، ڇاڪاڻ ته تبديل ٿيل رڪارڊ هميشه غير استعمال ٿيل جڳهه تي لکندا آهن - اصل بلاڪ صرف هڪ 4 KiB سيڪٽر وٺندو آهي، ۽ هڪ نئون لکڻ 256 تائين وٺندو، پر اهو مسئلو ناهي - تازو تبديل ٿيل ٽڪرا فائل جي "وچ" کي غير استعمال ٿيل جاء تي لکيو ويندو، قطع نظر ته ان جي سائيز تبديل ٿي وئي آهي يا نه، تنهنڪري اهو ZFS لاء مڪمل طور تي عام صورتحال آهي.
بلٽ-ان ZFS ڪمپريشن ڊفالٽ طور تي بند ٿيل آهي، ۽ سسٽم پيش ڪري ٿو پلگ ايبل الگورتھم - في الحال LZ4، gzip (1-9)، LZJB ۽ ZLE شامل آهن.
- LZ4 هڪ اسٽريمنگ الگورٿم آهي جيڪو پيش ڪري ٿو انتهائي تيز ڪمپريشن ۽ ڊيڪپريشن ۽ ڪارڪردگي جا فائدا اڪثر استعمال جي ڪيسن لاءِ - جيتوڻيڪ ڪافي سست CPUs تي.
- GZIP هڪ قابل احترام الگورتھم آهي جنهن کي سڀ يونڪس استعمال ڪندڙ ڄاڻن ٿا ۽ پيار ڪن ٿا. اهو ڪمپريشن ليول 1-9 سان لاڳو ٿي سگهي ٿو، وڌندي ڪمپريشن تناسب ۽ سي پي يو جي استعمال سان جيئن توهان 9 ليول تي پهچن ٿا. الورورٿم سڀني ٽيڪسٽ (يا ٻيو انتهائي دٻائڻ وارو) استعمال جي ڪيسن لاءِ موزون آهي، پر اڪثر ڪري CPU مسئلا پيدا ڪري ٿو ٻي صورت ۾ - ان کي استعمال ڪريو احتياط سان، خاص طور تي اعلي سطح تي.
- ايل جي جي بي - ZFS ۾ اصل الگورتھم. اهو متروڪ آهي ۽ هاڻي استعمال نه ٿيڻ گهرجي، LZ4 هر لحاظ کان بهتر آهي.
- خراب - صفر ليول انڪوڊنگ، زيرو ليول انڪوڊنگ. اهو عام ڊيٽا کي هرگز نه ڇڪيندو آهي، پر اهو زيرو جي وڏي ترتيبن کي دٻائي ٿو. مڪمل طور تي ناقابل استعمال ڊيٽا سيٽن لاءِ ڪارآمد (جهڙوڪ JPEG، MP4 يا ٻيون اڳ ۾ ئي ڪمپريس ٿيل فارميٽ) جيئن ته اهو ناقابل استعمال ڊيٽا کي نظر انداز ڪري ٿو پر نتيجن جي رڪارڊ ۾ غير استعمال ٿيل جڳهه کي دٻائي ٿو.
اسان تقريبن سڀني استعمال جي ڪيسن لاء LZ4 کمپريشن جي صلاح ڏيو ٿا؛ ڪارڪردگي جي سزا جڏهن ناقابل برداشت ڊيٽا سان معاملو ڪرڻ تمام ننڍڙو آهي، ۽ واڌ عام ڊيٽا لاء ڪارڪردگي اهم آهي. ونڊوز آپريٽنگ سسٽم جي نئين تنصيب لاءِ ورچوئل مشين جي تصوير کي نقل ڪرڻ (تازو نصب ٿيل OS، اڃا تائين اندر ڪا ڊيٽا ناهي) compression=lz4 27 سيڪڙو تيزيءَ سان گذري ويو compression=none۾ .
ARC - موافقت واري متبادل ڪيش
ZFS واحد جديد فائل سسٽم آهي جنهن کي اسان ڄاڻون ٿا ته ان جي پنهنجي ريڊ ڪيشنگ ميڪانيزم استعمال ڪري ٿي، بلڪه آپريٽنگ سسٽم جي پيج ڪيش تي ڀروسو ڪرڻ بجاءِ ريم ۾ تازو پڙهيل بلاڪن جون ڪاپيون محفوظ ڪرڻ لاءِ.
جيتوڻيڪ اصلي ڪيش ان جي مسئلن کان سواءِ نه آهي - ZFS نئين ميموري مختص ڪرڻ جي درخواستن جو جواب نه ٿو ڏئي سگهي جيترو جلدي ڪرنل ، تنهنڪري هڪ نئون ڪال malloc() ميموري مختص ناڪام ٿي سگھي ٿي جيڪڏھن ان کي RAM جي ضرورت آھي ھن وقت ARC جي قبضي ۾ آھي. پر توهان جي پنهنجي ڪيش کي استعمال ڪرڻ جا سٺا سبب آهن، گهٽ ۾ گهٽ هاڻي لاء.
سڀ سڃاتل جديد آپريٽنگ سسٽم، جن ۾ MacOS، Windows، Linux ۽ BSD شامل آهن، استعمال ڪن ٿا LRU (Least Recently Used) الورورٿم صفحي جي ڪيش کي لاڳو ڪرڻ لاءِ. هي هڪ پرائمري الگورٿم آهي جيڪو هر پڙهڻ کان پوءِ هڪ ڪيش ٿيل بلاڪ کي ”قطار جي چوٽيءَ تائين“ کي دٻائي ٿو ۽ بلاڪن کي ”قطار جي هيٺان“ ڏانهن ڌڪي ٿو جيئن ضرورت هجي ته نئين ڪيش مسز شامل ڪرڻ جي ضرورت هجي (بلاڪ جيڪي ڊسڪ کان پڙهڻ بجاءِ ڊسڪ مان پڙهڻ گهرجن ها. ڪيش کان) مٿي تائين.
عام طور تي الورورٿم ٺيڪ ڪم ڪري ٿو، پر سسٽم تي وڏي ڪم ڪندڙ ڊيٽا سيٽن سان، LRU آسانيءَ سان ڇڪڻ جي طرف وٺي وڃي ٿو- اڪثر گهربل بلاڪن کي بي دخل ڪرڻ لاءِ ڪمرو ٺاهڻ لاءِ جيڪي ڪيش مان ٻيهر نه پڙهيا ويندا.
هڪ تمام گهٽ غير معمولي الگورتھم آهي جنهن کي سمجهي سگهجي ٿو "وزن وارو" ڪيش. هر دفعي ڪيش ٿيل بلاڪ کي پڙهيو ويندو آهي، اهو ٿورڙو ڳرو ۽ بي دخل ڪرڻ ڏکيو ٿيندو آهي - ۽ ان کان پوءِ به بلاڪ بي دخل ڪيو وڃي ٽريڪ ٿيل وقت جي هڪ خاص عرصي دوران. هڪ بلاڪ جيڪو بي دخل ڪيو ويو آهي پر پوءِ پڙهڻ جي ضرورت آهي واپس ڪيش ۾ پڻ ڳري ٿي ويندي.
هن سڀني جو آخري نتيجو هڪ ڪيش آهي هڪ تمام گهڻي هٽ جي تناسب سان - ڪيش هٽس جي وچ ۾ تناسب (ڪيش مان پڙهي) ۽ مس (ڊسڪ مان پڙهي). هي هڪ انتهائي اهم انگ اکر آهي - نه صرف ڪيش هٽس پاڻ ۾ تيزيءَ سان آرڊر جي خدمت ڪري رهيا آهن، ڪيش مس به تيزيءَ سان خدمت ڪري سگھجن ٿا، ڇو ته جيتري وڌيڪ ڪيش هٽس آهن، اوتريون گهٽ متوازي درخواستون ڊسڪ لاءِ ۽ گهٽ آهن انهن باقي مسز لاءِ دير جيڪو ڊسڪ سان خدمت ڪرڻ گهرجي.
ٿڪل
هاڻي ته اسان ZFS جي بنيادي معنائن کي ڍڪي ڇڏيو آهي- ڪاپي-آن-لکڻ ڪيئن ڪم ڪندو آهي، گڏوگڏ اسٽوريج پولز، ورچوئل ڊيوائسز، بلاڪس، شعبن ۽ فائلن جي وچ ۾ لاڳاپا- اسان حقيقي دنيا جي ڪارڪردگي تي بحث ڪرڻ لاءِ تيار آهيون. حقيقي انگ.
ايندڙ حصي ۾، اسان هڪ ٻئي جي مقابلي ۾ آئيني ٿيل vdev ۽ RAIDz پولز جي حقيقي ڪارڪردگي تي نظر وجهنداسين، ۽ ان جي مقابلي ۾ روايتي لينڪس ڪنيل RAID ٽوپولوجيز جو اسان جائزو ورتو آهي. .
شروعات ۾ اسان چاهيون ٿا ته صرف بنيادي شيون - ZFS ٽوپولوجيز پاڻ - پر پوءِ اهڙيون اسان ZFS جي وڌيڪ ترقي يافته ترتيبن ۽ ٽيوننگ بابت ڳالهائڻ لاءِ تيار ٿي وينداسين، بشمول معاون vdev قسمن جي استعمال جهڙوڪ L2ARC، SLOG ۽ خاص مختص.
جو ذريعو: www.habr.com