The development of artificial intelligence has raised ethical concerns.

செயற்கை நுண்ணறிவின் வளர்ச்சி நெறிமுறை சார்ந்த கவலைகளை எழுப்பியுள்ளது.


Despite the challenges, the team persevered and succeeded.

சவால்கள் இருந்தபோதிலும், குழு விடாமுயற்சியுடன் செயல்பட்டு வெற்றி பெற்றது.


The project's success depended on meticulous planning and execution.

திட்டத்தின் வெற்றி நுணுக்கமான திட்டமிடல் மற்றும் செயல்படுத்துதலைப் பொறுத்தது.


The economic forecast predicts a period of slow growth.

பொருளாதார முன்னறிவிப்பு மெதுவான வளர்ச்சியை முன்னறிவிக்கிறது.


The intricate details of the investigation were revealed.

விசாரணையின் சிக்கலான விவரங்கள் வெளிப்படுத்தப்பட்டன.


The implementation of the new system required extensive training.

புதிய அமைப்பை செயல்படுத்துவதற்கு விரிவான பயிற்சி தேவைப்பட்டது.


The consumer waits for a buffer to become filled before using it.

நுகர்வோர் அதைப் பயன்படுத்துவதற்கு முன்பு ஒரு இடையகம் நிரப்பப்படுவதற்காகக் காத்திருப்பார்.


Imagine there are two threads, a producer and a consumer.

உற்பத்தியாளரும், நுகர்வோரும் என இரண்டு திரெட்கள் இருப்பதாகக் கற்பனை செய்து கொள்ளுங்கள்.


The producer will put a data value into the first entry of buffer.

உற்பத்தியாளர் தரவு மதிப்பை இடையகத்தின் முதல் உள்ளீட்டில் வைப்பார்.


This is a no-no; we don’t want any data from the producer to be lost.

இது கூடாது; உற்பத்தியாளரிடமிருந்து எந்த தரவும் இழக்கப்படுவதை நாங்கள் விரும்பவில்லை.


The filling of a buffer and incrementing of the index into the buffer is a critical section.

ஒரு இடையகத்தை நிரப்புவதும், இடையகத்தில் குறியீட்டை அதிகரிப்பதும் ஒரு முக்கியமான பகுதியாகும்.


The consumer acquires the mutex and is waiting for the someone to signal full.

நுகர்வோர் மியூட்டெக்ஸைப் பெறுகிறார், மேலும் யாராவது முழுமையைக் குறிக்கக் காத்திருக்கிறார்.


The producer could signal full but is waiting for the mutex.

உற்பத்தியாளர் முழுமையைக் குறிக்க முடியும், ஆனால் மியூட்டெக்ஸுக்காகக் காத்திருக்கிறார்.


The result is a simple and working bounded buffer, a commonly-used pattern in multi-threaded programs.

இதன் விளைவாக ஒரு எளிய மற்றும் வேலை செய்யும் வரம்புக்குட்பட்ட இடையகம், இது பல திரெட் நிரல்களில் பொதுவாகப் பயன்படுத்தப்படும் ஒரு வடிவமாகும்.


They often add more overhead and thus do not end up speeding up performance.

அவை பெரும்பாலும் அதிக மேல்நிலையைச் சேர்க்கின்றன, இதனால் செயல்திறனை அதிகரிக்காது.


The basic setup for the problem is this: assume there are five “philosophers” sitting around a table.

பிரச்சனைக்கான அடிப்படை அமைப்பு இதுதான்: ஒரு மேசையில் அமர்ந்திருக்கும் ஐந்து “தத்துவஞானிகள்” இருப்பதாகக் கருதுங்கள்.


In order to eat, a philosopher needs two forks, both the one on their left and the one on their right.

சாப்பிடுவதற்காக, ஒரு தத்துவஞானிக்கு இரண்டு முட்கரண்டிகள் தேவை, இடதுபுறத்தில் ஒன்று மற்றும் வலதுபுறத்தில் ஒன்று.


The key challenge, then, is to write the routines getforks() and putforks() such that there is no deadlock.

முக்கியமான சவால் என்னவென்றால், getforks() மற்றும் putforks() ஆகிய நடைமுறைகளை எழுதுவதாகும், இதனால் எந்த முட்டுக்கட்டையும் ஏற்படாது.


If each philosopher happens to grab the fork on their left before any philosopher can grab the fork on their right, each will be stuck.

ஒவ்வொரு தத்துவஞானியும் தங்கள் இடதுபுறத்தில் உள்ள முட்கரண்டியைப் பிடித்துக் கொண்டால், எந்த தத்துவஞானியும் தங்கள் வலதுபுறத்தில் உள்ள முட்கரண்டியைப் பிடிப்பதற்கு முன், ஒவ்வொருவரும் சிக்கிக் கொள்வார்கள்.


The simplest way to attack this problem is to change how forks are acquired by at least one of the philosophers.

இந்த சிக்கலைத் தாக்குவதற்கான மிக எளிய வழி, குறைந்தது ஒரு தத்துவஞானியால் முட்கரண்டிகள் எவ்வாறு பெறப்படுகின்றன என்பதை மாற்றுவதாகும்.


There are other “famous” problems like this one, e.g., the cigarette smoker’s problem or the sleeping barber problem.

சிகரெட் புகைப்பவரின் பிரச்சனை அல்லது தூங்கும் முடிதிருத்துபவரின் பிரச்சனை போன்ற இதுபோன்ற “பிரபலமான” பிரச்சனைகளும் உள்ளன.


Semaphores are a powerful and flexible primitive for writing concurrent programs.

செமாபோர்கள் ஒரே நேரத்தில் இயங்கும் நிரல்களை எழுதுவதற்கான ஒரு சக்திவாய்ந்த மற்றும் நெகிழ்வான அடிப்படை ஆகும்.


In this chapter, we have presented just a few classic problems and solutions.

இந்த அத்தியாயத்தில், சில கிளாசிக் பிரச்சனைகளையும் தீர்வுகளையும் நாங்கள் வழங்கியுள்ளோம்.


Becoming a real concurrency expert takes years of effort.

உண்மையான ஒரே நேரத்தில் இயங்கும் நிபுணராக மாறுவதற்கு பல வருட முயற்சி தேவை.


Concurrency bugs tend to come in a variety of common patterns.

ஒரே நேரத்தில் இயங்கும் பிழைகள் பொதுவான வடிவங்களில் வர முனைகின்றன.


Knowing which ones to look out for is the first step to writing more robust, correct concurrent code.

எந்தெந்தவற்றை கவனிக்க வேண்டும் என்பதை அறிவது, மிகவும் வலுவான, சரியான ஒரே நேரத்தில் இயங்கும் குறியீட்டை எழுதுவதற்கான முதல் படியாகும்.


The study focuses on four major and important open-source applications.

இந்த ஆய்வு நான்கு முக்கிய மற்றும் முக்கியமான திறந்த மூல பயன்பாடுகளில் கவனம் செலுத்துகிறது.


Understanding these results can help you understand what types of problems actually occur in mature code bases.

இந்த முடிவுகளைப் புரிந்துகொள்வது, முதிர்ந்த குறியீடு தளங்களில் உண்மையில் என்ன வகையான சிக்கல்கள் ஏற்படுகின்றன என்பதைப் புரிந்துகொள்ள உதவும்.


Table 32.1 shows a summary of the bugs Lu and colleagues studied.

அட்டவணை 32.1, லூ மற்றும் அவரது சக ஊழியர்கள் ஆய்வு செய்த பிழைகளின் சுருக்கத்தைக் காட்டுகிறது.


From the table, you can see that there were 105 total bugs, most of which were not deadlock.

அட்டவணையில் இருந்து, மொத்தம் 105 பிழைகள் இருந்தன, அவற்றில் பெரும்பாலானவை முட்டுக்கட்டை அல்ல என்பதை நீங்கள் காணலாம்.


We now dive into these different classes of bugs a bit more deeply.

நாம் இப்போது இந்த வெவ்வேறு வகையான பிழைகளை இன்னும் ஆழமாக ஆராய்வோம்.


For the first class of non-deadlock bugs, we use examples from the study to drive our discussion.

முதலாவது முட்டுக்கட்டை அல்லாத பிழைகளுக்கு, எங்கள் விவாதத்தை இயக்குவதற்கு ஆய்வில் இருந்து எடுத்துக்காட்டுகளைப் பயன்படுத்துகிறோம்.


The first type of problem encountered is referred to as an atomicity violation.

சந்தித்த முதல் வகை சிக்கல் அணுசக்தி மீறல் என்று அழைக்கப்படுகிறது.


Clearly, if the first thread performs the check but then is interrupted before the call to fputs, the second thread could run in-between.

நிச்சயமாக, முதல் திரெட் சரிபார்ப்பை மேற்கொண்டால், ஆனால் fputs க்கு அழைப்பதற்கு முன் குறுக்கிடப்பட்டால், இரண்டாவது திரெட் இடையில் இயங்கக்கூடும்.


The more formal definition of an atomicity violation is this: “The desired serializability among multiple memory accesses is violated.

அணுசக்தி மீறலுக்கான முறையான வரையறை இதுதான்: “பல நினைவக அணுகல்களுக்கு இடையில் விரும்பிய தொடர் வரிசை மீறப்படுகிறது.


Finding a fix for this type of problem is often straightforward.

இந்த வகை சிக்கலுக்கு ஒரு தீர்வை கண்டுபிடிப்பது பெரும்பாலும் நேரடியானது.


Another common type of non-deadlock bug found is known as an order violation.

கண்டுபிடிக்கப்பட்ட மற்றொரு பொதுவான வகை முட்டுக்கட்டை அல்லாத பிழை வரிசை மீறல் என்று அழைக்கப்படுகிறது.


The fix to this type of bug is generally to enforce ordering.

இந்த வகை பிழைக்கான தீர்வு பொதுவாக வரிசையை அமல்படுத்துவதாகும்.


When ordering matters between threads, condition variables can come to the rescue.

திரெட்களுக்கு இடையில் வரிசைப்படுத்துதல் முக்கியமாக இருக்கும்போது, நிபந்தனை மாறிகள் மீட்புக்கு வரலாம்.


A large fraction of non-deadlock bugs studied are either atomicity or order violations.

ஆய்வு செய்யப்பட்ட முட்டுக்கட்டை அல்லாத பிழைகளில் பெரும் பகுதி அணுசக்தி அல்லது வரிசை மீறல்களாகும்.


Beyond the concurrency bugs mentioned above, a classic problem that arises is known as deadlock.

மேலே குறிப்பிடப்பட்ட ஒரே நேரத்தில் நிகழும் பிழைகளுக்கு அப்பால், எழும் ஒரு உன்னதமான சிக்கல் முட்டுக்கட்டை என்று அழைக்கப்படுகிறது.


Deadlock occurs, for example, when a thread is holding a lock and waiting for another one.

உதாரணமாக, ஒரு திரெட் ஒரு பூட்டை வைத்திருக்கும்போது மற்றும் மற்றொரு பூட்டுக்காக காத்திருக்கும்போது முட்டுக்கட்டை ஏற்படுகிறது.


How should we build systems to prevent, avoid, or at least detect and recover from deadlock?

முட்டுக்கட்டையைத் தடுக்க, தவிர்க்க அல்லது குறைந்தபட்சம் கண்டறிந்து மீட்க நாம் எவ்வாறு அமைப்புகளை உருவாக்க வேண்டும்?


One reason is that in large code bases, complex dependencies arise between components.

ஒரு காரணம் என்னவென்றால், பெரிய குறியீடு தளங்களில், கூறுகளுக்கு இடையில் சிக்கலான சார்புகள் எழுகின்றன.


Another reason is due to the nature of encapsulation.

மற்றொரு காரணம், என்கapsulation இன் தன்மை காரணமாகும்.


If any of these four conditions are not met, deadlock cannot occur.

இந்த நான்கு நிபந்தனைகளில் ஏதேனும் ஒன்று பூர்த்தி செய்யப்படாவிட்டால், முட்டுக்கட்டை ஏற்பட முடியாது.


A pioneering paper on how to structure web servers in the then-burgeoning Internet era.

அப்போதைய இணைய யுகத்தில் வலை சேவையகங்களை எவ்வாறு கட்டமைப்பது என்பது பற்றிய ஒரு முன்னோடி கட்டுரை இது.


If there is some detail you need to know, it is in here.

நீங்கள் தெரிந்து கொள்ள வேண்டிய விவரம் ஏதேனும் இருந்தால், அது இங்கே உள்ளது.


A paper about how to make threads work at extreme scale; a counter to all the event-based work ongoing at the time.

