ფაილური სისტემის შეზღუდვები

ერთ-ერთი საიტის კოდში შემხვდა hack ლინუქსისთვის, რომელიც ფაილური სისტემის შეზღუდვის გათვალისწინების გამო იყო ჩამატებული. მივხვდი, აქამდე არასდროს მიფიქრია ასეთ წინააღმდეგობებზე და გადავწყვიტე ფაილური სისტემების აღწერისთვის მიმეძღვნა პოსტი, თუმცა იმდენნი არიან, ამ ერთი ჰეკით შემოვიფარგლები.

(ვიკიპედიაზე არის ქართული სტატიის ნაწილი მათ შესახებ, აქ კი სისტემების შედარების ცხრილებია)

კოდის ფრაგმენტი, რაც ზევით ვახსენე, საიტზე სურათების ატვირთვას ეხებოდა. როგორც ჩანს ლინუქსის ფაილურ სისტემებს (ext2/ext3) შეზღუდვა აქვთ, რომ ერთ საქაღალდეში 32000-ზე მეტი ქვე საქაღალდის შენახვა არ შეიძლება. ანუ თუ მაგალითად, მომხმარებლის ფოტოების შესანახად ერთი საქაღალდე გაქვთ გამოყოფილი და იქ თითოეული იუზერისთვის ქვესაქაღალდეს ქმნით, 32000-ზე მეტი იუზერის შექმნის შემთხვევაში ამ საქაღალდეებს ვეღარ შექმნის.

ერთი გამოსავალი ისაა, რომ ფაილური სისტემა შეცვალოთ (როგორც წერენ, ReiserFS-ს ასეთი შეზღუდვა არ აქვს და ასობით ათასს ფაილსსაც მარტივად უმკლავდება), მაგრამ თუ სხვა მხრივ ხელს არ გიშლით, ჩემი აზრით უკეთესია უბრალოდ სხვანაირად დაანაწილოთ ფაილები და ისე შეინახოთ.

მაგალითად, შეიძლება root ფოლდერში შეინახოთ საქალდეები სახელად 10000, 20000, 30000, ხოლო თითოეულში მაქსიმამუმ 10000 ცალი საქაღალდე რომელიც შესაბამისად არის გადანომრილი (1,2,3,.. ). როდესაც საჭირო იქნება იმის დადგენა თუ რომელ გარე საქაღალდეში უნდა მოიძებნოს თქვენი ფოლდერი, მისი სახელის 10000-ზე მთელი გაყოფით და შემდეგ ისევ 10000-ზე გამრავლებით გარე ფოლდერის სახელს მიიღებთ.

შეზღუდვები რომც არ იყოს, ზოგი ფაილური სისტემა არ არის ოპტიმიზირებული რომ ბევრ ფაილიან ფოლდერში სწრაფად ჩაამატოს, ამოშალოს ან წაიკითხოს ფაილები. მაგალითად ლინუქსის ext2 და ext3 დირექტორიების და ფაილების იერარქიას ბმული სიების სახით ინახავდნენ და შესაბამისად იქ ძებნას O(n) დრო სჭირდებოდა. ზოგ შემთხვევაში პრობლემა არაა, მაგრამ როცა, თუნდაც, კეშის მსგავსი სტრუქტურები იყო შესანახი, ძალიან ანელებდა ეს ყველაფერს. შემდეგ დაამატეს მარტივი ხის სტრუქტურა  – HTree, რომელიც ext3-ში შეიძლება ”ჩაირთოს”, ext4-ს კი default-ად აქვს უკვე. სხვა ფაილური სისტემებიდან ბევრი B-tree-ის მონაცემთა სტრუქტურას იყენებს სწრაფი მუშაობისთვის. ამაზე ალბათ მოგვიანებით დავწერ.

იქით მივდიოდი, რომ უკეთესი წარმადობისთვის ჩვენმა აპლიკაციამაც შეიძლება შეუწყოს ხელი ოპერაციულ სისტემას. უკვე რამდენგანმე შემხვდა ჰეშირებას გამოყენება ფაილების მენეჯმენტის დროს. მაგალითად, რომ აიღოთ ფაილის სახელის ჰეში 910a90401e7bdc0452eea5630, ამ ჰეშის პირველი რამდენიმე სიმბოლო გამოიყენოთ საქაღალდეების იერარქიისთვის, ხოლო დანარჩენი ფაილის სახელისთვის.

91\0a\90401e7bdc0452eea5630.jpg

კარგი ჰეშ ფუნქციის შემთხვევაში საქაღალდეები და ფაილები დაახლოებით თანაბრად განაწილდება და ფოლდერები არ გადაიტვირთება. არც ფაილის მოძებნა იქნება მძიმე.

