`Ls -s` प्रिंट" 0 "कब करता है

13

बेशक, यदि फ़ाइल खाली है test -s FILE, तो परीक्षण का मानक तरीका है , लेकिन हमारे ग्राहकों में से एक को इस तरह के परीक्षण वाली एक स्क्रिप्ट मिली है:

RETVAL=`ls -s ./log/cr_trig.log | awk '{print $1}'`
if test $RETVAL -ne 0
then
    echo "Badness: Log not empty"
    exit 25
fi

आपूर्तिकर्ता के दावों के साथ कि यह उन दो वातावरणों में काम करता है जिन्हें उन्होंने इसमें परीक्षण किया है। कहने की जरूरत नहीं है कि यह दोनों स्थानों पर बुरी तरह से विफल रहा है कि मैंने इसका परीक्षण किया।

तो, मैं उत्सुक हो गया। खाली फ़ाइलों के लिए ls -sप्रिंट कब होता है 0?

यह मेरा अब तक का निष्कर्ष है:

लिनक्स पर जीएफएस: 4
Linux पर ext4: 0
सोलारिस पर ZFS: 1
सोलारिस पर UFS: 0
AIX पर jfs: 0
HP-UX पर VxFS: 0
एचपी-यूएक्स पर एचएफएस: 0
मैक ओएस एक्स पर एचएफएस: 0

मैंने अभी तक नेटवर्क फ़ाइल सिस्टम की जांच नहीं की है।

प्रश्न: मैं दूसरों को कैसे समझा सकता हूं कि उनकी स्क्रिप्ट गलत है ?

मेरी राय में, "सही" संस्करण होगा:

if test ! -s ./log/cr_trig.log
then
    echo "Badness: Log not empty"
    exit 25
fi

filesystems shell-script ls compatibility

— MattBianco
स्रोत

5

बस उन्हें अपने परीक्षण दिखाएं। आपके पास कठिन डेटा है जो साबित करता है कि उनका परीक्षण पोर्टेबल नहीं है, आपको और क्या चाहिए?

— Mat

सबसे दिलचस्प सवालों में से एक मैंने इस सर्वर पर अब तक देखा है। बहुत बुरा केवल एक बिंदु खर्च कर सकता है।

— ktf

@ktf आप हमेशा एक इनाम दे सकते हैं।

— जो

6

बहुत दिलचस्प खोज। हालाँकि मैंने कभी ls -sयह जांचने के लिए उपयोग नहीं किया है कि कोई फ़ाइल खाली है या नहीं, मैंने मान लिया होगा, कि यह 0खाली फ़ाइलों के लिए भी रिपोर्ट करता है।

आपके प्रश्न के लिए: जैसा कि मैट ने पहले ही टिप्पणी की थी, उन्हें अपने परीक्षा परिणाम दिखाएं। उन्हें परिणामों की व्याख्या करने के लिए, बताएं कि ls -sफाइलसिस्टम में आवंटित ब्लॉकों की मात्रा रिपोर्ट करता है, बाइट्स में वास्तविक आकार नहीं। स्पष्ट रूप से कुछ फाइलसिस्टम कार्यान्वयन ब्लॉक को आवंटित करते हैं, भले ही उन्हें इनोड में केवल एक NULL पॉइंटर को संग्रहीत करने के बजाय किसी भी डेटा को संग्रहीत करने की आवश्यकता न हो।

इसके लिए स्पष्टीकरण प्रदर्शन-संबंधी हो सकता है। खाली रहने वाली फाइलें बनाने के लिए सामान्य प्रसंस्करण के लिए एक छूट है (मैंने देखा है सबसे सामान्य उपयोग स्थिति फ़ाइलों का निर्माण होगा जहां एक फ़ाइल की मौजूदगी सॉफ्टवेयर की एक निश्चित स्थिति का प्रतिनिधित्व करती है)।

लेकिन आम तौर पर बनाई गई एक फ़ाइल को जल्द ही कुछ डेटा मिलेगा, इसलिए एक निश्चित एफएस के डिजाइनरों ने मान लिया होगा कि यह फ़ाइल निर्माण पर एक डेटा ब्लॉक को तुरंत आवंटित करने का भुगतान करता है, इसलिए जब पहला डेटा आता है तो यह कार्य पहले से ही किया जाता है।

