GFS2
Developer(s) | Red Hat |
---|---|
Full name | Global File System 2 |
Introduced | 2005 with Linux 2.6.19 |
Structures | |
Directory contents | Hashed (small directories stuffed into inode) |
File allocation | bitmap (resource groups) |
Bad blocks | No |
Limits | |
Max. number of files | Variable |
Max. filename length | 255 bytes |
Allowed characters in filenames | All except NUL |
Features | |
Dates recorded | attribute modification (ctime), modification (mtime), access (atime) |
Date resolution | Nanosecond |
Attributes | No-atime, journaled data (regular files only), inherit journaled data (directories only), synchronous-write, append-only, immutable, exhash (dirs only, read only) |
File system permissions | Unix permissions, ACLs and arbitrary security attributes |
Transparent compression | No |
Transparent encryption | No |
Data deduplication | across nodes only |
Other | |
Supported operating systems | Linux |
Developer(s) | Red Hat (formerly, Sistina Software) |
---|---|
Full name | Global File System |
Introduced | 1996 with IRIX (1996), Linux (1997) |
Structures | |
Directory contents | Hashed (small directories stuffed into inode) |
File allocation | bitmap (resource groups) |
Bad blocks | No |
Limits | |
Max. number of files | Variable |
Max. filename length | 255 bytes |
Allowed characters in filenames | All except NUL |
Features | |
Dates recorded | attribute modification (ctime), modification (mtime), access (atime) |
Date resolution | 1s |
Attributes | No-atime, journaled data (regular files only), inherit journaled data (directories only), synchronous-write, append-only, immutable, exhash (dirs only, read only) |
File system permissions | Unix permissions, ACLs |
Transparent compression | No |
Transparent encryption | No |
Data deduplication | across nodes only |
Other | |
Supported operating systems | IRIX (now obsolete), FreeBSD (now obsolete), Linux |
कम्प्यूटिंग में, ग्लोबल फाइल सिस्टम 2 या GFS2 एक क्लस्टर फ़ाइल सिस्टम #Shared-disk_file_system|साझा-डिस्क फ़ाइल सिस्टम लिनक्स कंप्यूटर क्लस्टर के लिए है। GFS2 एक क्लस्टर के सभी सदस्यों को एक ही साझा ब्लॉक भंडारण के लिए सीधी समवर्ती पहुंच की अनुमति देता है, क्लस्टर फ़ाइल सिस्टम # वितरित_फाइल_सिस्टम के विपरीत जो पूरे क्लस्टर में डेटा वितरित करता है। GFS2 को एक कंप्यूटर पर एक स्थानीय फाइल सिस्टम के रूप में भी इस्तेमाल किया जा सकता है।
GFS2 में कोई डिस्कनेक्टेड ऑपरेटिंग-मोड नहीं है, और कोई क्लाइंट या सर्वर भूमिका नहीं है। GFS2 क्लस्टर में सभी नोड पीयर के रूप में कार्य करते हैं। क्लस्टर में GFS2 का उपयोग करने के लिए साझा स्टोरेज तक पहुंच की अनुमति देने के लिए #हार्डवेयर और स्टोरेज तक पहुंच को नियंत्रित करने के लिए लॉक मैनेजर की आवश्यकता होती है। लॉक मैनेजर एक अलग मॉड्यूल के रूप में काम करता है: इस प्रकार GFS2 क्लस्टर (कंप्यूटिंग) कॉन्फ़िगरेशन के लिए वितरित ताला प्रबंधक (DLM) और स्थानीय फाइल सिस्टम के लिए नोलॉक लॉक मैनेजर का उपयोग कर सकता है। GFS के पुराने संस्करण भी GULM का समर्थन करते हैं, जो एक सर्वर-आधारित लॉक मैनेजर है जो फेलओवर के माध्यम से अतिरेक को लागू करता है।
GFS और GFS2 मुफ्त सॉफ्टवेयर हैं, जिन्हें जीएनयू जनरल पब्लिक लाइसेंस की शर्तों के तहत वितरित किया जाता है।[1][2]
इतिहास
GFS का विकास 1995 में शुरू हुआ और मूल रूप से मिनेसोटा विश्वविद्यालय के प्रोफेसर मैथ्यू ओ'कीफ और छात्रों के एक समूह द्वारा विकसित किया गया था।[3] यह मूल रूप से सिलिकॉन ग्राफिक्स, इंक. के IRIX ऑपरेटिंग सिस्टम के लिए लिखा गया था, लेकिन 1998 में इसे लिनक्स में पोर्ट किया गया था क्योंकि खुला स्रोत सॉफ्टवेयर कोड ने एक अधिक सुविधाजनक विकास मंच प्रदान किया था। 1999 के अंत में/2000 की शुरुआत में इसने सिस्टिन सॉफ्टवेयर के लिए अपना रास्ता बनाया, जहां यह एक ओपन-सोर्स मॉडल के रूप में कुछ समय के लिए रहा। ओपन-सोर्स प्रोजेक्ट। 2001 में, सिस्टिना ने GFS को एक मालिकाना उत्पाद बनाने का विकल्प चुना।
डेवलपर्स ने ओपनजीएफएस को जीएफएस के अंतिम सार्वजनिक रिलीज से हटा दिया और फिर इसे ओपनडीएलएम के साथ काम करने की अनुमति देने वाले अपडेट शामिल करने के लिए आगे बढ़ाया। लेकिन OpenGFS और OpenDLM समाप्त हो गए, क्योंकि Red Hat ने दिसंबर 2003 में सिस्टिना को खरीद लिया और जून 2004 के अंत में GNU जनरल पब्लिक लाइसेंस के तहत GFS और कई क्लस्टर-बुनियादी ढांचे के टुकड़े जारी किए।
Red Hat ने बाद में बग-फिक्सिंग और स्थिरीकरण की दिशा में आगे के विकास को वित्तपोषित किया। एक और विकास, GFS2[4][5] GFS से प्राप्त होता है और Linux 2.6.19 में इसके वितरित लॉक प्रबंधक (GFS के साथ साझा) के साथ शामिल किया गया था। Red Hat Enterprise Linux 5.2 में GFS2 को मूल्यांकन उद्देश्यों के लिए कर्नेल मॉड्यूल के रूप में शामिल किया गया है। 5.3 अद्यतन के साथ, GFS2 कर्नेल पैकेज का हिस्सा बन गया।
GFS2 फेडोरा (ऑपरेटिंग सिस्टम), Red Hat Enterprise Linux और संबंधित CentOS Linux वितरण का हिस्सा है। Red Hat Enterprise Linux के शीर्ष पर पूरी तरह से समर्थित GFS2 को चलाने के लिए उपयोगकर्ता व्यावसायिक समर्थन खरीद सकते हैं। Red Hat Enterprise Linux 8.3 के रूप में, GFS2 क्लाउड कम्प्यूटिंग वातावरण में समर्थित है जिसमें साझा स्टोरेज डिवाइस उपलब्ध हैं।[6] निम्नलिखित सूची में कुछ संस्करण संख्याओं और शुरू की गई प्रमुख विशेषताओं का सारांश दिया गया है:
- v1.0 (1996) केवल सिलिकॉन ग्राफिक्स IRIX
- v3.0 लिनक्स पोर्ट
- v4 जर्नलिंग फाइल सिस्टम
- v5 रिडंडेंट लॉक मैनेजर
- v6.1 (2005) वितरित ताला प्रबंधक
- Linux 2.6.19 - GFS2 और DLM लिनक्स कर्नेल में विलय
- Red Hat Enterprise Linux|Red Hat Enterprise Linux 5.3 पहला पूर्णतः समर्थित GFS2 जारी करता है
हार्डवेयर
GFS और GFS2 का डिज़ाइन संरक्षण क्षेत्र नियंत्रण कार्य जैसे वातावरण को लक्षित करता है। यद्यपि उन्हें एकल नोड फ़ाइल सिस्टम के रूप में उपयोग करना संभव है, पूर्ण सुविधा-सेट के लिए एक SAN की आवश्यकता होती है। यह iSCSI, Fibrechannel, [[ईथरनेट पर एटीए]], या किसी अन्य डिवाइस का रूप ले सकता है, जिसे लिनक्स के तहत कई नोड्स द्वारा साझा किए गए ब्लॉक डिवाइस के रूप में प्रस्तुत किया जा सकता है, उदाहरण के लिए एक DRBD डिवाइस।
डिस्ट्रीब्यूटेड लॉक मैनेजर को एक इंटरनेट प्रोटोकॉल आधारित नेटवर्क की आवश्यकता होती है, जिस पर संचार किया जा सके। यह आम तौर पर सिर्फ ईथरनेट है, लेकिन फिर से, कई अन्य संभावित समाधान हैं। सैन की पसंद के आधार पर, इसे जोड़ना संभव हो सकता है, लेकिन सामान्य अभ्यास[citation needed] डिस्ट्रीब्यूटेड लॉक मैनेजर और स्टोरेज के लिए अलग नेटवर्क शामिल करता है।
जीएफएस को किसी प्रकार की बाड़ लगाने (कंप्यूटिंग) तंत्र की आवश्यकता होती है। यह स्वयं GFS/GFS2 के बजाय क्लस्टर अवसंरचना की आवश्यकता है, लेकिन यह सभी मल्टी-नोड क्लस्टर के लिए आवश्यक है। सामान्य विकल्पों में पावर स्विच और रिमोट एक्सेस कंट्रोलर (जैसे डेल डीआरएसी, बुद्धिमान मंच प्रबंधन इंटरफ़ेस , या एचपी इंटीग्रेटेड लाइट्स-आउट) शामिल हैं। वर्चुअल और हाइपरविजर-आधारित फेंसिंग तंत्र का भी उपयोग किया जा सकता है। फ़ेंसिंग (कंप्यूटिंग) का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि एक नोड जिसे क्लस्टर विफल मानता है, अचानक फिर से काम करना शुरू नहीं कर सकता है जबकि दूसरा नोड विफल नोड के लिए जर्नल को पुनर्प्राप्त कर रहा है। पुनर्प्राप्ति पूर्ण होने के बाद यह वैकल्पिक रूप से विफल नोड को स्वचालित रूप से पुनरारंभ कर सकता है।
एक स्थानीय फाइल सिस्टम से अंतर
हालांकि GFS/GFS2 के डिजाइनरों का लक्ष्य एक स्थानीय फाइल सिस्टम का बारीकी से अनुकरण करना है, इसके बारे में जागरूक होने के लिए कई अंतर हैं। इनमें से कुछ मौजूदा फाइलसिस्टम इंटरफेस के कारण हैं जो क्लस्टर से संबंधित जानकारी को पास करने की अनुमति नहीं देते हैं। कुछ उन सुविधाओं को कुशलता से एक क्लस्टर तरीके से लागू करने की कठिनाई से उत्पन्न होते हैं। उदाहरण के लिए:
- यूनिक्स में फाइल लॉकिंग#जीएफएस/जीएफएस2 पर फ्लॉक() सिस्टम कॉल सिग्नल (कंप्यूटिंग) द्वारा बाधित नहीं है।
- फ़ाइल लॉकिंग # UNIX में | fcntl () F_GETLK सिस्टम कॉल किसी भी ब्लॉकिंग लॉक का PID लौटाता है। चूंकि यह एक क्लस्टर फाइल सिस्टम है, इसलिए पीआईडी किसी भी नोड पर एक प्रक्रिया को संदर्भित कर सकता है, जिसमें फाइल सिस्टम आरोहित है। चूंकि इस इंटरफ़ेस का उद्देश्य ब्लॉकिंग प्रक्रिया को सिग्नल भेजने की अनुमति देना है, यह अब संभव नहीं है।
- पट्टे लॉक_डीएलएम (क्लस्टर) लॉक मॉड्यूल के साथ समर्थित नहीं हैं, लेकिन स्थानीय फाइल सिस्टम के रूप में उपयोग किए जाने पर उनका समर्थन किया जाता है
- dnotify एक ही नोड के आधार पर काम करेगा, लेकिन GFS/GFS2 के साथ इसके उपयोग की अनुशंसा नहीं की जाती है
- inotify भी एक ही नोड के आधार पर काम करेगा, और यह भी अनुशंसित नहीं है (लेकिन यह भविष्य में समर्थित हो सकता है)
- ब्याह (सिस्टम कॉल) केवल GFS2 पर समर्थित है
अन्य मुख्य अंतर, और एक जो सभी समान क्लस्टर फ़ाइल सिस्टम द्वारा साझा किया जाता है, वह यह है कि कैश नियंत्रण तंत्र, जिसे GFS/GFS2 के लिए glocks (स्पष्ट जी-लॉक) के रूप में जाना जाता है, पूरे क्लस्टर पर प्रभाव डालता है। फाइलसिस्टम पर प्रत्येक इनोड में दो ग्लॉक जुड़े होते हैं। एक (जिसे आईओपेन ग्लॉक कहा जाता है) ट्रैक करता है कि किन प्रक्रियाओं में इनोड खुला है। दूसरा (इनोड ग्लॉक) उस इनोड से संबंधित कैश को नियंत्रित करता है। एक ग्लॉक में चार अवस्थाएँ होती हैं, UN (अनलॉक), SH (साझा - एक रीड लॉक), DF (स्थगित - SH के साथ असंगत एक रीड लॉक) और EX (अनन्य)। चार मोड में से प्रत्येक सीधे एक वितरित लॉक मैनेजर लॉक मोड में मैप करता है।
EX मोड में होने पर, डेटा और फ़ाइल सिस्टम # मेटाडेटा (जो गंदा हो सकता है, यानी फ़ाइल सिस्टम पर वापस लिखने की प्रतीक्षा कर रहा है) को कैश करने के लिए एक इनोड की अनुमति है। SH मोड में, इनोड डेटा और मेटाडेटा को कैश कर सकता है, लेकिन यह गंदा नहीं होना चाहिए। DF मोड में, इनोड को केवल मेटाडेटा को कैश करने की अनुमति है, और फिर यह गंदा नहीं होना चाहिए। DF मोड का उपयोग केवल प्रत्यक्ष I/O के लिए किया जाता है। यूएन मोड में, इनोड को किसी मेटाडेटा को कैश नहीं करना चाहिए।
एक इनोड के डेटा या मेटाडेटा को बदलने वाले ऑपरेशन एक दूसरे के साथ हस्तक्षेप नहीं करते हैं, इसके लिए EX लॉक का उपयोग किया जाता है। इसका मतलब यह है कि कुछ संचालन, जैसे कि एक ही निर्देशिका से फ़ाइलों को बनाना/अनलिंक करना और उसी फ़ाइल को लिखना सामान्य रूप से क्लस्टर में एक नोड तक सीमित होना चाहिए। बेशक, इन ऑपरेशनों को कई नोड्स से करना उम्मीद के मुताबिक काम करेगा, लेकिन कैश को बार-बार फ्लश करने की आवश्यकता के कारण, यह बहुत कुशल नहीं होगा।
GFS/GFS2 प्रदर्शन के बारे में सबसे अधिक बार पूछा जाने वाला एकमात्र प्रश्न यह है कि ईमेल सर्वर के साथ प्रदर्शन खराब क्यों हो सकता है। समाधान यह है कि मेल स्पूल को अलग-अलग निर्देशिकाओं में तोड़ दिया जाए और प्रत्येक नोड को पढ़ने और लिखने के लिए (जहाँ तक संभव हो) रखने की कोशिश की जाए और निर्देशिकाओं के एक निजी सेट को लिखा जाए।
जर्नलिंग
GFS और GFS2 दोनों जर्नल फ़ाइल सिस्टम हैं; और GFS2 जर्नलिंग मोड के समान सेट का समर्थन करता है जैसे ext3। डेटा = राइटबैक मोड में, केवल मेटाडेटा को जर्नल किया जाता है। यह जीएफएस द्वारा समर्थित एकमात्र मोड है, हालांकि व्यक्तिगत डेटा-फाइलों पर जर्नलिंग को चालू करना संभव है, लेकिन केवल तब जब वे शून्य आकार के हों। GFS में जर्नल की गई फ़ाइलों पर कई प्रतिबंध लगाए गए हैं, जैसे mmap या सेंडफाइल सिस्टम कॉल के लिए कोई समर्थन नहीं है, वे नियमित फाइलों से अलग ऑन-डिस्क प्रारूप का भी उपयोग करते हैं। एक इनहेरिट-जर्नल एट्रिब्यूट भी है, जो एक डायरेक्टरी पर सेट होने पर उस डायरेक्टरी के भीतर बनाई गई सभी फाइलों (और सब-डायरेक्टरीज) को जर्नल (या इनहेरिट-जर्नल, क्रमशः) फ्लैग सेट करने का कारण बनता है। इसका उपयोग data=journal माउंट विकल्प के बजाय किया जा सकता है जो ext3 का समर्थन करता है (और GFS/GFS2 नहीं करता है)।
GFS2 भी data=ordered mode का समर्थन करता है जो data=writeback के समान है सिवाय इसके कि गंदे डेटा को प्रत्येक जर्नल फ्लश पूरा होने से पहले सिंक किया जाता है। यह सुनिश्चित करता है कि नए आकार को रिकॉर्ड करने के लिए मेटाडेटा को अपडेट करने से पहले ब्लॉक जो एक इनोड में जोड़े गए हैं, उनकी सामग्री डिस्क में वापस सिंक हो जाएगी और इस प्रकार नोड विफलता स्थितियों के तहत फ़ाइल में दिखाई देने वाले गैर-प्रारंभिक ब्लॉक को रोकता है। डिफ़ॉल्ट जर्नलिंग मोड है data=ordered, ext3 के डिफ़ॉल्ट से मिलान करने के लिए।
As of 2010[update], GFS2 अभी तक data=journal मोड का समर्थन नहीं करता है, लेकिन यह (GFS के विपरीत) नियमित और जर्नल की गई फ़ाइलों दोनों के लिए समान ऑन-डिस्क प्रारूप का उपयोग करता है, और यह समान जर्नलेड और इनहेरिट-जर्नल विशेषताओं का भी समर्थन करता है। GFS2 उन प्रतिबंधों में भी ढील देता है जब किसी फ़ाइल की जर्नल विशेषता किसी भी समय बदली जा सकती है जब फ़ाइल खुली नहीं होती है (ext3 के समान भी)।
प्रदर्शन कारणों से, GFS और GFS2 में प्रत्येक नोड का अपना जर्नल है। GFS में पत्रिकाएँ डिस्क विस्तार हैं, GFS2 में पत्रिकाएँ केवल नियमित फ़ाइलें हैं। किसी एक समय में फ़ाइल सिस्टम को आरोहित करने वाले नोड की संख्या उपलब्ध जर्नल की संख्या द्वारा सीमित होती है।
== GFS == की तुलना में GFS2 की विशेषताएं
GFS2 कई नई सुविधाएँ जोड़ता है जो GFS में नहीं हैं। यहां उन सुविधाओं का सारांश दिया गया है जिनका इस पृष्ठ के दाईं ओर स्थित बॉक्स में पहले से उल्लेख नहीं किया गया है:
- मेटाडेटा फाइल सिस्टम (वास्तव में एक अलग रूट) - नीचे #Compatibility और GFS2 मेटा फाइल सिस्टम देखें
- GFS2 विशिष्ट ट्रेस पॉइंट कर्नेल 2.6.32 के बाद से उपलब्ध हैं
- XFS-शैली कोटा इंटरफ़ेस GFS2 में कर्नेल 2.6.33 से उपलब्ध है
- कैशिंग ACL 2.6.33 से GFS2 में उपलब्ध है
- GFS2 थिन प्रोविजनिंग/SCSI TRIM रिक्वेस्ट के लिए डिस्कार्ड रिक्वेस्ट जनरेशन को सपोर्ट करता है
- GFS2 I/O बाधाओं का समर्थन करता है (डिफ़ॉल्ट रूप से, यह मानते हुए कि अंतर्निहित डिवाइस इसका समर्थन करता है। कर्नेल 2.6.33 और ऊपर से कॉन्फ़िगर करने योग्य)
- FIEMAP ioctl (डिस्क पर इनोड्स की मैपिंग क्वेरी करने के लिए)
- ब्याह (सिस्टम कॉल) समर्थन
- जर्नल की गई फ़ाइलों के लिए एमएमएपी/स्प्लिस समर्थन (नियमित फ़ाइलों के लिए डिस्क प्रारूप पर उसी का उपयोग करके सक्षम)
- बहुत कम ट्यूनेबल (सेट-अप को कम जटिल बनाना)
- आदेशित लेखन मोड (ext3 के अनुसार, GFS में केवल राइटबैक मोड है)
संगतता और GFS2 मेटा फ़ाइल सिस्टम
GFS2 को डिज़ाइन किया गया था ताकि GFS से अपग्रेड करना एक सरल प्रक्रिया हो। इसके लिए, अधिकांश ऑन-डिस्क संरचना जीएफएस के समान ही बनी हुई है, जिसमें एंडियननेस#बिग-एंडियन|बिग-एंडियन बाइट ऑर्डरिंग शामिल है। हालांकि कुछ अंतर हैं:
- GFS2 में एक मेटा फ़ाइल सिस्टम है जिसके माध्यम से सिस्टम फ़ाइलों तक पहुँचने की प्रक्रियाएँ होती हैं
- GFS2 जर्नल की गई फ़ाइलों के लिए उसी ऑन-डिस्क फ़ॉर्मेट का उपयोग करता है जो नियमित फ़ाइलों के लिए होता है
- GFS2 पत्रिकाओं के लिए नियमित (सिस्टम) फ़ाइलों का उपयोग करता है, जबकि GFS विशेष विस्तार का उपयोग करता है
- GFS2 में कुछ और हैper_node सिस्टम फ़ाइलें
- इनोड का लेआउट (थोड़ा सा) अलग है
- अप्रत्यक्ष ब्लॉकों का लेआउट थोड़ा भिन्न होता है
GFS और GFS2 के जर्नलिंग सिस्टम एक दूसरे के साथ संगत नहीं हैं। उन्नयन एक उपकरण के माध्यम से संभव है (gfs2_convert) जो मेटाडेटा को अद्यतन करने के लिए फ़ाइल सिस्टम के साथ ऑफ़लाइन चलाया जाता है। जीएफएस पत्रिकाओं में कुछ अतिरिक्त ब्लॉकों का उपयोग (बहुत छोटा) बनाने के लिए किया जाता है per_node फ़ाइलें अद्यतन प्रक्रिया के दौरान GFS2 के लिए आवश्यक हैं। अधिकांश डेटा जगह में रहता है।
GFS2 मेटा फाइल सिस्टम अपने आप में एक फाइल सिस्टम नहीं है, बल्कि मुख्य फाइल सिस्टम की एक वैकल्पिक मूल निर्देशिका है। हालांकि यह एक सामान्य फ़ाइल सिस्टम की तरह व्यवहार करता है, इसकी सामग्री GFS2 द्वारा उपयोग की जाने वाली विभिन्न सिस्टम फ़ाइलें हैं, और आम तौर पर उपयोगकर्ताओं को कभी भी इसे देखने की आवश्यकता नहीं होती है। GFS2 उपयोगिताओं पर्दे के पीछे, आवश्यकतानुसार मेटा फ़ाइल सिस्टम को माउंट (कंप्यूटिंग) और अनमाउंट करती हैं।
यह भी देखें
- फाइल सिस्टम की तुलना
- सामान्य समानांतर फाइल सिस्टम, ZFS, VxFS
- चमक (फाइल सिस्टम)
- ग्लस्टरएफएस
- फ़ाइल सिस्टम की सूची
- ओसीएफएस2
- क्यूएफएस
- सैन फाइल सिस्टम
- बाड़ लगाना (कम्प्यूटिंग)
- ओपन-शेयररूट
- सेफ (सॉफ्टवेयर)
संदर्भ
- ↑
Teigland, David (29 June 2004). "Symmetric Cluster Architecture and Component Technical Specifications" (PDF). Red Hat Inc. Retrieved 2007-08-03.
{{cite journal}}
: Cite journal requires|journal=
(help) - ↑ Soltis, Steven R.; Erickson, Grant M.; Preslan, Kenneth W. (1997). "The Global File System: A File System for Shared Disk Storage" (PDF). IEEE Transactions on Parallel and Distributed Systems. Archived from the original (PDF) on 2004-04-15.
- ↑ OpenGFS Data sharing with a GFS storage cluster
- ↑ Whitehouse, Steven (27–30 June 2007). "The GFS2 Filesystem" (PDF). Proceedings of the Linux Symposium 2007. Ottawa, Ontario, Canada. pp. 253–259.
- ↑ Whitehouse, Steven (13–17 July 2009). "Testing and verification of cluster filesystems" (PDF). Proceedings of the Linux Symposium 2009. Montreal, Quebec, Canada. pp. 311–317.
- ↑ "Red Hat लचीला भंडारण को सार्वजनिक क्लाउड पर लाना". www.redhat.com. Retrieved 19 February 2021.
बाहरी संबंध
- Templates that generate short descriptions
- Articles with unsourced statements from July 2010
- Collapse templates
- Navigational boxes
- Navigational boxes without horizontal lists
- Sidebars with styles needing conversion
- Templates generating microformats
- Templates that are not mobile friendly
- Wikipedia metatemplates
- लिनक्स कर्नेल द्वारा समर्थित वितरित फाइल सिस्टम
- रेड हैट सॉफ्टवेयर
- साझा डिस्क फ़ाइल सिस्टम
- मिनेसोटा सॉफ्टवेयर विश्वविद्यालय
- लिनक्स के लिए वर्चुअलाइजेशन सॉफ्टवेयर
- Machine Translated Page
- Created On 18/06/2023