அதிக அளவில் திரிகளை எவ்வாறு செயல்படுத்துவது என்பது பற்றிய ஒரு கட்டுரை; அப்போதைய நிகழ்வு அடிப்படையிலான அனைத்து வேலைகளுக்கும் ஒரு எதிர்வாதம்.


A nice twist on event-based serving that combines threads, queues, and event-based handling into one streamlined whole.

நிகழ்வு அடிப்படையிலான சேவையில் ஒரு நல்ல திருப்பம், இது திரிகள், வரிசைகள் மற்றும் நிகழ்வு அடிப்படையிலான கையாளுதலை ஒன்றிணைத்து ஒரு நெறிப்படுத்தப்பட்ட முழுமையை உருவாக்குகிறது.


Some of these ideas have found their way into the infrastructures of companies such as Google, Amazon, and elsewhere.

இந்த யோசனைகளில் சில கூகிள், அமேசான் மற்றும் பிற இடங்களில் உள்ள நிறுவனங்களின் உள்கட்டமைப்புகளில் தங்கள் வழியைக் கண்டுபிடித்துள்ளன.


எனவே, இப்போது உங்கள் தலை வலிக்கிறதா?


It’s hard to think about all the ways threads can interleave.

திரி எவ்வாறு ஒன்றோடொன்று பின்னிப் பிணைந்து செயல்படும் என்பதைப் பற்றி சிந்திப்பது கடினம்.


Indeed it is. I am always amazed at how so few line of code, when concurrent execution is involved, can become nearly impossible to understand.

நிச்சயமாக அது உண்மை. சில வரிக் குறியீடு, ஒரே நேரத்தில் செயல்படுத்துவது சம்பந்தப்பட்டிருக்கும்போது, புரிந்துகொள்வது கிட்டத்தட்ட சாத்தியமற்றதாகிவிடும்போது நான் எப்போதும் ஆச்சரியப்படுகிறேன்.


Oh, don’t feel too badly. If you look through the first papers on con- current algorithms, they are sometimes wrong!

ஓ, அவ்வளவு மோசமாக நினைக்காதே. ஒரே நேரத்தில் இயங்கும் வழிமுறைகளைப் பற்றிய முதல் கட்டுரைகளைப் பார்த்தால், அவை சில நேரங்களில் தவறாக இருக்கும்!


பேராசிரியர்கள் ... ம்ம் ... தவறு செய்யலாமா?


Well that is the real question, isn’t it?

சரி, அதுதான் உண்மையான கேள்வி, இல்லையா?


முதலில், அதை எளிமையாக வைத்திருங்கள்!


Avoid complex interactions between threads, and use well-known and tried-and-true ways to manage thread interactions.

திரிகளுக்கு இடையேயான சிக்கலான தொடர்புகளைத் தவிர்க்கவும், மேலும் திரிகளின் தொடர்புகளை நிர்வகிக்க நன்கு அறியப்பட்ட மற்றும் முயற்சித்த வழிகளைப் பயன்படுத்தவும்.


Like simple locking, and maybe a producer-consumer queue?

எளிமையான பூட்டுதல் போன்றவை, மற்றும் ஒரு தயாரிப்பாளர்-நுகர்வோர் வரிசை?


Second, only use con- currency when absolutely needed; avoid it if at all possible.

இரண்டாவதாக, முற்றிலும் தேவைப்படும்போது மட்டுமே ஒரே நேரத்தில் பயன்படுத்துங்கள்; முடிந்தால் அதைத் தவிர்க்கவும்.


There is nothing worse than premature optimization of a program.

ஒரு நிரலை முன்கூட்டியே மேம்படுத்துவதை விட மோசமானது எதுவும் இல்லை.


Third, if you really need parallelism, seek it in other sim- plified forms.

மூன்றாவதாக, உங்களுக்கு உண்மையில் இணையான தன்மை தேவைப்பட்டால், அதை மற்ற எளிமைப்படுத்தப்பட்ட வடிவங்களில் தேடுங்கள்.


Read, read, and read some more! And then try things out, write some code, and then write some more too.

படியுங்கள், படியுங்கள், இன்னும் கொஞ்சம் படியுங்கள்! பிறகு விஷயங்களை முயற்சி செய்யுங்கள், சில குறியீடுகளை எழுதுங்கள், பின்னர் இன்னும் கொஞ்சம் எழுதுங்கள்.


And thus we reach the third of our four ... err... three pillars of operating systems:persistence.

ஆகவே, நாம் நமது நான்கு ... அதாவது ... இயக்க முறைமைகளின் மூன்று தூண்களில் மூன்றாவதுக்கு வருகிறோம்: நிலைத்தன்மை.


Did you say there were three pillars, or four? What is the fourth?

நீங்கள் மூன்று தூண்கள் என்று சொன்னீர்களா, அல்லது நான்கு? நான்காவது என்ன?


முகவரி 0x1F3 = LBA குறைந்த பைட்


கட்டளை பதிவேடுகளுக்கு அளவுருக்களை எழுதுங்கள்.


இடைமறிப்புகளைக் கையாளுங்கள்.


The basic protocol to interact with the device is as follows.

சாதனத்துடன் தொடர்பு கொள்ள அடிப்படை நெறிமுறை பின்வருமாறு.


இயக்கி தயாராக இருக்கும் வரை காத்திருங்கள்.


Read Status Register (0x1F7) until drive is not busy and READY.

இயக்கி பிஸியாக இல்லாமல் மற்றும் தயாராக இருக்கும் வரை நிலை பதிவேட்டை (0x1F7) படியுங்கள்.


Write the sector count, logical block address (LBA) of the sectors to be accessed, and drive number to command registers.

அணுக வேண்டிய துறைகளின் துறை எண்ணிக்கை, தர்க்கரீதியான தொகுதி முகவரி (LBA) மற்றும் இயக்கி எண்ணை கட்டளை பதிவேடுகளுக்கு எழுதுங்கள்.


Start the I/O by issuing read/write to command register.

கட்டளைப் பதிவேட்டில் படிக்க/எழுத உத்தரவு பிறப்பிப்பதன் மூலம் I/O ஐத் தொடங்குங்கள்.


After each operation, read the status register.

ஒவ்வொரு செயல்பாட்டிற்குப் பிறகும், நிலை பதிவேட்டைப் படியுங்கள்.


If the ERROR bit is on, read the error register for details.

பிழை பிட் இயக்கப்பட்டிருந்தால், விவரங்களுக்கு பிழைப் பதிவேட்டைப் படியுங்கள்.


Most of this protocol is found in the xv6 IDE driver.

இந்த நெறிமுறையின் பெரும்பகுதி xv6 IDE இயக்கியில் காணப்படுகிறது.


The first is ide_rw(), which queues a request.

முதலாவது ide_rw(), இது ஒரு கோரிக்கையை வரிசைப்படுத்துகிறது.


The second is ide_startrequest(), which is used to send a request to the disk.

இரண்டாவது ide_startrequest(), இது வட்டுக்கு ஒரு கோரிக்கையை அனுப்ப பயன்படுகிறது.


The start request routine uses the third function, ide_waitready().

தொடக்க கோரிக்கை வழக்கமானது மூன்றாவது செயல்பாட்டைப் பயன்படுத்துகிறது, ide_waitready().


Finally, ide_intr() is invoked when an interrupt takes place.

இறுதியாக, ஒரு குறுக்கீடு நிகழும்போது ide_intr() அழைக்கப்படுகிறது.


Interrupts are an ancient idea, existing on the earliest of machines.

இடைமறிப்புகள் ஒரு பழங்கால யோசனையாகும், இது ஆரம்பகால இயந்திரங்களில் இருந்தது.


The basic interface for all modern drives is straightforward.

அனைத்து நவீன இயக்ககங்களுக்கான அடிப்படை இடைமுகம் நேரடியானது.


The drive consists of a large number of sectors.

இயக்கி அதிக எண்ணிக்கையிலான துறைகளைக் கொண்டுள்ளது.


பல துறை செயல்பாடுகள் சாத்தியமாகும்.


How do modern hard-disk drives store data?

நவீன ஹார்ட்-டிஸ்க் டிரைவ்கள் தரவை எவ்வாறு சேமிக்கின்றன?


The system can tolerate the loss of a single disk.

ஒரு வட்டு இழப்பை கணினி தாங்க முடியும்.


RAID systems operate even if a disk fails.

ஒரு வட்டு செயலிழந்தாலும் RAID அமைப்புகள் செயல்படும்.


Transparency is key for easy deployment of new features.

புதிய அம்சங்களை எளிதாகப் பயன்படுத்துவதற்கு வெளிப்படைத்தன்மை முக்கியமானது.


RAID allows administrators to replace a disk without changing the system.

கணினி அமைப்பில் எந்த மாற்றமும் செய்யாமல் ஒரு வட்டை மாற்ற RAID நிர்வாகிகளை அனுமதிக்கிறது.


RAID appears as a single large disk to the host system.

RAID, ஹோஸ்ட் கணினிக்கு ஒரு பெரிய வட்டு போல் தோன்றும்.


The operating system and applications don't need modification.

இயக்க முறைமை மற்றும் பயன்பாடுகளில் மாற்றம் செய்ய வேண்டியதில்லை.


RAID பயன்படுத்துவதை மேம்படுத்துகிறது.


We will now discuss important aspects of RAIDs.

இப்போது RAIDகளின் முக்கியமான அம்சங்களைப் பற்றி விவாதிப்போம்.


A RAID internally calculates which disks to access.

ஒரு RAID உள்நாட்டில் எந்த வட்டுக்களை அணுக வேண்டும் என்பதை கணக்கிடுகிறது.


Consider a RAID that keeps two copies of each block.

ஒவ்வொரு தொகுதியின் இரண்டு பிரதிகளை வைத்திருக்கும் ஒரு RAID ஐக் கவனியுங்கள்.


A RAID system is often built as a separate hardware box.

ஒரு RAID அமைப்பு பெரும்பாலும் ஒரு தனி வன்பொருள் பெட்டியாக உருவாக்கப்படுகிறது.


RAIDகள் ஒரு சிறப்பு கணினி அமைப்புகள் ஆகும்.


RAIDs are designed to recover from disk faults.

வட்டு குறைபாடுகளில் இருந்து மீட்க RAIDகள் வடிவமைக்கப்பட்டுள்ளன.


The fail-stop fault model assumes a disk can be working or failed.

தோல்வி-நிறுத்த மாதிரி, ஒரு வட்டு வேலை செய்கிறது அல்லது தோல்வியடைகிறது என்று கருதுகிறது.


We assume that disk failure is easily detected.

வட்டு செயலிழப்பு எளிதில் கண்டறியப்படும் என்று நாங்கள் கருதுகிறோம்.


We evaluate RAID designs along three axes.

மூன்று அச்சுகளில் RAID வடிவமைப்புகளை நாங்கள் மதிப்பீடு செய்கிறோம்.


முதல் அச்சு திறன் ஆகும்.


How many disk faults can the design tolerate?

வடிவமைப்பு எத்தனை வட்டு குறைபாடுகளைத் தாங்கும்?


Performance depends heavily on the workload.

செயல்திறன் பணிச்சுமையை பெரிதும் சார்ந்துள்ளது.


We now consider three important RAID designs.

இப்போது மூன்று முக்கியமான RAID வடிவமைப்புகளைப் பற்றி கருதுகிறோம்.


The first, known as the Cheetah 15K.5 [S09b], is a high-performance SCSI drive.

முதலில், சீட்டா 15K.5 [S09b] என அழைக்கப்படுவது, ஒரு உயர்-செயல்திறன் கொண்ட SCSI இயக்கி ஆகும்.


The second, the Barracuda [S09a], is a drive built for capacity.

இரண்டாவதாக, பாராகுடா [S09a] என்பது கொள்ளளவுக்காக கட்டப்பட்ட ஒரு இயக்கி ஆகும்.


Details on both are found in Table 37.1.

இரண்டின் விவரங்களும் அட்டவணை 37.1 இல் காணப்படுகின்றன.


As you can see, the drives have quite different characteristics.

நீங்கள் பார்க்க முடியும் என, இயக்ககங்கள் முற்றிலும் வேறுபட்ட பண்புகளைக் கொண்டுள்ளன.


The first is the “high performance” drive market, where drives are engineered to spin as fast as possible.

முதலாவது “உயர் செயல்திறன்” இயக்கி சந்தையாகும், அங்கு இயக்கிகள் முடிந்தவரை வேகமாக சுழலும் வகையில் வடிவமைக்கப்பட்டுள்ளன.


The second is the “capacity” market, where cost per byte is the most important aspect.

இரண்டாவது “கொள்ளளவு” சந்தையாகும், அங்கு ஒரு பைட்டுக்கான விலை மிக முக்கியமான அம்சமாகும்.


From these numbers, we can start to calculate how well the drives would do under our two workloads outlined above.

இந்த எண்களிலிருந்து, மேலே கோடிட்டுக் காட்டப்பட்டுள்ள எங்கள் இரண்டு பணிச்சுமைகளின் கீழ் இயக்ககங்கள் எவ்வளவு சிறப்பாக செயல்படும் என்பதை கணக்கிடத் தொடங்கலாம்.


Let’s start by looking at the random workload.

சீரற்ற பணிச்சுமையைப் பார்ப்பதன் மூலம் ஆரம்பிக்கலாம்.


Assuming each 4 KB read occurs at a random location on disk, we can calculate how long each such read would take.

ஒவ்வொரு 4 KB ரீடும் டிஸ்கில் ஒரு சீரற்ற இடத்தில் நிகழ்கிறது என்று வைத்துக்கொண்டால், ஒவ்வொரு ரீடும் எவ்வளவு நேரம் எடுக்கும் என்பதை கணக்கிடலாம்.


On the Cheetah: T seek = 4ms, T rotation = 2ms, T transfer = 30microsecs(37.3)

சீட்டாவில்: T seek = 4ms, T சுழற்சி = 2ms, T பரிமாற்றம் = 30microsecs(37.3)


If sequential is not possible, at least think about transferring data in large chunks: the bigger, the better.

வரிசைமுறை சாத்தியமில்லை என்றால், குறைந்தபட்சம் பெரிய துண்டுகளாக தரவை மாற்றுவதைப் பற்றி சிந்தியுங்கள்: எவ்வளவு பெரியதாக இருக்கிறதோ, அவ்வளவு நல்லது.


If I/O is done in little random pieces, I/O performance will suffer dramatically.

I/O சிறிய சீரற்ற துண்டுகளாக செய்யப்பட்டால், I/O செயல்திறன் வியத்தகு முறையில் பாதிக்கப்படும்.


Also, users will suffer. Also, you will suffer, knowing what suffering you have wrought with your careless random I/Os.

மேலும், பயனர்கள் பாதிக்கப்படுவார்கள். மேலும், உங்கள் கவனக்குறைவான சீரற்ற I/O களால் நீங்கள் என்ன துன்பத்தை ஏற்படுத்தினீர்கள் என்பதை அறிந்து நீங்களும் பாதிக்கப்படுவீர்கள்.


The average seek time (4 milliseconds) is just taken as the average time reported by the manufacturer.

சராசரி தேடல் நேரம் (4 மில்லி விநாடிகள்) உற்பத்தியாளரால் அறிவிக்கப்பட்ட சராசரி நேரமாக எடுத்துக் கொள்ளப்படுகிறது.


The average rotational delay is calculated from the RPM directly.

சராசரி சுழற்சி தாமதம் RPM இலிருந்து நேரடியாக கணக்கிடப்படுகிறது.


Finally, the transfer time is just the size of the transfer over the peak transfer rate.

இறுதியாக, பரிமாற்ற நேரம் என்பது உச்ச பரிமாற்ற வீதத்தில் பரிமாற்றத்தின் அளவு மட்டுமே.


Thus, from our equation above,T I/O for the Cheetah roughly equals 6 ms.

எனவே, மேலே உள்ள நமது சமன்பாட்டிலிருந்து, சீட்டாவிற்கான T I/O தோராயமாக 6 ms க்கு சமம்.


To compute the rate of I/O, we just divide the size of the transfer by the average time, and thus arrive atR I/O for the Cheetah under the random workload of about0.66MB/s.

I/O இன் விகிதத்தை கணக்கிட, பரிமாற்றத்தின் அளவை சராசரி நேரத்தால் வகுக்கிறோம், இதன் மூலம் தோராயமாக 0.66MB/s என்ற சீரற்ற பணிச்சுமையின் கீழ் சீட்டாவிற்கான R I/O ஐப் பெறுகிறோம்.


The same calculation for the Bar- racuda yields aT I/O of about 13.2 ms, more than twice as slow, and thus a rate of about0.31MB/s.

பாராகுடாவிற்கான அதே கணக்கீடு தோராயமாக 13.2 ms இன் T I/O ஐ அளிக்கிறது, இது இரண்டு மடங்கு மெதுவாகும், மேலும் தோராயமாக 0.31MB/s என்ற விகிதத்தில் உள்ளது.


Now let’s look at the sequential workload.

இப்போது வரிசைமுறை பணிச்சுமையைப் பார்ப்போம்.


I want to know more about the file's length.

கோப்பின் நீளம் பற்றி நான் மேலும் தெரிந்து கொள்ள விரும்புகிறேன்.


The -l flag provides detailed information.

-l கொடி விரிவான தகவல்களை வழங்குகிறது.


வெளியீட்டைப் பார்க்க 'ls -l' ஐப் பயன்படுத்த முயற்சிக்கவும்.


கோப்புறைகளை நீக்குவது ஆபத்தானது.


The rmdir() call requires an empty directory.

rmdir() அழைப்பிற்கு ஒரு வெற்று கோப்புறை தேவை.


You could potentially delete a lot of data.

நீங்கள் ஒரு பெரிய அளவிலான தரவை நீக்கலாம்.


Hard links provide another way to refer to the same file.

ஹார்ட் இணைப்புகள் அதே கோப்பைக் குறிப்பிடுவதற்கு மற்றொரு வழியை வழங்குகின்றன.


ln கட்டளை ஹார்ட் இணைப்புகளை உருவாக்குகிறது.


Both file and file2 refer to the same inode.

கோப்பு மற்றும் file2 இரண்டும் ஒரே ஐனோடைக்குக் குறிப்பிடுகின்றன.


ஐனோட் கோப்பு மெட்டாடேட்டாவைக் கண்காணிக்கிறது.


Unlinking a file decrements the reference count.

ஒரு கோப்பை நீக்குவது குறிப்பு எண்ணிக்கையை குறைக்கிறது.


The file system frees the inode when the count reaches zero.

எண்ணிக்கை பூஜ்ஜியத்தை அடையும்போது கோப்பு முறைமை ஐனோடை விடுவிக்கிறது.


Symbolic links are a different type of link.

சின்ன இணைப்புகள் ஒரு வித்தியாசமான வகை இணைப்பு.


A symbolic link is actually a file itself.

சின்ன இணைப்பு உண்மையில் ஒரு கோப்பாகும்.


Symbolic links can point to non-existent files.

சின்ன இணைப்புகள் இல்லாத கோப்புகளைச் சுட்டிக்காட்டலாம்.


ஒரு கோப்பு முறைமையை உருவாக்குவது mkfs ஐ உள்ளடக்கியது.


Mounting makes the file system accessible.

மவுண்டிங் கோப்பு முறைமையை அணுகக்கூடியதாக ஆக்குகிறது.


மவுண்ட் கட்டளை கோப்பு முறைமைகளை ஒருங்கிணைக்கிறது.


The superblock contains file system information.

சூப்பர் பிளாக்கில் கோப்பு முறைமை தகவல் உள்ளது.


Understanding file systems requires understanding data structures and access methods.

கோப்பு முறைமைகளைப் புரிந்துகொள்வதற்கு தரவு கட்டமைப்புகள் மற்றும் அணுகல் முறைகளைப் புரிந்துகொள்வது அவசியம்.


The file is referred to by the user-readable name of “foo”.

கோப்பின் பயனர் படிக்கக்கூடிய பெயர் “foo” ஆகும்.


Each entry in a directory refers to either files or other directories.

ஒரு கோப்பகத்தில் உள்ள ஒவ்வொரு உள்ளீடும் கோப்புகள் அல்லது பிற கோப்பகங்களைக் குறிக்கிறது.


By placing directories within other directories, users are able to build an arbitrary directory tree.

கோப்பகங்களை மற்ற கோப்பகங்களுக்குள் வைப்பதன் மூலம், பயனர்கள் ஒரு தன்னிச்சையான கோப்பக மரத்தை உருவாக்க முடியும்.


For example, if a user created a directory foo in the root directory, and then created a file bar.txt in the directory foo, we could refer to the file by its absolute pathname, which in this case would be /foo/bar.txt.

உதாரணமாக, ஒரு பயனர் ரூட் கோப்பகத்தில் foo என்ற கோப்பகத்தை உருவாக்கி, பின்னர் foo கோப்பகத்தில் bar.txt என்ற கோப்பை உருவாக்கினால், அந்த கோப்பை அதன் முழுமையான பாதைப்பெயரால் குறிப்பிடலாம், இது இந்த விஷயத்தில் /foo/bar.txt ஆக இருக்கும்.


Naming is an important aspect of computer systems.

பெயரிடுதல் கணினி அமைப்புகளின் ஒரு முக்கியமான அம்சமாகும்.


In UNIX systems, virtually everything that you can think of is named through the file system.

UNIX அமைப்புகளில், நீங்கள் நினைக்கும் கிட்டத்தட்ட எல்லாமே கோப்பு முறை மூலம் பெயரிடப்படுகின்றன.


This uniformity of naming eases your conceptual model of the system, and makes the system simpler and more modular.

பெயரிடுவதில் உள்ள இந்த சீரான தன்மை உங்கள் கணினி பற்றிய கருத்தியல் மாதிரியை எளிதாக்குகிறது, மேலும் கணினியை எளிமையாகவும், அதிக மட்டுத்தன்மையுடனும் ஆக்குகிறது.


Thus, whenever creating a system or interface, think carefully about what names you are using.

எனவே, ஒரு கணினி அல்லது இடைமுகத்தை உருவாக்கும் போதெல்லாம், நீங்கள் பயன்படுத்தும் பெயர்களைப் பற்றி கவனமாக சிந்தியுங்கள்.


The first part is an arbitrary name, whereas the second part of the file name is usually used to indicate the type of the file.

முதல் பகுதி ஒரு தன்னிச்சையான பெயர், அதே நேரத்தில் கோப்பு பெயரின் இரண்டாவது பகுதி பொதுவாக கோப்பின் வகையைக் குறிக்கப் பயன்படுகிறது.


Thus, we can see one great thing provided by the file system: a convenient way to name all the files we are interested in.

எனவே, கோப்பு முறை மூலம் வழங்கப்பட்ட ஒரு சிறந்த விஷயத்தை நாம் காணலாம்: நாம் விரும்பும் அனைத்து கோப்புகளுக்கும் பெயரிடுவதற்கான ஒரு வசதியான வழி.


Names are important in systems as the first step to accessing any resource is being able to name it.

எந்தவொரு வளத்தையும் அணுகுவதற்கான முதல் படியாக பெயர்கள் அமைப்புகளில் முக்கியம்.


Let’s now discuss the file system interface in more detail.

இப்போது கோப்பு முறை இடைமுகத்தை விரிவாக விவாதிப்போம்.


We’ll start with the basics of creating, accessing, and deleting files.

கோப்புகளை உருவாக்குதல், அணுகுதல் மற்றும் நீக்குதல் ஆகியவற்றின் அடிப்படைகளுடன் தொடங்குவோம்.


This can be accomplished with the open system call; by calling open and passing it the O_CREAT flag, a program can create a new file.

இது திறந்த அமைப்பு அழைப்புடன் செய்யப்படலாம்; open()ஐ அழைப்பதன் மூலமும், O_CREAT கொடியை அதற்கு அனுப்புவதன் மூலமும், ஒரு நிரல் ஒரு புதிய கோப்பை உருவாக்க முடியும்.


The older way of creating a file is to call creat, as follows:

ஒரு கோப்பை உருவாக்கும் பழைய வழி creat ஐ அழைப்பதாகும், பின்வருமாறு:


One important aspect of open is what it returns: a file descriptor.

open இன் ஒரு முக்கியமான அம்சம் அது என்ன திருப்பி அனுப்புகிறது: ஒரு கோப்பு விளக்ககம்.


A file descriptor is just an integer, private per process, and is used in UNIX systems to access files.

ஒரு கோப்பு விளக்ககம் என்பது ஒரு முழு எண், ஒவ்வொரு செயலுக்கும் தனிப்பட்டது, மேலும் UNIX அமைப்புகளில் கோப்புகளை அணுகப் பயன்படுகிறது.


Once we have some files, of course we might like to read or write them.

சில கோப்புகள் கிடைத்தவுடன், அவற்றை படிக்கவோ அல்லது எழுதவோ விரும்பலாம்.


Let’s start by reading an existing file.

ஏற்கனவே உள்ள கோப்பை படிப்பதன் மூலம் ஆரம்பிக்கலாம்.