दूसरा कारण यह हो सकता है कि किसी फ़ाइल में अतीत में डेटा समाहित है जिसे मिटा दिया गया है। अंतिम डेटा ब्लॉक को मुक्त करने के बजाय उसी डेटा ब्लॉक को उसी फ़ाइल द्वारा पुन: उपयोग के लिए रखने के योग्य हो सकता है।

संपादित करें:

एक और कारण दिमाग में आया: फाइलसिस्टम जहाँ आपने मान पाया है> 0 ZFS , RAID + LVM + FS कार्यान्वयन और GFS , एक क्लस्टर फाइल सिस्टम। दोनों को फ़ाइल अखंडता को बनाए रखने के लिए मेटाडेटा संग्रहीत करना पड़ सकता है जो इनोड्स में संग्रहीत नहीं है। ऐसा हो सकता है कि ls -sइस मेटाडेटा के लिए आवंटित डेटा ब्लॉक में मायने रखता है।

— KTF
स्रोत

4

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

मुझे लगता है कि GFS को सिंक्रनाइज़ेशन / लॉक डेटा को अन्य गैर शून्य परिणाम के लिए स्टोर करना होगा।

— jlliagre
स्रोत

2

ls -s फ़ाइल के लिए आवंटित किए गए ब्लॉक की संख्या को रिपोर्ट करता है, जिसमें डायरेक्ट्री प्रविष्टि में सीधे संग्रहीत किए जाने वाले कुछ भी शामिल नहीं हैं।

ज्यादातर मामलों में, ब्लॉक की संख्या बाइट्स में विभाजित बाइट्स की संख्या को गोल करके विभाजित किया जाता है।

ब्लॉक की संख्या एक विरल फ़ाइल के लिए इससे कम हो सकती है । उदाहरण के लिए, अधिकांश फाइल सिस्टमों पर, यह 0 ब्लॉकों में फैले 8192-बाइट फ़ाइल का निर्माण करेगा:

$ perl -e 'truncate STDOUT, 8192' >a
$ ls -l a
-rw-r--r-- 1 gilles gilles 8192 Nov  1 21:32 a
$ ls -s a
0 a

इसके विपरीत, ब्लॉक की संख्या अधिक हो सकती है यदि फाइल सिस्टम फाइलों के लिए ब्लॉक का प्रचार करता है या मेटाडेटा को स्टोर करने के लिए ब्लॉक का उपयोग करता है। मुझे आश्चर्य नहीं है कि Zfs के पास फ़ाइल आकार और ब्लॉकों की संख्या के बीच एक गैर-स्पष्ट पत्राचार है, बड़ी संख्या में इसे प्रदान की जाने वाली सुविधाएँ और बड़े फाइल सिस्टम के प्रति इसकी अभिविन्यास; मुझे विवरण नहीं पता है, लेकिन ब्लॉक की संख्या न केवल फाइलों के आकार पर बल्कि उसके इतिहास पर भी निर्भर करती है (यदि आप किसी बड़ी फ़ाइल को रौंदने का नतीजा है तो खाली फाइल में एक से अधिक ब्लॉक हो सकते हैं)।

यह समझने के लिए कि क्यों ls -sगलत है: यह फ़ाइल के आकार की गणना नहीं करता है, लेकिन एक फाइलसिस्टम-निर्भर मात्रा। यह निर्धारित करने के लिए एक बहुत ही अप्रत्यक्ष तरीका है कि क्या एक फ़ाइल पहली जगह में खाली है, बाहरी उपकरण ( ls) और कुछ पार्सिंग की आवश्यकता है; इसके बजाय, उन्हें उपयोग करना चाहिए test -s, जिसके लिए कोई पार्सिंग की आवश्यकता नहीं होती है, और जो अनुरोध किया जाता है, वही करता है। अगर उन्हें लगता है कि ls -sयह परीक्षण करने का एक अच्छा तरीका है कि क्या कोई फ़ाइल खाली है, तो यह काम करने के लिए ओनस उन पर होना चाहिए।

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत