ერთ-ერთი საიტის კოდში შემხვდა 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) ინახავს კეშირებულ ფაილებს მსგავსი სახით.
მშვენიერი სტატია 🙂
ერთი კითხვა გამიჩნდა, ეს შეზღუდვა საქაღალდების რაოდენობას მხოლოდ ერთ დონეზე ეხება თუ მთლიანად ?
🙂 ერთ დონეზე. სხვა შემთხვევაში ქვე ფოლდერების სხვანაირად გადალაგებას აზრი დაეკარგებოდა.
ok გასაგებია, root ფოლდერის ხსნებამ დამაბნია 🙁