The first thing that cat does is open the file for reading.

cat செய்யும் முதல் விஷயம் கோப்பை படிப்பதற்காக திறப்பதாகும்.


As you can see, for each stripe of data, we have added a single parity block.

நீங்கள் பார்க்கலாம், ஒவ்வொரு தரவு துண்டுக்கும், ஒரு தனித்தன்மை சரிபார்ப்புத் தொகுதியைச் சேர்த்துள்ளோம்.


For example, parity block P1 has redundant information that it calculated from blocks 4, 5, 6, and 7.

உதாரணமாக, சரிபார்ப்புத் தொகுதி P1 ஆனது 4, 5, 6, மற்றும் 7 தொகுதிகளிலிருந்து கணக்கிடப்பட்ட உபரி தகவல்களைக் கொண்டுள்ளது.


To compute parity, we need to use a mathematical function that enables us to withstand the loss of any one block from our stripe.

சரிபார்ப்பைக் கணக்கிட, எங்கள் துண்டிலிருந்து எந்தவொரு தொகுதியின் இழப்பையும் தாங்கும் ஒரு கணிதச் செயல்பாட்டைப் பயன்படுத்த வேண்டும்.


It turns out the simple function XOR does the trick quite nicely.

எளிமையான செயல்பாடு XOR நன்றாக வேலை செய்கிறது.


For a given set of bits, the XOR of all of those bits returns a 0 if there are an even number of 1’s in the bits, and a 1 if there are an odd number of 1’s.

கொடுக்கப்பட்ட பிட்களின் தொகுப்பிற்கு, அந்த பிட்களின் அனைத்து XOR களும் 0 ஐ வழங்குகின்றன, பிட்களில் இரட்டைப்படை 1 கள் இருந்தால், மற்றும் ஒற்றைப்படை 1 கள் இருந்தால் 1 ஐ வழங்குகின்றன.


In the first row (0,0,1,1), there are two 1’s (C2, C3), and thus XOR of all of those values will be 0 (P); similarly, in the second row there is only one 1 (C1), and thus the XOR must be 1 (P).

முதல் வரிசையில் (0,0,1,1), இரண்டு 1 கள் (C2, C3) உள்ளன, எனவே அந்த மதிப்புகள் அனைத்தின் XOR 0 (P) ஆக இருக்கும்; அதேபோல், இரண்டாவது வரிசையில் ஒரே ஒரு 1 (C1) உள்ளது, எனவே XOR 1 (P) ஆக இருக்க வேண்டும்.


You can remember this in a very simple way: that the number of 1’s in any row must be an even (not odd) number; that is the invariant that the RAID must maintain in order for parity to be correct.

இதை நீங்கள் மிக எளிமையான முறையில் நினைவில் கொள்ளலாம்: எந்த வரிசையிலும் உள்ள 1 களின் எண்ணிக்கை ஒரு இரட்டைப்படை எண்ணாக இருக்க வேண்டும்; அதாவது சரிபார்ப்பு சரியாக இருக்க RAID பராமரிக்க வேண்டிய மாறிலி இதுவாகும்.


C2 என்று பெயரிடப்பட்ட நெடுவரிசை இழந்துவிட்டதாக கற்பனை செய்து கொள்ளுங்கள்.


To figure out what values must have been in the column, we simply have to read in all the other values in that row (including the XOR’d parity bit) and reconstruct the right answer.

அந்த நெடுவரிசையில் என்ன மதிப்புகள் இருந்திருக்க வேண்டும் என்பதைக் கண்டுபிடிக்க, அந்த வரிசையில் உள்ள மற்ற எல்லா மதிப்புகளையும் (XOR செய்யப்பட்ட சரிபார்ப்பு பிட் உட்பட) படித்து சரியான பதிலை மீண்டும் உருவாக்க வேண்டும்.


Specifically, assume the first row’s value in column C2 is lost (it is a 1); by reading the other values in that row (0 from C0, 0 from C1, 1 from C3, and 0 from the parity column P), we get the values 0, 0, 1, and 0.

குறிப்பாக, நெடுவரிசை C2 இல் உள்ள முதல் வரிசையின் மதிப்பு இழந்துவிட்டது என்று வைத்துக்கொள்வோம் (அது 1); அந்த வரிசையில் உள்ள மற்ற மதிப்புகளைப் படிப்பதன் மூலம் (C0 இலிருந்து 0, C1 இலிருந்து 0, C3 இலிருந்து 1, மற்றும் சரிபார்ப்பு நெடுவரிசை P இலிருந்து 0), நாம் மதிப்புகளைப் பெறுகிறோம் 0, 0, 1, மற்றும் 0.


Because we know that XOR keeps an even number of 1’s in each row, we know what the missing data must be: a 1.

XOR ஒவ்வொரு வரிசையிலும் இரட்டைப்படை 1 களை வைத்திருக்கிறது என்பதை நாம் அறிவோம், விடுபட்ட தரவு என்னவாக இருக்க வேண்டும் என்பதை நாம் அறிவோம்: 1.


And that is how reconstruction works in a XOR-based parity scheme!

ஒரு XOR-அடிப்படையிலான சரிபார்ப்புத் திட்டத்தில் மறுசீரமைப்பு எவ்வாறு செயல்படுகிறது என்பது இதுதான்!


Now you might be wondering: we are talking about XORing all of these bits, and yet above we know that the RAID places 4KB (or larger) blocks on each disk; how do we apply XOR to a bunch of blocks to compute the parity?

இப்போது நீங்கள் யோசிக்கலாம்: நாம் இந்த எல்லா பிட்களையும் XOR செய்வது பற்றி பேசுகிறோம், மேலும் RAID ஒவ்வொரு வட்டில் 4KB (அல்லது பெரிய) தொகுதிகளை வைக்கிறது என்பதை மேலே அறிவோம்; சரிபார்ப்பைக் கணக்கிட, ஒரு தொகுதி தொகுதிகளுக்கு XOR ஐ எவ்வாறு பயன்படுத்துவது?


இதுவும் எளிதானது.


Simply perform a bitwise XOR across each bit of the data blocks; put the result of each bitwise XOR into the corresponding bit slot in the parity block.

தரவுத் தொகுதிகளின் ஒவ்வொரு பிட்டிலும் ஒரு பிட்வைஸ் XOR ஐச் செய்யுங்கள்; ஒவ்வொரு பிட்வைஸ் XOR இன் முடிவையும் சரிபார்ப்புத் தொகுதியில் உள்ள தொடர்புடைய பிட் ஸ்லாட்டில் வைக்கவும்.


For example, if we had blocks of size 4 bits (yes, this is still quite a bit smaller than a 4KB block, but you get the picture), they might look something like this:

உதாரணமாக, 4 பிட்களின் அளவிலான தொகுதிகள் இருந்தால் (ஆம், இது இன்னும் 4KB தொகுதியை விட சிறியது, ஆனால் உங்களுக்குப் புரிகிறது), அவை இப்படி இருக்கலாம்:


RAID-4 uses 1 disk for parity information for every group of disks it is protecting.

RAID-4 ஆனது, அது பாதுகாக்கும் ஒவ்வொரு வட்டு குழுவிற்கும் சரிபார்ப்பு தகவலுக்காக 1 வட்டைப் பயன்படுத்துகிறது.


Thus, our useful capacity for a RAID group is (N-1).

எனவே, ஒரு RAID குழுவிற்கான பயனுள்ள திறன் (N-1) ஆகும்.


Reliability is also quite easy to understand: RAID-4 tolerates 1 disk failure and no more.

நம்பகத்தன்மையும் புரிந்து கொள்ள மிகவும் எளிதானது: RAID-4 ஆனது 1 வட்டு தோல்வியை மட்டுமே பொறுத்துக்கொள்ளும்.


If more than one disk is lost, there is simply no way to reconstruct the lost data.

ஒன்றுக்கு மேற்பட்ட வட்டு இழக்கப்பட்டால், இழந்த தரவை மீண்டும் உருவாக்க வழியே இல்லை.


The inode is a data structure that stores metadata about a file.

ஒரு கோப்பின் மெட்டாடேட்டாவைச் சேமிக்கும் தரவு கட்டமைப்பு இனோட் ஆகும்.


File systems use inodes to manage files on a storage device.

சேமிப்பு சாதனத்தில் கோப்புகளை நிர்வகிக்க கோப்பு அமைப்புகள் இனோட்களைப் பயன்படுத்துகின்றன.


The inode number is used to index into an array of inodes.

இனோட் எண்ணானது இனோட்களின் வரிசையில் குறியீடாகப் பயன்படுத்தப்படுகிறது.


Each file has an inode that contains information like its size and permissions.

ஒவ்வொரு கோப்பும் அதன் அளவு மற்றும் அனுமதிகள் போன்ற தகவல்களைக் கொண்ட ஒரு இனோட்டைக் கொண்டுள்ளது.


The inode stores the location of the file's data blocks.

கோப்பின் தரவு தொகுதிகளின் இருப்பிடத்தை இனோட் சேமிக்கிறது.


File system design heavily relies on the inode structure.

கோப்பு அமைப்பு வடிவமைப்பு இனோட் கட்டமைப்பை பெரிதும் நம்பியுள்ளது.


The inode table is a crucial part of a file system.

இனோட் அட்டவணை ஒரு கோப்பு அமைப்பின் முக்கியமான பகுதியாகும்.


The file system uses the inode to find the file's data.

கோப்பின் தரவைக் கண்டறிய கோப்பு அமைப்பு இனோட்டைப் பயன்படுத்துகிறது.


Understanding inodes is key to understanding how file systems work.

கோப்பு அமைப்புகள் எவ்வாறு செயல்படுகின்றன என்பதைப் புரிந்துகொள்வதற்கு இனோட்களைப் புரிந்துகொள்வது முக்கியம்.


The inode contains information about file access times.

இனோட் கோப்பு அணுகல் நேரங்களைப் பற்றிய தகவல்களைக் கொண்டுள்ளது.


The file system uses bitmaps to manage free space.

காலி இடத்தை நிர்வகிக்க கோப்பு அமைப்பு பிட்மேப்களைப் பயன்படுத்துகிறது.


When a file is created, the file system allocates an inode.

ஒரு கோப்பு உருவாக்கப்பட்டால், கோப்பு அமைப்பு ஒரு இனோட்டை ஒதுக்குகிறது.


The directory structure is organized using inodes.

இனோட்களைப் பயன்படுத்தி கோப்பக அமைப்பு ஒழுங்கமைக்கப்பட்டுள்ளது.


The root directory's inode number is typically 2.

ரூட் கோப்பகத்தின் இனோட் எண் பொதுவாக 2 ஆகும்.


File creation involves allocating an inode and directory entry.

கோப்பை உருவாக்குவதில் ஒரு இனோட் மற்றும் கோப்பக உள்ளீட்டை ஒதுக்குவது அடங்கும்.


Multi-level indexing is a common approach for large files.

பல-நிலை குறியீட்டு முறை பெரிய கோப்புகளுக்கு ஒரு பொதுவான அணுகுமுறையாகும்.


The file system must traverse the directory structure to find a file.

ஒரு கோப்பைக் கண்டுபிடிக்க கோப்பு அமைப்பு கோப்பக கட்டமைப்பை கடந்து செல்ல வேண்டும்.


Writing to a file may involve allocating new data blocks.

ஒரு கோப்பில் எழுதுவது புதிய தரவு தொகுதிகளை ஒதுக்குவதை உள்ளடக்கியிருக்கலாம்.


The open() system call retrieves the file's inode.

திற() சிஸ்டம் கால் கோப்பின் இனோட்டை மீட்டெடுக்கிறது.


File systems use various strategies for free space management.

காலி இட மேலாண்மைக்கு கோப்பு அமைப்புகள் பல்வேறு உத்திகளைப் பயன்படுத்துகின்றன.


The disk transfer rate improves rapidly.

வட்டு பரிமாற்ற வீதம் வேகமாக மேம்படுகிறது.


Mechanical aspects of drives improve slowly.

இயக்ககங்களின் இயந்திர அம்சங்கள் மெதுவாக மேம்படுகின்றன.


FFS introduced sub-blocks to save space.

இடத்தை சேமிக்க FFS துணை தொகுதிகளை அறிமுகப்படுத்தியது.


Small files wasted space with 4-KB blocks.

சிறிய கோப்புகள் 4-KB தொகுதிகளுடன் இடத்தை வீணடித்தன.


நூலகம் எழுத்துக்களை இடையகப்படுத்தும்.


FFS optimized disk layout for performance.

செயல்திறனுக்காக FFS வட்டு அமைப்பை மேம்படுத்தியது.