მაგალითად,  Squid (web proxy cache) ინახავს კეშირებულ ფაილებს მსგავსი სახით.

კოდის წერის სიჩქარის მნიშვნელოვნად გაუმჯობესება

არა მარტო კოდის 🙂

ალბათ უმეტესი თქვენგანი უკვე იყენებს მას ან მის ალტერნატივას. ზოგიერთ IDE-ს ჩადგმული აქვს მისი შესაძლებლობები.

მე კი მხოლოდ დღეს ვნახე Nettuts+ საიტზე და უკვე შემიყვარდა. ლაპარაკია Texter პროგრამაზე.

მისი საშუალებით სიტყვებს ან სიმბოლოებს ვაბამთ სრულ სკრიპტებს, კოდის ფრაგმენტებს, თუნდაც წერილის შაბლონებს და წერის დროს უკვე ამ სიტყვებს ვიყენებთ shortcut-ის როლში იმ დიდი ტექსტის ჩასასმელად.

არა მარტო ტექსტს ვაბამთ. შესაძლებელია მაკროსების წერაც. მაგალითად, თუ წინადადების ბოლოს გაგვახსენდა, რომ წინადადება <p></p> პარაგრაფის ტეგებში უნდა ჩაგვესვა, Texter-ს შეუძლია ისევ რაღაც წინასწარ განსაზღვრული shortcut-ით ეს ტეგები ჩაუსვას, თუ ამ shortcuts განვსაზღვრავთ მაკროსით: {HOME}<p> {END}</p>

ძალიან ზოგადად ვლაპარკობ, იმიტომ რომ ვფიქრობ ვიდეოში ყველაფერს დაწვრილებით ხსნის ჩემი ერთ-ერთი საყვარელი რედაქტორი – ჯეფრი ვეი. ვიდეო ამ ბმულზეა.

Hotstring-ის დამატება Texter-ში
Hotstring-ის დამატება Texter-ში

როგორც ჩანს LifeHacker-ის Texter-ის გარდა კიდევ არსებობს მისი მსგავსი პროგრამები, მაგრამ მე უკეთესი ვერ შევარჩიე. ამას კი ჯერჯერობით რაც ვუპოვე ერთადერთი ნაკლი უნიკოდია. არა მარტო ის, რომ უნიკოდი თვითონ პროგრამას არ ესმის, არამედ ხელსაც მიშლის, როცა სხვაგან ვწერ ქართულად და პროგრამის გათიშვა მიწევს.. მიუხედავად ამისა მაინც საშინლად მოსახერხებელია 😀

The NetBeans Collaboration Project

ამ პოსტის ესკიზი მას მერე დევს დრაფტებში, რაც Xray-იმ (იმედია არ მიწყენს) ერთობლივი მუშაობის იდეა გამოთქვა. ერთობლივ მუშაობაში კოდის ერთდროულად წერას ვგულისხმობ. წარმოიდგინეთ, რომ გახსნილი გაქვთ NetBeans IDE და რამდენიმე ადამიანი ერთდროულად არედაქტირებთ ერთსა და იმავე ფაილებს.

პირველად რომ ვცადეთ, ფრიად აღფრთოვანებული დავრჩი. დროის პრობლემების გამო, იშვიათად გვიწევდა შეხვედრა, თორემ pair programming და მისი ჯანი. არადა უკანასკნელი ძალიან მომწონს მისი ნაყოფიერების გამო. კოდი უმეტესად შეცდომების გარეშე გამოდის ხოლმე.

NetBeans-ის Developer Collaboration პლაგინი კი ზუსტად ‘remote’ pair programming-ის საშუალებას იძლევა. 🙂 თუ ასე შეიძლება დაერქვას.

რის შესაძლებლობას იძლევა?

მომხმარებლების ჯგუფის წევრებს შეუძლიათ უყურონ ერთსა და იმავე ფაილებს და ნებისმიერი მათგანის მიერ დარედაქტირების შედეგი real-time დროში დაინახონ. თან პროგრამა გიჩვენებთ, რომელი სტრიქონების ცვლილება მიმდინარეობს და რომელი მომხმარებლის მიერ.

პლაგინს მესენჯერიც აქვს ჩადგმული, რომელსაც სხვადასხვანაირად ფორმატირებული შეტყობინებების გაგზავნა/მიღება შეუძლია (ფორმატირებაში კოდის ფორმატირებას ვგულისხმობ. ანუ, იგივენაირად შეიძლება წერა, როგორც ჩვეულებრივ NetBeans IDE-ში – თავისი shortcut-ებით)

NetBeans Collaboration

გარემოს ასაწყობად საჭიროა:

1. Collaboration სერვერის დაყენება და დაკონფიგურირება (ასეთი სერვერი რამდენიმე არსებობს, თუმცა NetBeans-ის Developer Collaboration მოდულები კარგად არის შემოწმებული OpenFire XMPP სერვერთან ერთად სამუშაოდ, ამიტომ მის საიტზე ამ სერვერის დაყენებას გვირჩევენ და ინსტრუქციაც დევს).

2. NetBeans IDE-ში საჭიროა Developer Collaboration პლაგინის დაინსტალირება.

3. მომხმარებლების დამატება OpenFire-ის ადმინისტრატორის პანელიდან და შემდეგ ამ მომხმარებლების შესვლა (log in) NetBeans IDE-დან.

თამაში გამოცანებით

🙂 არა, მე არა.

ერთ ქართულ ბლოგზე გადავაწყდი თამაშს, რომელიც ბავშვობას მახსენებს :)) პატარა გამოცანებს ვწერდით და ბაღში ვმალავდით ხოლმე.. ერთის პასუხი იყო შემდეგის ადგილსამყოფელი. ანუ, ცნობილი თამაშის – ენქაუნთერის ბავშვური ვარიანტი 🙂

ამ ბლოგზეც (”თითქმის EXCLUSIVE!”)  მსგავსი თამაშია 🙂 საინტერესო კითხვები. თითოეულის პასუხი შემდეგი ტურის პაროლია.

მოკლედ, ისიამოვნეთ 🙂 და ბლოგის ავტორს კი დიდი მადლობა, კარგად ვიმხიარულეთ :)))

RAID მასივები

ამ საკითხზე სემინარი მქონდა მოსამზადებელი და ბარემ პოსტსაც მივუძღვნი 🙂

რა არის ეს RAID (Redundant Array of Independent Disks) და რისთვის გამოიყენება? : )

როგორ შევინახოთ ინფორმაცია სისტემის აგების დროს დამოკიდებულია თვითონ ამოცანაზე. რა გვჭირდება: დიდი რაოდენობით ჩაწერა, წაკითხვა, სისწრაფე, საიმედოობა?

მაგალითად, არსებობს ამოცანები, სადაც კრიტიკული მნიშვნელობა აქვს ინფორმაციის საიმედოდ შენახვას და მასზე წვდომის შესაძლებლობას დროის ნებისმიერ მომენტში. ანუ, დისკის დაზიანების დროს უნდა არსებობდეს მისი შემცვლელი იგივე ინფორმაციით და თანაც რაც შეიძლება სწრაფად.

არის ამოცანები, სადაც წარმადობა უფრო პრიორიტეტულია. მაგალითად, როდესაც სერვერიდან დიდი რაოდენობით ვიდეო ნაკადები მოდის.

თავდაპირველად RAID-ის ძირითადი იდეა იყო, რომ რამდენიმე მყარი დისკი გაეერთიანებინა დისკების მასივში და ამით გაეუმჯობესებინა წარმადობა, რომელიც ერთ დიდი ზომის დისკს ჰქონდა.

ახლა RAID-ის არქიტექტურული დიზაინებიდან ყველაზე გავრცელებულია 5 ვარიანტი:  RAID 0, RAID 1, RAID 5, RAID 6, RAID 10.

ისინი ძირითადად ორ მიზანს ემსახურებიან: მონაცემთა შენახვის საიმედოობის გაზრდას, შეტანა/გამოტანის (დისკზე ჩაწერა/წაკითხვის) წარმადობის გაზრდას.

განვიხილოთ თითოეული მათგანი:

RAID 0

ჩაწერის დროს მონაცემები იყოფა ფრაგმენტებად და ეს ფრაგმენტები სათითაოდ ნაწილდება მასივში შემავალ დისკებზე. წაკითხვის დროს კი ყველა დისკიდან ერთდროულად ხდება წაკითხვა.

raid0

up_iconრაც უფრო მეტი დისკია, უფრო მეტად იზრდება სისწრაფე. უხეშად რომ შევადარო, ეს იგივეა, წყლის არხიდან ერთის მაგივრად რამდენიმე მილი გამოვიყვანოთ. იგივე რაოდენობის წყალს უფრო მალე მივიღებთ.

up_iconარ ვკარგავთ ადგილს. მთლიანად ვიყენებთ დისკების მოცულობას ჩვენი ინფორმაციისთვის.

down_iconასეთი სტრუქტურის სისუსტე დისკის დაზიანების დროს ჩანს. საკმარისია ერთ-ერთი მათგანის ამოვარდნა, რომ მთელი მასივი გადასაგდებია. წარმოიდგინეთ, წიგნში ყოველ სიტყვას მისი მესამედი რომ ჩამოვაჭრათ. წიგნი გამოუსადეგარი გახდება. თანაც მისი აღდგენა შეუძლებელია.

Read more