ग्राफिकल फ़ाइल खोज उपयोगिताओं की तुलना में GNU इतनी तेज़ी से क्यों पाया जाता है?

Question

मैं एक ऐसी फाइल खोजने की कोशिश कर रहा हूं जो मेरे घर की निर्देशिका और सभी उपनिर्देशिकाओं में मौजूद नहीं है।

find ~/ -name "bogus"कुछ सेकंड के बाद मुझे वह जानकारी देता है, फिर भी केडीई के dolphinफ़ाइल प्रबंधक को ऐसा करने के लिए लगभग 3 मिनट की आवश्यकता होती है। यह गनोम केbeagle साथ मेरे पिछले अनुभव से मेल खाता है ।

findग्राफिकल सर्च (जो कि कमांडलाइन मापदंडों की तुलना में उपयोग करने के लिए अधिक सहज है) के पीछे उसी तेजी से करने का प्रबंधन कैसे करता है ?

Comments

मुझे नहीं पता कि "डॉल्फिन" क्या है, लेकिन क्या यह शायद फाइलों के अंदर भी दिखता है ?

— Kusalananda

यह केडीई से एक चित्रमय फ़ाइल प्रबंधक है: kde.org/applications/system/dolphin इसमें फ़ाइलों के अंदर खोज करने की क्षमता है, लेकिन मैंने इस विकल्प को इस छोटे परीक्षण के दौरान सक्षम नहीं किया।

— लाल

क्या आपने डॉल्फिन में एक से अधिक बार खोज की थी? यह पहली बार "अनुक्रमण" हो सकता है। और "ढूंढें" भी धीमी है। "का पता लगाने" अगर फाइल पिछली बार का पता लगाने के लिए डेटाबेस अनुक्रमित किया गया था ;-) से अधिक पुराना है की कोशिश करो

— Rinzwind

मैं locateअधिक से अधिक बार उपयोग करता हूं findऔर यह एक विशाल फ़ोल्डर में तेज है

— फुल्विक

जबकि locateफ़ाइलें खोजने के लिए वास्तव में बहुत अच्छा है, यह थोड़ा OT है, क्योंकि यह पूरी तरह से अलग दृष्टिकोण का उपयोग करता है: findऔर GUI जैसे उपकरण Dolphinफ़ाइल ट्री को मांग पर ट्रेस कर रहे हैं, जबकि locateपहले से बनाई गई इंडेक्स संरचना का उपयोग कर रहा है।

— माइकल शेफर्स

Answer 1

विशेष रूप से बालू के साथ डॉल्फिन को देखते हुए, यह अपने खोज डोमेन में प्रत्येक फ़ाइल के मेटाडेटा को देखने के लिए लगता है, भले ही आप एक साधारण फ़ाइल नाम खोज कर रहे हों। जब मैं file.soप्रक्रिया का पता लगाता हूं , तो मैं हर फाइल के लिए कॉल करता हूं lstat, getxattrऔर getxattrफिर ..प्रविष्टियों के लिए भी देखता हूं । ये सिस्टम कॉल मेटाडेटा को उस फ़ाइल के बारे में पुनः प्राप्त करता है जो फ़ाइल नाम से अलग स्थान पर संग्रहीत होती है (फ़ाइल नाम निर्देशिका सामग्री में संग्रहीत होता है, लेकिन मेटाडेटा इनोड में हैं )। फ़ाइल का मेटाडेटा क्वेरी करना कई बार सस्ता है क्योंकि डेटा डिस्क कैश में होगा, लेकिन मेटाडेटा को क्वेरी करने और मेटाडेटा को क्वेरी नहीं करने के बीच एक महत्वपूर्ण अंतर हो सकता है।

findबहुत अधिक चतुर है। यह अनावश्यक सिस्टम कॉल से बचने की कोशिश करता है। यह कॉल नहीं करेगा getxattrक्योंकि यह विस्तारित विशेषताओं के आधार पर खोज नहीं करता है। जब यह किसी निर्देशिका को ट्रेस कर रहा होता है, तो इसे lstatगैर-मिलान फ़ाइल नामों पर कॉल करने की आवश्यकता हो सकती है क्योंकि यह पुनरावर्ती खोज करने के लिए एक उपनिर्देशिका हो सकती है ( lstatयह सिस्टम कॉल है जो फ़ाइल मेटाडेटा को लौटाता है जिसमें फ़ाइल प्रकार जैसे कि नियमित / निर्देशिका / सिमलिंक /…) शामिल है। हालाँकि findइसका एक अनुकूलन है: यह जानता है कि एक निर्देशिका के पास अपनी लिंक गणना से कितनी उपनिर्देशिकाएँ हैं , और यह lstatएक बार कॉल करना बंद कर देता है क्योंकि यह जानता है कि यह सभी उपनिर्देशिकाओं का पता लगाया है। विशेष रूप से, पत्ती निर्देशिका में (कोई उपनिर्देशिका वाली निर्देशिका),findकेवल नामों की जाँच करता है, मेटाडेटा की नहीं। इसके अलावा कुछ फाइल सिस्टम निर्देशिका प्रविष्टि में फ़ाइल प्रकार की एक प्रतिलिपि रखते हैं ताकि findकॉल करने की आवश्यकता न हो, lstatयदि केवल वही जानकारी हो जिसकी उसे आवश्यकता है।

यदि आप findउन विकल्पों के साथ चलते हैं जिन्हें मेटाडेटा की जाँच की आवश्यकता होती है, तो यह अधिक lstatकॉल करेगा, लेकिन यह तब भी lstatकिसी फ़ाइल पर कॉल नहीं करेगा यदि उसे जानकारी की आवश्यकता नहीं है (उदाहरण के लिए क्योंकि फ़ाइल को पिछली स्थिति से बाहर रखा गया है नाम पर मेल)।

मुझे संदेह है कि अन्य जीयूआई खोज उपकरण जो findपहिया को फिर से संगठित करते हैं, कमांड लाइन उपयोगिता की तुलना में कम चतुर हैं जो अनुकूलन के दशकों से गुजरे हैं। डॉल्फिन, कम से कम, यदि आप "हर जगह" खोज के साथ डेटाबेस का उपयोग करने के लिए पर्याप्त चतुर हैं (सीमा के साथ जो यूआई में स्पष्ट नहीं है कि परिणाम पुराने हो सकते हैं)।

Comments

GNU खोज इतनी "चतुर" है कि यह कुछ फाइल सिस्टम प्रकारों पर कुछ फ़ाइलों को याद करती है। जीएनयू में अच्छी तरह से ज्ञात बग यह है कि यह अवैध धारणा बनाता है कि एक निर्देशिका की लिंक गणना 2 + number of sub-directories.यह फाइलसिस्टम के लिए काम करती है जो UNIX V7 फाइलसिस्टम से डिजाइन बग को लागू करती है, लेकिन सभी फाइल सिस्टम के लिए नहीं, क्योंकि यह पॉसकी आवश्यकता नहीं है। । यदि आप GNU मेक के लिए एक उपयोगी प्रदर्शन संख्या प्राप्त करना पसंद करते हैं, तो आपको -noleafGNU मेक को सही ढंग से व्यवहार करने के लिए बताने के लिए आदेश पर निर्दिष्ट करना होगा।

— विद्वान

@ सामान्य तौर पर, जीएनयू findमें वह बग बहुत समय पहले हो सकता था, लेकिन मुझे संदेह है कि आपको एक ऐसा मामला मिलेगा, जहां आपको -noleafआजकल हाथ से निर्दिष्ट करने की आवश्यकता है। AFAICT, लिनक्स पर कम से कम getdents()(और readdir ()) बताता है कि कौन सी फाइलें UDF, ISO-9660, btrfs पर निर्देशिका फाइलें हैं जिनके पास वास्तविक .या ..प्रविष्टियां नहीं हैं और findवहां ठीक व्यवहार करते हैं। क्या आप एक मामले के बारे में जानते हैं जहां GNU findसमस्या का प्रदर्शन करता है?

— स्टीफन चेज़लस

डेबियन से इस सड़े हुए जीनिसोइमेज का उपयोग "ग्राफ्ट-पॉइंट्स" का उपयोग करके रॉक रिज फाइलसिस्टम बनाने के लिए करें और एक निर्देशिका में लिंक गणना एक यादृच्छिक मूल्य है। चूंकि रॉक रिज एक लिंक गिनती और /। लागू करता है, इसलिए GNU खोज आमतौर पर इस तरह के एक फाइल सिस्टम पर सभी फ़ाइलों को नहीं मिलेगा।

— विद्वान

@ StéphaneChazelas: पिछली बार जब मैंने जाँच की (अपने गुरु की थीसिस के लिए), तो बग को ठीक से समझा जाता था 2 का मतलब पत्ती के बजाय <= 2. था। फाइलसिस्टम जो 2+ काउंटर को लागू नहीं करते हैं, निर्देशिका निर्देशिका के लिए सभी 1 रिटर्न काउंटर करते हैं। सब कुछ अच्छा है। अब अगर किसी दिन किसी ने एक फाइल सिस्टम बनाया है जो उन निर्देशिकाओं के लिए कड़ी है, जिनके पास यह संपत्ति नहीं है, तो किसी का दिन खराब होने वाला है।

— जोशुआ

@ सामान्य रूप से, मैं डेबियन पर genisoimage 1.1.11 के साथ ग्राफ्ट-पॉइंट्स और आरआर के साथ यादृच्छिक लिंक की संख्या प्राप्त करने में सक्षम नहीं था और यहां तक ​​कि अगर मैं लिंक मानों को यादृच्छिक मानों में बदलने के लिए आइसो छवि को बाइनरी-एडिट करता हूं, तो भी मुझे कोई फायदा नहीं हुआ जीएनयू के साथ समस्या find। और किसी भी स्थिति में, strace -vदिखाता है कि getdents()निर्देशिकाओं के लिए d_type = DT_DIR सही रूप से देता है, इसलिए GNU को लिंक लिंक ट्रिक का उपयोग नहीं करना पड़ता है।

— स्टीफन चेजालस