நவீன வட்டுக்கள் உள் நினைவகத்தைப் பயன்படுத்துகின்றன.


Abstraction and higher-level interfaces are beneficial.

சுருக்கம் மற்றும் உயர்-நிலை இடைமுகங்கள் நன்மை பயக்கும்.


FFS நீண்ட கோப்பு பெயர்களை அனுமதித்தது.


சின்ன இணைப்புகள் நெகிழ்வுத்தன்மையை வழங்குகின்றன.


Usability improvements increased adoption.

பயன்பாட்டு மேம்பாடுகள் தத்தெடுப்பை அதிகரித்தன.


FFS ஒரு திருப்புமுனை தருணமாக இருந்தது.


File management is an interesting issue.

கோப்பு மேலாண்மை ஒரு சுவாரஸ்யமான பிரச்சினை.


நவீன அமைப்புகள் FFS இலிருந்து குறிப்புகளை எடுத்துக்கொள்கின்றன.


The crash-consistency problem is a key challenge.

விபத்து-நிலையான பிரச்சனை ஒரு முக்கிய சவாலாகும்.


File system data structures must persist.

கோப்பு முறை தரவு கட்டமைப்புகள் நிலைத்திருக்க வேண்டும்.


மின்சாரம் தடைபடுவது தரவு சிதைவை ஏற்படுத்தலாம்.


Fsck என்பது முரண்பாடுகளை சரிசெய்யும் ஒரு கருவி.


Fsck ஐனோட்களையும் பிட்மேப்களையும் ஸ்கேன் செய்கிறது.


Fsck இரட்டை சுட்டிகளை சரிபார்க்கிறது.


The file system uses system memory to cache important blocks.

கோப்பு முறை முக்கிய தொகுதிகளை சேமிக்க கணினி நினைவகத்தைப் பயன்படுத்துகிறது.


Reading and writing files can be expensive, incurring many I/Os to the disk.

கோப்புகளைப் படித்தல் மற்றும் எழுதுதல் விலை உயர்ந்ததாக இருக்கலாம், இது வட்டில் பல I/O களை ஏற்படுத்துகிறது.


Modern systems integrate virtual memory pages and file system pages into a unified page cache.

நவீன அமைப்புகள் மெய்நிகர் நினைவகப் பக்கங்களையும் கோப்பு முறைப் பக்கங்களையும் ஒருங்கிணைந்த பக்க சேமிப்பில் ஒருங்கிணைக்கின்றன.


The file system can batch some updates into a smaller set of I/Os.

கோப்பு முறை சில புதுப்பிப்புகளை சிறிய I/O தொகுப்பாக மாற்ற முடியும்.


Some applications force writes to disk to avoid unexpected data loss.

சில பயன்பாடுகள் எதிர்பாராத தரவு இழப்பைத் தவிர்க்க வட்டில் எழுதுவதை கட்டாயப்படுத்துகின்றன.


We have seen the basic machinery required in building a file system.

ஒரு கோப்பு முறையை உருவாக்குவதற்கு தேவையான அடிப்படை இயந்திரத்தை நாம் பார்த்தோம்.


Directories are just a specific type of file that store name→inode-number mappings.

கோப்பகங்கள் என்பது பெயர்→இனோட்-எண் மேப்பிங்குகளை சேமிக்கும் ஒரு குறிப்பிட்ட வகை கோப்பாகும்.


The file system was delivering only 2% of overall disk bandwidth!

கோப்பு முறை மொத்த வட்டு அலைவரிசையின் 2% மட்டுமே வழங்கியது!


The main issue was that the old UNIX file system treated the disk like it was a random-access memory.

முக்கிய பிரச்சனை என்னவென்றால், பழைய UNIX கோப்பு முறை வட்டை ஒரு ரேண்டம்-அணுகல் நினைவகமாக நடத்தியது.


The free space was not carefully managed.

இலவச இடம் கவனமாக நிர்வகிக்கப்படவில்லை.


This fragmentation problem happened all the time in the old UNIX file system.

இந்த துண்டாக்கும் பிரச்சனை பழைய UNIX கோப்பு முறையில் எப்போதும் நடந்தது.


அசல் தொகுதி அளவு மிகவும் சிறியதாக இருந்தது.


How can we organize file system data structures so as to improve performance?

செயல்திறனை மேம்படுத்தும் வகையில் கோப்பு முறை தரவு கட்டமைப்புகளை எவ்வாறு ஒழுங்கமைக்க முடியும்?


FFS divides the disk into a bunch of groups known as cylinder groups.

FFS வட்டை உருளை குழுக்கள் என்று அழைக்கப்படும் குழுக்களாக பிரிக்கிறது.


These groups are the central mechanism that FFS uses to improve performance.

இந்த குழுக்கள் FFS செயல்திறனை மேம்படுத்த பயன்படுத்தும் மைய வழிமுறையாகும்.


A copy of the super block is found in each group for reliability reasons.

நம்பகத்தன்மை காரணங்களுக்காக ஒவ்வொரு குழுவிலும் சூப்பர் பிளாக்கின் நகல் காணப்படுகிறது.


Bitmaps are an excellent way to manage free space in a file system.

கோப்பு முறையில் இலவச இடத்தை நிர்வகிப்பதற்கான சிறந்த வழி பிட்மேப்கள் ஆகும்.


Overall, it is a lot of work just to create a new file!

மொத்தத்தில், ஒரு புதிய கோப்பை உருவாக்குவதற்கு நிறைய வேலைகள் உள்ளன!


FFS makes use of a few simple placement heuristics.

FFS சில எளிய இடஞ்சார்ந்த யூகங்களைப் பயன்படுத்துகிறது.


Files in a directory are often accessed together.

ஒரு கோப்பகத்தில் உள்ள கோப்புகள் பெரும்பாலும் ஒன்றாக அணுகப்படுகின்றன.


The file system uses journaling to ensure data consistency after a crash.

ஒரு விபத்துக்குப் பிறகு தரவு நிலைத்தன்மையை உறுதிப்படுத்த கோப்பு முறை ஜர்னலிங்கை பயன்படுத்துகிறது.


Journaling reduces recovery time from O(size-of-the-disk-volume) to O(size-of-the-log).

ஜர்னலிங் மீட்பு நேரத்தை O(வட்டு அளவின் அளவு) முதல் O(பதிவின் அளவு) வரை குறைக்கிறது.


Many modern file systems use journaling for faster recovery.

வேகமான மீட்புக்காக பல நவீன கோப்பு முறைகள் ஜர்னலிங்கைப் பயன்படுத்துகின்றன.


The system first scans for revoke records when replaying the journal.

ஜர்னலை மீண்டும் இயக்கும்போது, அமைப்பு முதலில் ரத்துசெய்யும் பதிவுகளை ஸ்கேன் செய்கிறது.


Data journaling protocol involves writing transaction begin and end blocks.

தரவு ஜர்னலிங் நெறிமுறையில் பரிவர்த்தனை தொடக்க மற்றும் முடிவு தொகுதிகளை எழுதுவது அடங்கும்.


The effective rate of writing is dependent on the positioning time and peak transfer rate.

எழுதுவதற்கான பயனுள்ள விகிதம் நிலைப்படுத்தல் நேரம் மற்றும் உச்ச பரிமாற்ற விகிதத்தைப் பொறுத்தது.


LFS buffers all updates in an in-memory segment.

LFS அனைத்து புதுப்பிப்புகளையும் நினைவகப் பிரிவில் சேமிக்கிறது.


The inode map is a structure that takes an inode number as input.

ஐனோட் மேப் என்பது ஒரு ஐனோட் எண்ணை உள்ளீடாக எடுக்கும் ஒரு கட்டமைப்பு ஆகும்.


The details are critical in building a working system.

ஒரு வேலை செய்யும் அமைப்பை உருவாக்குவதில் விவரங்கள் முக்கியமானவை.


The file system can determine if the file is consistent by checking the pointers.

கோப்பு சுட்டிகளை சரிபார்ப்பதன் மூலம் கோப்பு நிலையானதா என்பதை கோப்பு முறை தீர்மானிக்க முடியும்.


This approach carefully orders all writes to the file system.

இந்த அணுகுமுறை கோப்பு முறைக்கு செய்யப்படும் அனைத்து எழுத்துக்களையும் கவனமாக வரிசைப்படுத்துகிறது.


The system uses a transaction checksum to detect inconsistencies.

நிலையின்மைகளைக் கண்டறிய அமைப்பு பரிவர்த்தனை சரிபார்ப்புத்தொகையைப் பயன்படுத்துகிறது.


The new updates are placed to previously unused locations on disk.

புதிய புதுப்பிப்புகள் முன்பு பயன்படுத்தப்படாத வட்டு இடங்களில் வைக்கப்படுகின்றன.


The file system checker works but is likely too slow on modern systems.

கோப்பு முறை சரிபார்ப்பாளர் வேலை செய்கிறார், ஆனால் நவீன அமைப்புகளில் மிகவும் மெதுவாக இருக்கலாம்.


Journaling reduces recovery time substantially after a crash.

ஒரு விபத்துக்குப் பிறகு ஜர்னலிங் மீட்பு நேரத்தை கணிசமாகக் குறைக்கிறது.


We have introduced the problem of crash consistency.

விபத்து நிலைத்தன்மை சிக்கலை நாங்கள் அறிமுகப்படுத்தியுள்ளோம்.


The disk is used efficiently, and performance of the file system approaches its zenith.

வட்டு திறமையாகப் பயன்படுத்தப்படுகிறது, மேலும் கோப்பு முறையின் செயல்திறன் அதன் உச்சத்தை அடைகிறது.


How can a file system turn all writes into sequential writes?

எப்படி ஒரு கோப்பு முறை அனைத்து எழுத்துக்களையும் தொடர்ச்சியான எழுத்துக்களாக மாற்ற முடியும்?


LFS never overwrites existing data, but rather always writes segments to free locations.

LFS ஒருபோதும் ஏற்கனவே உள்ள தரவை மேலெழுதுவதில்லை, மாறாக எப்போதும் பிரிவுகளை இலவச இடங்களில் எழுதுகிறது.


The imap, unfortunately, needs to be kept persistent.

துரதிர்ஷ்டவசமாக, imap தொடர்ந்து வைத்திருக்க வேண்டும்.


The allocated blocks and read the entire directory tree may take many minutes or hours.

ஒதுக்கப்பட்ட தொகுதிகளைப் படித்து, முழு கோப்பக மரத்தையும் படிக்க பல நிமிடங்களோ அல்லது மணிநேரங்களோ ஆகலாம்.


Performance offsck, as disks grew in capacity and RAIDs grew in popularity, became prohibitive.

வட்டுக்களின் கொள்ளளவு அதிகரித்ததால் மற்றும் RAID களின் புகழ் அதிகரித்ததால், செயல்திறன் குறைபாடு ஏற்பட்டது, இது தடைசெய்யப்பட்டது.


Consider our example above, where just three blocks are written to the disk.

மேலே உள்ள எங்கள் உதாரணத்தை எடுத்துக் கொள்ளுங்கள், அங்கு வெறும் மூன்று தொகுதிகள் மட்டுமே வட்டில் எழுதப்படுகின்றன.


This situation is akin to dropping your keys on the floor in your bedroom.

இந்த நிலை உங்கள் படுக்கையறையில் தரையில் உங்கள் சாவியைத் தவறவிடுவதைப் போன்றது.


Researchers and practitioners started to look for other solutions.

ஆராய்ச்சியாளர்களும் பயிற்சியாளர்களும் மற்ற தீர்வுகளைத் தேடத் தொடங்கினர்.


Probably the most popular solution to the consistent update problem is to steal an idea from the world of database management systems.

நிலையான புதுப்பிப்பு பிரச்சினைக்கான மிகவும் பிரபலமான தீர்வு, தரவுத்தள மேலாண்மை அமைப்புகளின் உலகில் இருந்து ஒரு யோசனையைத் திருடுவது ஆகும்.


That idea, known as write-ahead logging, was invented to address exactly this type of problem.

ரைட்-அஹெட் லாக்கிங் என்று அழைக்கப்படும் அந்த யோசனை, இந்த வகை சிக்கலைத் தீர்க்க கண்டுபிடிக்கப்பட்டது.


In file systems, we usually call write-ahead logging journaling for historical reasons.

கோப்பு அமைப்புகளில், வரலாற்று காரணங்களுக்காக நாம் பொதுவாக ரைட்-அஹெட் லாக்கிங்கை ஜர்னலிங் என்று அழைக்கிறோம்.


அடிப்படை யோசனை பின்வருமாறு.


When updating the disk, before overwriting the structures in place, first write down a little note describing what you are about to do.

வட்டைப் புதுப்பிக்கும்போது, அமைப்பில் உள்ள கட்டமைப்புகளை மேலெழுதுவதற்கு முன், நீங்கள் என்ன செய்யப் போகிறீர்கள் என்பதை விவரிக்கும் ஒரு சிறிய குறிப்பை முதலில் எழுதுங்கள்.


Writing this note is the “write ahead” part, and we write it to a structure that we organize as a “log”.

இந்தக் குறிப்பை எழுதுவது “முன்னதாக எழுதுதல்” பகுதி, மேலும் அதை நாம் ஒரு “லாக்” ஆக ஒழுங்கமைக்கும் ஒரு கட்டமைப்பிற்கு எழுதுகிறோம்.


By writing the note to disk, you are guaranteeing that if a crash takes places during the update, you can go back and look at the note you made and try again.

வட்டில் குறிப்பை எழுதுவதன் மூலம், புதுப்பிப்பின் போது செயலிழப்பு ஏற்பட்டால், நீங்கள் மீண்டும் சென்று நீங்கள் உருவாக்கிய குறிப்பைப் பார்த்து மீண்டும் முயற்சிக்க முடியும் என்பதை உறுதி செய்கிறீர்கள்.


By design, journaling thus adds a bit of work during updates to greatly reduce the amount of work required during recovery.

வடிவமைப்பின் மூலம், ஜர்னலிங் புதுப்பிப்புகளின் போது சிறிது வேலையைச் சேர்க்கிறது, மீட்பின் போது தேவையான வேலையின் அளவைக் கணிசமாகக் குறைக்கிறது.


We’ll now describe how Linux ext3, a popular journaling file system, incorporates journaling into the file system.

பிரபலமான ஜர்னலிங் கோப்பு முறைமையான லினக்ஸ் ext3, ஜர்னலிங்கை கோப்பு முறைமையில் எவ்வாறு ஒருங்கிணைக்கிறது என்பதை இப்போது விவரிப்போம்.


The new key structure is the journal itself, which occupies some small amount of space within the partition or on another device.

புதிய முக்கிய கட்டமைப்பு ஜர்னல் ஆகும், இது பகிர்வுக்குள் அல்லது மற்றொரு சாதனத்தில் சிறிய இடத்தை ஆக்கிரமிக்கிறது.


The real difference is just the presence of the journal, and of course, how it is used.

உண்மையான வித்தியாசம் ஜர்னலின் இருப்பு மற்றும் நிச்சயமாக, அது எவ்வாறு பயன்படுத்தப்படுகிறது என்பதாகும்.


Let’s look at a simple example to understand how data journaling works.

தரவு ஜர்னலிங் எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்ள ஒரு எளிய உதாரணத்தைப் பார்ப்போம்.


Say we have our canonical update again, where we wish to write the ‘inode (I[v2]), bitmap (B[v2]), and data block (Db) to disk again.

மீண்டும் நமது நியம புதுப்பிப்பு உள்ளது என்று வைத்துக்கொள்வோம், அங்கு ‘inode (I[v2]), பிட்மேப் (B[v2]), மற்றும் தரவு தொகுதி (Db) ஆகியவற்றை மீண்டும் வட்டில் எழுத விரும்புகிறோம்.


Before writing them to their final disk locations, we are now first going to write them to the log (a.k.a. journal).

அவற்றை இறுதி வட்டு இடங்களில் எழுதுவதற்கு முன், அவற்றை முதலில் லாக்கிற்கு (அதாவது ஜர்னல்) எழுதப் போகிறோம்.


You can see we have written five blocks here.

நாம் இங்கு ஐந்து தொகுதிகளை எழுதியுள்ளோம் என்பதை நீங்கள் காணலாம்.


When accessing a seemingly-working disk, it may return an error.

ஒரு தோற்றத்தில் வேலை செய்யும் வட்டை அணுகும் போது, அது ஒரு பிழையைத் திருப்பி அனுப்பலாம்.


அது தவறான தரவை எளிதாக திருப்பி அனுப்பலாம்.


Both of these types of faults are somewhat rare.

இந்த வகையான குறைபாடுகள் இரண்டும் ஓரளவு அரிதானவை.


The table summarizes some of the findings from the two studies.

இந்த அட்டவணை இரண்டு ஆய்வுகளின் சில கண்டுபிடிப்புகளை சுருக்கமாகக் கூறுகிறது.


The table shows the percent of drives that exhibited at least one LSE.

குறைந்தபட்சம் ஒரு LSE ஐக் காட்டிய டிரைவ்களின் சதவீதத்தை அட்டவணை காட்டுகிறது.


Buying better drives reduces the frequency of both types of problem.

சிறந்த டிரைவ்களை வாங்குவது இரண்டு வகையான பிரச்சனைகளின் அதிர்வெண்ணையும் குறைக்கிறது.


They still happen often enough that you need to think carefully about them.

அவை இன்னும் அடிக்கடி நிகழ்கின்றன, அதனால் நீங்கள் அவற்றைப் பற்றி கவனமாக சிந்திக்க வேண்டும்.


Costly drives with more than one LSE are as likely to develop additional errors as cheaper drives.

ஒன்றுக்கு மேற்பட்ட LSE கொண்ட விலையுயர்ந்த டிரைவ்கள், மலிவான டிரைவ்களைப் போலவே கூடுதல் பிழைகளை உருவாக்கும் வாய்ப்புள்ளது.


For most drives, annual error rate increases in year two.

பெரும்பாலான டிரைவ்களுக்கு, ஆண்டு பிழை விகிதம் இரண்டாவது ஆண்டில் அதிகரிக்கிறது.


வட்டு அளவு அதிகரிக்கும்போது LSE கள் அதிகரிக்கின்றன.


LSE கள் கொண்ட பெரும்பாலான வட்டுக்களில் 50 க்கும் குறைவாகவே உள்ளன.


Disks with LSEs are more likely to develop additional LSEs.

LSE கள் கொண்ட வட்டுக்கள் கூடுதல் LSE களை உருவாக்கும் வாய்ப்பு அதிகம்.


வட்டு தேய்த்தல் பயனுள்ளதாக இருக்கும்.


The chance of corruption varies greatly across different drive models.

ஊழல் ஏற்படும் வாய்ப்பு வெவ்வேறு டிரைவ் மாடல்களில் பெரிதும் வேறுபடுகிறது.


Age affects are different across models.

வயது விளைவுகள் மாதிரிகளில் வேறுபடுகின்றன.


Workload and disk size have little impact on corruption.

வேலைப்பளு மற்றும் வட்டு அளவு ஊழலில் சிறிய தாக்கத்தை ஏற்படுத்துகின்றன.


Most disks with corruption only have a few corruptions.

ஊழல் ஏற்பட்ட பெரும்பாலான வட்டுக்களில் சில ஊழல்கள் மட்டுமே உள்ளன.


Corruption is not independent with a disk or across disks in RAID.

ஊழல் ஒரு வட்டில் அல்லது RAID இல் உள்ள வட்டுக்களில் சுயாதீனமாக இல்லை.


There exists spatial locality, and some temporal locality.

இங்கு இடஞ்சார்ந்த உள்ளூர் தன்மை உள்ளது, மேலும் சில தற்காலிக உள்ளூர் தன்மையும் உள்ளது.


If you really wish to build a reliable storage system, you must include machinery to detect and recover from both LSEs and block corruption.

நீங்கள் உண்மையிலேயே நம்பகமான சேமிப்பு அமைப்பை உருவாக்க விரும்பினால், LSE கள் மற்றும் தொகுதி ஊழல் இரண்டையும் கண்டறிந்து மீட்டெடுப்பதற்கான இயந்திரங்களை நீங்கள் சேர்க்க வேண்டும்.


It turns out that file systems are more complex than they initially seem.

கோப்பு முறைமைகள் ஆரம்பத்தில் தோன்றியதை விட சிக்கலானவை என்பது தெரிய வருகிறது.


The paper discusses how file systems react to failures.

இந்த கட்டுரை கோப்பு முறைமைகள் தோல்விகளுக்கு எவ்வாறு வினைபுரிகின்றன என்பதைப் பற்றி விவாதிக்கிறது.


We found numerous bugs and design flaws in the file systems.

கோப்பு முறைமைகளில் ஏராளமான பிழைகள் மற்றும் வடிவமைப்பு குறைபாடுகளைக் கண்டறிந்தோம்.


This work has helped yield new, more robust file systems.

இந்த பணி புதிய, மிகவும் வலுவான கோப்பு முறைமைகளை உருவாக்க உதவியது.


This paper is about improving write performance in file systems.

இந்த கட்டுரை கோப்பு முறைமைகளில் எழுதும் செயல்திறனை மேம்படுத்துவது பற்றியது.


This classic paper defines terms for building fault-tolerant services.

இந்த உன்னதமான கட்டுரை, குறைபாடு-சகிப்புத்தன்மை கொண்ட சேவைகளை உருவாக்குவதற்கான சொற்களை வரையறுக்கிறது.


Building distributed systems is a challenging task.

விநியோகிக்கப்பட்ட அமைப்புகளை உருவாக்குவது ஒரு சவாலான பணியாகும்.


Data management for long-term storage is harder than in-memory data.

நீண்ட கால சேமிப்பிற்கான தரவு மேலாண்மை, நினைவகத்தில் உள்ள தரவை விட கடினமானது.


Persistent storage needs to last forever.

நிரந்தர சேமிப்பு எப்போதும் நீடிக்க வேண்டும்.


Updating persistent storage devices is complicated.

நிரந்தர சேமிப்பு சாதனங்களைப் புதுப்பிப்பது சிக்கலானது.


Recovery is a big deal when virtualizing memory.

நினைவகத்தை மெய்நிகராக்கும்போது மீட்பு ஒரு பெரிய விஷயம்.


Disk scheduling and data protection techniques are cool.

வட்டு திட்டமிடல் மற்றும் தரவு பாதுகாப்பு நுட்பங்கள் அருமையாக உள்ளன.


Erasure codes can be mathematically complex.

அழித்தல் குறியீடுகள் கணித ரீதியாக சிக்கலானதாக இருக்கலாம்.


Flash Translation Layers (FTLs) use log-structuring internally.

ஃப்ளாஷ் மொழிபெயர்ப்பு அடுக்குகள் (FTLகள்) உள்நாட்டில் பதிவு கட்டமைப்பைப் பயன்படுத்துகின்றன.


Locality is always useful in computer science.

கம்ப்யூட்டர் அறிவியலில் இருப்பிடம் எப்போதும் பயனுள்ளதாக இருக்கும்.


Distributed systems have changed the world.

விநியோகிக்கப்பட்ட அமைப்புகள் உலகை மாற்றியுள்ளன.


Building distributed systems is hard because things fail.

விநியோகிக்கப்பட்ட அமைப்புகளை உருவாக்குவது கடினம், ஏனெனில் விஷயங்கள் தோல்வியடைகின்றன.


Machines, disks, and networks fail from time to time.

இயந்திரங்கள், வட்டுக்கள் மற்றும் நெட்வொர்க்குகள் அவ்வப்போது தோல்வியடைகின்றன.


Communication is inherently unreliable in networking.

நெட்வொர்க்கிங்கில் தொடர்பு இயல்பாகவே நம்பகமற்றது.


We need reliable communication on top of an unreliable network.

நம்பகமற்ற நெட்வொர்க்கின் மேல் நம்பகமான தொடர்பு நமக்குத் தேவை.


LFS has just such a fixed place on disk for this, known as the checkpoint region (CR).

LFS ஆனது இதற்கு ஒரு நிலையான இடத்தை கொண்டுள்ளது, இது சரிபார்ப்பு பகுதி (CR) என அழைக்கப்படுகிறது.


The checkpoint region contains pointers to (i.e., ad- dresses of) the latest pieces of the inode map, and thus the inode map pieces can be found by reading the CR first.

சரிபார்ப்புப் பகுதியில், இனோட் வரைபடத்தின் சமீபத்திய பகுதிகளுக்கான சுட்டிகள் (அதாவது, முகவரிகள்) உள்ளன, எனவே CR ஐ முதலில் படிப்பதன் மூலம் இனோட் வரைபடப் பகுதிகளைக் கண்டறிய முடியும்.


To make sure you understand how LFS works, let us now walk through what must happen to read a file from disk.

LFS எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் புரிந்து கொண்டீர்களா என்பதை உறுதிப்படுத்த, ஒரு கோப்பை வட்டில் இருந்து படிக்க என்ன செய்ய வேண்டும் என்பதை இப்போது பார்க்கலாம்.


Assume we have nothing in memory to begin.

நாம் தொடங்குவதற்கு நினைவகத்தில் எதுவும் இல்லை என்று வைத்துக்கொள்வோம்.


The first on-disk data structure we must read is the checkpoint region.

நாம் படிக்க வேண்டிய முதல் வட்டு தரவு கட்டமைப்பு சரிபார்ப்பு பகுதி ஆகும்.


The checkpoint region contains pointers (i.e., disk ad- dresses) to the entire inode map, and thus LFS then reads in the entire in- ode map and caches it in memory.

சரிபார்ப்புப் பகுதியில் முழு இனோட் வரைபடத்திற்கான சுட்டிகள் (அதாவது, வட்டு முகவரிகள்) உள்ளன, எனவே LFS முழு இனோட் வரைபடத்தையும் படித்து அதை நினைவகத்தில் சேமிக்கிறது.


After this point, when given an inode number of a file, LFS simply looks up the inode-number to inode-disk- address mapping in the imap, and reads in the most recent version of the inode.

இந்த கட்டத்திற்குப் பிறகு, ஒரு கோப்பின் இனோட் எண் கொடுக்கப்பட்டால், LFS ஆனது imap இல் உள்ள இனோட்-எண் முதல் இனோட்-வட்டு-முகவரி வரைபடத்தை எளிமையாகப் பார்த்து, இனோட்டின் மிக சமீபத்திய பதிப்பை படிக்கிறது.


To access a file in a file system (such as /home/remzi/foo, one of our favorite fake file names), some directo- ries must be accessed too.

ஒரு கோப்பு முறைமையில் ஒரு கோப்பை அணுகுவதற்கு (/home/remzi/foo போன்றது, இது எங்கள் விருப்பமான போலி கோப்பு பெயர்களில் ஒன்றாகும்), சில கோப்பகங்களையும் அணுக வேண்டும்.


Fortunately, directory structure is basically identical to classic UNIX file systems, in that a directory is just a collection of (name, inode number) mappings.

அதிர்ஷ்டவசமாக, கோப்பக அமைப்பு அடிப்படையில் கிளாசிக் UNIX கோப்பு முறைமைகளைப் போன்றது, ஏனெனில் ஒரு கோப்பகம் என்பது (பெயர், இனோட் எண்) மேப்பிங்குகளின் தொகுப்பாகும்.


For example, when creating a file on disk, LFS must both write a new inode, some data, as well as the directory data and its inode that refer to this file.

உதாரணமாக, வட்டில் ஒரு கோப்பை உருவாக்கும்போது, LFS ஒரு புதிய இனோட், சில தரவு மற்றும் இந்த கோப்பைக் குறிக்கும் கோப்பக தரவு மற்றும் அதன் இனோட் இரண்டையும் எழுத வேண்டும்.


Remember that LFS will do so sequentially on the disk (after buffering the updates for some time).

LFS அதை வட்டில் வரிசையாக செய்யும் என்பதை நினைவில் கொள்ளுங்கள் (சில நேரம் புதுப்பிப்புகளைச் சேமித்த பிறகு).


Thus, creating a file foo in a directory would lead to the following new structures on disk:

எனவே, ஒரு கோப்பகத்தில் foo என்ற கோப்பை உருவாக்குவது வட்டில் பின்வரும் புதிய கட்டமைப்புகளுக்கு வழிவகுக்கும்:


The piece of the inode map contains the information for the location of both the directory file dir as well as the newly-created file f.

இனோட் வரைபடத்தின் பகுதி, கோப்பக கோப்பு dir மற்றும் புதிதாக உருவாக்கப்பட்ட கோப்பு f ஆகிய இரண்டின் இருப்பிடத்திற்கான தகவல்களைக் கொண்டுள்ளது.


You may have noticed another problem with LFS; it keeps writing newer version of a file, its inode, and in fact all data to new parts of the disk.

LFS உடன் மற்றொரு சிக்கலை நீங்கள் கவனித்திருக்கலாம்; இது ஒரு கோப்பின் புதிய பதிப்பு, அதன் இனோட் மற்றும் உண்மையில் அனைத்து தரவையும் வட்டின் புதிய பகுதிகளுக்கு தொடர்ந்து எழுதுகிறது.


அத்தகைய பழைய விஷயங்களை நாம் குப்பை என்று அழைக்கிறோம்.


For example, let’s imagine the case where we have an existing file referred to by inode number k, which points to a single data block D0.

உதாரணமாக, இனோட் எண் k ஆல் குறிப்பிடப்படும் ஏற்கனவே உள்ள கோப்பு உள்ளது என்று கற்பனை செய்வோம், இது ஒரு தரவுத் தொகுதி D0 ஐக் குறிக்கிறது.


By the simple act of overwriting a data block, a number of new structures must be persisted by LFS, thus leaving old versions of said blocks on the disk.

ஒரு தரவுத் தொகுதியை மேலெழுதுவதன் மூலம், பல புதிய கட்டமைப்புகள் LFS ஆல் நிலைத்திருக்க வேண்டும், இதனால் வட்டில் கூறப்பட்ட தொகுதிகளின் பழைய பதிப்புகள் விடப்படுகின்றன.


As another example, imagine we instead append a block to that original file k.

மற்றொரு உதாரணமாக, அந்த அசல் கோப்பு k க்கு பதிலாக ஒரு தொகுதியைச் சேர்க்கிறோம் என்று கற்பனை செய்து பாருங்கள்.


So what should we do with these older versions of inodes, datablocks, and so forth?

எனவே, இந்த பழைய இனோட்கள், தரவுத் தொகுதிகள் மற்றும் பலவற்றைப் பற்றி நாம் என்ன செய்ய வேண்டும்?


Cleaning became the focus of much controversy in LFS, and concerns over cleaning costs perhaps limited LFS’s initial impact on the field.

LFS இல் சுத்தம் செய்வது பெரும் சர்ச்சைக்குரியதாக மாறியது, மேலும் சுத்தம் செய்யும் செலவுகள் பற்றிய கவலைகள், LFS இன் ஆரம்பகால தாக்கத்தை இந்த துறையில் மட்டுப்படுத்தியது.


வாடிக்கையாளர் ஒரு கோரிக்கையை அனுப்புகிறார்.


This stateless approach will make more sense as we discuss the protocol.

நாம் நெறிமுறையைப் பற்றி விவாதிக்கும்போது இந்த நிலையற்ற அணுகுமுறை மிகவும் அர்த்தமுள்ளதாக இருக்கும்.


Consider the open() system call as an example.

உதாரணமாக open() சிஸ்டம் அழைப்பைக் கவனியுங்கள்.


The file descriptor is a piece of shared state between the client and the server.

கோப்பு விவரம் என்பது கிளையண்டிற்கும் சேவையகத்திற்கும் இடையே பகிரப்பட்ட நிலையாகும்.


Imagine the server crashes after the first read completes.

முதல் வாசிப்பு முடிந்த பிறகு சேவையகம் செயலிழந்துவிட்டதாக கற்பனை செய்து பாருங்கள்.


For these reasons, the designers of NFS decided to pursue a stateless approach.

இந்தக் காரணங்களுக்காக, NFS வடிவமைப்பாளர்கள் ஒரு நிலையற்ற அணுகுமுறையைப் பின்பற்ற முடிவு செய்தனர்.


How can we define the network protocol to enable stateless operation?

நிலையற்ற செயல்பாட்டை இயக்க, நெட்வொர்க் நெறிமுறையை எவ்வாறு வரையறுக்க முடியும்?


File handles are used to uniquely describe the file or directory.

கோப்பு அல்லது கோப்பகத்தை தனித்துவமாக விவரிக்க கோப்பு கைப்பிடிகள் பயன்படுத்தப்படுகின்றன.


The volume identifier informs the server which file system the request refers to.

தொகுதி அடையாளங்காட்டி, கோரிக்கை எந்த கோப்பு முறைமையைக் குறிக்கிறது என்பதை சேவையகத்திற்குத் தெரிவிக்கிறது.


The client can issue READ and WRITE protocol messages.

கிளையண்ட் READ மற்றும் WRITE நெறிமுறை செய்திகளை அனுப்பலாம்.


The READ protocol message requires the protocol to pass along the file handle.

READ நெறிமுறை செய்தி, கோப்பு கைப்பிடியை அனுப்ப நெறிமுறையை கோருகிறது.


The client-side file system tracks open files.

கிளையண்ட்-சைட் கோப்பு முறைமை திறந்த கோப்புகளைக் கண்காணிக்கிறது.


The server simply responds to each protocol message.

சேவையகம் ஒவ்வொரு நெறிமுறைக்கும் பதிலளிக்கிறது.


Idempotency is a useful property when building reliable systems.

நம்பகமான அமைப்புகளை உருவாக்கும்போது ஐடெம்போடென்சி ஒரு பயனுள்ள சொத்தாகும்.


கிளையண்ட் கோரிக்கையை மீண்டும் முயற்சிக்கிறது.


An operation is called idempotent when the effect of performing the operation multiple times is equivalent.

ஒரு செயல்பாட்டை பல முறை செய்வதன் விளைவு ஒரே மாதிரியாக இருக்கும்போது, அந்த செயல்பாடு ஐடெம்போடென்ட் என்று அழைக்கப்படுகிறது.


LOOKUP and READ requests are trivially idempotent.

LOOKUP மற்றும் READ கோரிக்கைகள் எளிதில் ஐடெம்போடென்ட் ஆகும்.


WRITE கோரிக்கைகளும் ஐடெம்போடென்ட் ஆகும்.


The client will retry it, the server will perform the write, and all will be well.

கிளையண்ட் அதை மீண்டும் முயற்சிக்கும், சேவையகம் எழுதும், எல்லாம் நன்றாக இருக்கும்.


Adding caching into any sort of system introduces a big and interesting challenge.

எந்தவொரு அமைப்பிலும் கேச்சிங்கைச் சேர்ப்பது ஒரு பெரிய மற்றும் சுவாரஸ்யமான சவாலை அறிமுகப்படுத்துகிறது.


The client issues system calls to the client-side file system.

கிளையன், கிளையன் பக்க கோப்பு முறைக்கு கணினி அழைப்புகளை அனுப்புகிறது.


In DSM systems, some accesses are inexpensive, but others cause page faults.

DSM அமைப்புகளில், சில அணுகல்கள் மலிவானவை, ஆனால் மற்றவை பக்கப் பிழைகளை ஏற்படுத்துகின்றன.


Imagine a linked list where a next pointer points into a portion of the address space that is gone.

அடுத்த சுட்டி இல்லாத முகவரி இடத்தின் ஒரு பகுதியைச் சுட்டிக்காட்டும் ஒரு இணைக்கப்பட்ட பட்டியலை கற்பனை செய்து பாருங்கள்.


The stub generator's job is simple: to remove some of the pain of packing function arguments.

ஸ்டப் ஜெனரேட்டரின் வேலை எளிதானது: செயல்பாடு வாதங்களை பேக் செய்வதில் உள்ள சில சிரமங்களை நீக்குவது.


The client calls func1(x); internally, the code in the client stub for func1() does this:

கிளையன் func1(x) ஐ அழைக்கிறது; உள்நாட்டில், func1()க்கான கிளையன் ஸ்டப்பில் உள்ள குறியீடு இதைச் செய்கிறது:


Create a message buffer. A message buffer is usually just a contiguous array of bytes.

ஒரு செய்தி இடையகத்தை உருவாக்குங்கள். ஒரு செய்தி இடையகம் பொதுவாக பைட்டுகளின் தொடர்ச்சியான வரிசையாகும்.


The process of putting all of this information into a single contiguous buffer is sometimes referred to as marshaling.

இந்த தகவலை அனைத்தையும் ஒரு ஒற்றை தொடர்ச்சியான இடையகத்தில் வைக்கும் செயல்முறை சில நேரங்களில் மார்ஷலிங் என்று அழைக்கப்படுகிறது.


Wait for the reply. Because function calls are usually synchronous, the call will wait for its completion.

பதிலுக்காக காத்திருங்கள். செயல்பாடு அழைப்புகள் பொதுவாக ஒத்திசைவாக இருப்பதால், அழைப்பு அதன் நிறைவுக்காக காத்திருக்கும்.


Unpack return code and other arguments. If the function just returns a single return code, this process is straightforward.

திரும்பும் குறியீடு மற்றும் பிற வாதங்களை அன் பேக் செய்யவும். செயல்பாடு ஒரு ஒற்றை திரும்பும் குறியீட்டை மட்டும் திரும்பினால், இந்த செயல்முறை நேரடியானது.


சேவையகத்திற்கும் குறியீடு உருவாக்கப்படுகிறது.


Unpack the message. This step, called unmarshaling or deserialization, takes the information out of the incoming message.

செய்தியை அன் பேக் செய்யவும். அன்மார்ஷலிங் அல்லது டீசெரியலைசேஷன் எனப்படும் இந்த படி, உள்வரும் செய்தியிலிருந்து தகவலை வெளியே எடுக்கிறது.


Call into the actual function. Finally! We have reached the point where the remote function is actually executed.

உண்மையான செயல்பாட்டிற்கு அழைக்கவும். இறுதியாக! தொலைநிலை செயல்பாடு உண்மையில் செயல்படுத்தப்படும் இடத்திற்கு வந்துவிட்டோம்.


Package the results. The return argument(s) are marshaled back into a single reply buffer.

முடிவுகளை தொகுக்கவும். திரும்பும் வாதங்கள் ஒரு ஒற்றை பதில் இடையகத்தில் மீண்டும் மார்ஷல் செய்யப்படுகின்றன.


Send the reply. The reply is finally sent to the caller.

பதிலை அனுப்புங்கள். பதில் இறுதியாக அழைப்பாளருக்கு அனுப்பப்படுகிறது.


Another important issue is the organization of the server with regards to concurrency.

மற்றொரு முக்கியமான பிரச்சினை, ஒரே நேரத்தில் செயல்படும் வகையில் சேவையகத்தை ஒழுங்கமைப்பதாகும்.


ஒரு பொதுவான அமைப்பு ஒரு திரெட் பூல் ஆகும்.


The run-time library handles much of the heavy lifting in an RPC system.

இயக்க நேர நூலகம் RPC அமைப்பில் பெரும்பாலான கனமான தூக்குதலைக் கையாளுகிறது.


One of the first challenges we must overcome is how to locate a remote service.

நாம் கடக்க வேண்டிய முதல் சவால்களில் ஒன்று, தொலைநிலை சேவையை எவ்வாறு கண்டுபிடிப்பது.


The simplest of approaches build on existing naming systems, e.g., hostnames and port numbers.

மிகவும் எளிமையான அணுகுமுறைகள் ஏற்கனவே உள்ள பெயரிடும் அமைப்புகளை உருவாக்குகின்றன, எ.கா., ஹோஸ்ட் பெயர்கள் மற்றும் போர்ட் எண்கள்.


In such a system, the client must know the hostname or IP address of the machine running the desired RPC service.

அத்தகைய அமைப்பில், விரும்பிய RPC சேவையை இயக்கும் இயந்திரத்தின் ஹோஸ்ட் பெயர் அல்லது IP முகவரியை கிளையன்ட் தெரிந்து கொள்ள வேண்டும்.


The server checks if the cached file is valid.

சேமித்த கோப்பு செல்லுபடியாகிறதா என சர்வர் சரிபார்க்கிறது.


If the cached copy is valid, the client can use it.

சேமித்த பிரதி செல்லுபடியாகும் என்றால், கிளையண்ட் அதைப் பயன்படுத்தலாம்.


If not, the client should fetch the newer version.

இல்லையென்றால், கிளையண்ட் புதிய பதிப்பை எடுக்க வேண்டும்.


Server recovery after a crash is more complicated.

செயலிழந்த பிறகு சர்வரை மீட்டெடுப்பது மிகவும் சிக்கலானது.


கால்பேக்குகள் நினைவகத்தில் வைக்கப்படுகின்றன.


The server has no idea which client has which files after reboot.

மறுதொடக்கம் செய்த பிறகு எந்த கிளையண்டில் எந்த கோப்புகள் உள்ளன என்பது சர்வருக்குத் தெரியாது.


Clients must realize the server has crashed.

சர்வர் செயலிழந்துவிட்டது என்பதை கிளையண்டுகள் உணர வேண்டும்.


அனைத்து சேமிப்பு உள்ளடக்கங்களையும் சந்தேகத்திற்குரியதாகக் கருதுங்கள்.


Re-establish the validity of a file before using it.

ஒரு கோப்பைப் பயன்படுத்துவதற்கு முன் அதன் செல்லுபடியாகும் தன்மையை மீண்டும் நிறுவவும்.


ஒரு சர்வர் செயலிழப்பு ஒரு பெரிய நிகழ்வு.


Ensure each client is aware of the crash.

ஒவ்வொரு கிளையண்ட்டும் செயலிழப்பு பற்றி அறிந்திருப்பதை உறுதிப்படுத்தவும்.


பழைய கோப்பை அணுகுவதற்கான ஆபத்து.


The server can send a message to each client.

சர்வர் ஒவ்வொரு கிளையண்ட்டிற்கும் ஒரு செய்தியை அனுப்பலாம்.


Clients check that the server is alive periodically.

கிளையண்டுகள் சர்வர் அவ்வப்போது இயங்குவதை சரிபார்க்கின்றன.


There is a cost to building a scalable caching model.

ஒரு அளவிடக்கூடிய சேமிப்பு மாதிரியை உருவாக்குவதில் ஒரு செலவு உள்ளது.


Clients hardly noticed a server crash with NFS.

NFS உடன், கிளையண்டுகள் சர்வர் செயலிழப்பை அரிதாகவே கவனித்தனர்.


AFSv2 was found to be much more scalable.

AFSv2 மிகவும் அளவிடக்கூடியதாகக் கண்டறியப்பட்டது.


Each server could support about 50 clients.

ஒவ்வொரு சேவையகமும் சுமார் 50 கிளையண்டுகளை ஆதரிக்க முடியும்.


Client-side performance came close to local performance.

கிளையன்ட் பக்க செயல்திறன் உள்ளூர் செயல்திறனுக்கு நெருக்கமாக வந்தது.


File reads usually went to the local disk cache.

கோப்பு ரீட் பொதுவாக உள்ளூர் வட்டு கேச் க்கு சென்றது.


The server crashed before writing the data to disk.

சேவையகம் தரவை வட்டில் எழுதுவதற்கு முன் செயலிழந்தது.


Clients handle server failure based on assumptions.

வாடிக்கையாளர்கள் சேவையக தோல்வியை அனுமானங்களின் அடிப்படையில் கையாளுகிறார்கள்.


Imagine the following sequence of writes as issued by a client.

ஒரு கிளையண்ட் வெளியிடும் பின்வரும் எழுத்து வரிசையை கற்பனை செய்து பாருங்கள்.


The server quickly restarts and receives the third write request, which also succeeds.

சேவையகம் உடனடியாக மறுதொடக்கம் செய்து மூன்றாவது எழுத்து கோரிக்கையைப் பெறுகிறது, இதுவும் வெற்றி பெறுகிறது.


To avoid this problem, NFS servers must commit each write to stable storage.

இந்த சிக்கலைத் தவிர்க்க, NFS சேவையகங்கள் ஒவ்வொரு எழுத்தையும் நிலையான சேமிப்பகத்திற்கு அனுப்ப வேண்டும்.


Write performance can be the major performance bottleneck.

எழுதுதல் செயல்திறன் முக்கிய செயல்திறன் தடையாக இருக்கலாம்.


NFS is centered around the idea of simple and fast recovery.

NFS ஆனது எளிய மற்றும் விரைவான மீட்பு என்ற கருத்தை மையமாகக் கொண்டது.


செயல்பாடுகளின் ஐடெம்போடென்சி அவசியம்.


We also have seen how the introduction of caching into a multiple-client, single-server system can complicate things.

பல கிளையண்ட், ஒற்றை சேவையக அமைப்பில் கேச்சிங்கை அறிமுகப்படுத்துவது விஷயங்களை எவ்வாறு சிக்கலாக்கும் என்பதையும் நாங்கள் பார்த்தோம்.


Security in early NFS implementations was remarkably lax.

ஆரம்பகால NFS செயலாக்கங்களில் பாதுகாப்பு குறிப்பிடத்தக்க வகையில் தளர்வாக இருந்தது.


The original NFS paper; though a bit of a challenging read.

அசல் NFS கட்டுரை; சற்று சவாலான வாசிப்பாக இருந்தாலும்.


The Andrew File System was introduced by researchers at Carnegie-Mellon University.

ஆண்ட்ரூ கோப்பு முறைமை கார்னகி-மெல்லன் பல்கலைக்கழக ஆராய்ச்சியாளர்களால் அறிமுகப்படுத்தப்பட்டது.


Most important is the design of the protocol between clients and servers.

மிக முக்கியமானது வாடிக்கையாளர்களுக்கும் சேவையகங்களுக்கும் இடையிலான நெறிமுறையின் வடிவமைப்பு ஆகும்.


In AFS, cache consistency is simple and readily understood.

AFS இல், கேச் நிலைத்தன்மை எளிமையானது மற்றும் எளிதில் புரிந்துகொள்ளக்கூடியது.


நாங்கள் AFS இன் இரண்டு பதிப்புகளைப் பற்றி விவாதிப்போம்.


One of the basic tenets of all versions of AFS is whole-file caching.

AFS இன் அனைத்து பதிப்புகளின் அடிப்படை கொள்கைகளில் ஒன்று முழு கோப்பு கேச்சிங் ஆகும்.


Subsequent application read() and write() operations are redirected to the local file system.

தொடர்ந்து வரும் பயன்பாட்டு read() மற்றும் write() செயல்பாடுகள் உள்ளூர் கோப்பு முறைமைக்கு திருப்பி விடப்படுகின்றன.


When a client application first calls open(), the AFS client-side code would send a Fetch protocol message.

ஒரு கிளையண்ட் பயன்பாடு முதலில் open() ஐ அழைக்கும்போது, AFS கிளையண்ட்-சைட் குறியீடு ஒரு Fetch நெறிமுறை செய்தியை அனுப்பும்.


The client-side code would then cache the file on the local disk.

கிளையண்ட்-சைட் குறியீடு பின்னர் கோப்பை உள்ளூர் வட்டில் சேமிக்கும்.


The server CPU became the bottleneck of the system.

சேவையக CPU அமைப்பின் தடையாக மாறியது.


The system uses time sharing to manage resources.

வளங்களை நிர்வகிக்க கணினி நேரப் பகிர்வைப் பயன்படுத்துகிறது.


Virtualization is a key concept in modern operating systems.

நவீன இயக்க முறைமைகளில் மெய்நிகராக்கம் ஒரு முக்கிய கருத்தாகும்.


The operating system provides the illusion of many CPUs.

இயக்க முறைமை பல CPU களின் மாயையை வழங்குகிறது.


How to efficiently virtualize the CPU with control?

கட்டுப்பாட்டுடன் CPU ஐ எவ்வாறு திறமையாக மெய்நிகராக்குவது?


நேரம்-இடம் வர்த்தகத்தை புரிந்து கொள்ளுங்கள்.


The book was typeset using the amazing LaTeX typesetting system.

இந்த புத்தகம் அற்புதமான LaTeX தட்டச்சு அமைப்பைப் பயன்படுத்தி தட்டச்சு செய்யப்பட்டது.


நேரப் பகிர்வு (மற்றும் இடப் பகிர்வு) பயன்படுத்தவும்.


ஒரு நிபந்தனைக்காக எவ்வாறு காத்திருப்பது?


The principle of isolation is important.

தனிமைப்படுத்தும் கொள்கை முக்கியமானது.


ஒரு விநியோகிக்கப்பட்ட கோப்பு முறையை எவ்வாறு உருவாக்குவது?


The system crashed due to a hardware failure.

வன்பொருள் செயலிழப்பு காரணமாக கணினி செயலிழந்தது.


நிரல் ஒரு டைமர் தடையைப் பயன்படுத்துகிறது.


The system uses a translation lookaside buffer.

கணினி மொழிபெயர்ப்பு லுக்அசைட் இடையகத்தைப் பயன்படுத்துகிறது.


விரிவாக்கப்பட்ட அணுகுமுறைகளைக் கவனியுங்கள்.


இலவச இடத்தை எவ்வாறு நிர்வகிப்பது?


The operating system is responsible for memory management.

நினைவக மேலாண்மைக்கு இயக்க முறைமை பொறுப்பாகும்.


நிபந்தனைகளுக்கு While (If அல்ல) பயன்படுத்தவும்.


How to efficiently and flexibly virtualize memory?

எவ்வாறு திறமையாகவும் நெகிழ்வாகவும் நினைவகத்தை மெய்நிகராக்குவது?


கணினி எழுதும்-முன்னோக்கு பதிவைப் பயன்படுத்துகிறது.


The RAID consistent-update problem is complex.

RAID நிலையான-புதுப்பிப்பு சிக்கல் சிக்கலானது.