Non-deadlock bugs make up a majority of concurrency bugs.

నాన్-డెడ్‌లాక్ లోపాలు సమాంతర లోపాలలో ఎక్కువ భాగాన్ని కలిగి ఉంటాయి.


అవి ఎలా వస్తాయి?


We now discuss the two major types of non-deadlock bugs.

ఇప్పుడు మనం రెండు ప్రధాన రకాల నాన్-డెడ్‌లాక్ లోపాల గురించి చర్చిద్దాం.


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

ఎదురయ్యే మొదటి రకం సమస్యను అటామిసిటీ ఉల్లంఘనగా సూచిస్తారు.


Here is a simple example, found in MySQL.

ఇక్కడ MySQL లో కనుగొనబడిన ఒక సాధారణ ఉదాహరణ ఉంది.


The more formal definition of an atomicity violation is this.

అటామిసిటీ ఉల్లంఘన యొక్క మరింత అధికారిక నిర్వచనం ఇది.


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 is known as deadlock.

పైన పేర్కొన్న సమాంతర లోపాలకు మించి, ఒక క్లాసిక్ సమస్య డెడ్‌లాక్‌గా పిలువబడుతుంది.


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

ఉదాహరణకు, ఒక థ్రెడ్ లాక్‌ను కలిగి ఉండి, మరొక దాని కోసం ఎదురు చూస్తున్నప్పుడు డెడ్‌లాక్ సంభవిస్తుంది.


పుస్తకం బల్ల మీద ఉంది.


మీరు ఎలా ఉన్నారు?


నేను మార్కెట్‌కి వెళ్తున్నాను.


ఈ రోజు వాతావరణం చాలా ఆహ్లాదకరంగా ఉంది.


దయచేసి తలుపు మూయండి.


మీరు నాకు ఇందులో సహాయం చేయగలరా?


కంపెనీ ఒక కొత్త ఉత్పత్తిని ప్రకటించింది.


ఆర్థిక వ్యవస్థ సవాళ్లను ఎదుర్కొంటోంది.


అతను చాలా ప్రతిభావంతుడైన సంగీత విద్వాంసుడు.


ఆమె ఇంగ్లీష్ బాగా మాట్లాడుతుంది.


The research team is working on a new project.

పరిశోధనా బృందం ఒక కొత్త ప్రాజెక్ట్‌పై పనిచేస్తోంది.


The algorithm efficiently sorts the data.

అల్గారిథం డేటాను సమర్ధవంతంగా క్రమబద్ధీకరిస్తుంది.


The system requires further optimization.

సిస్టమ్‌కు మరింత ఆప్టిమైజేషన్ అవసరం.


The software update will be released next week.

సాఫ్ట్‌వేర్ అప్‌డేట్ వచ్చే వారం విడుదల చేయబడుతుంది.


The meeting was adjourned due to lack of quorum.

కోరం లేకపోవడం వల్ల సమావేశం వాయిదా పడింది.


The implications of the policy change are significant.

విధాన మార్పు యొక్క పరిణామాలు చాలా ముఖ్యమైనవి.


కంపెనీ షేరు ధర బాగా పెరిగింది.


ప్రాజెక్ట్ షెడ్యూల్ ప్రకారం లేదు.


The data analysis revealed interesting insights.

డేటా విశ్లేషణ ఆసక్తికరమైన విషయాలను వెల్లడించింది.


The government is implementing new regulations.

ప్రభుత్వం కొత్త నిబంధనలను అమలు చేస్తోంది.


చిరునామా 0x1F3 = LBA తక్కువ బైట్.


చిరునామా 0x1F4 = LBA మధ్య బైట్.


చిరునామా 0x1F5 = LBA hi బైట్.


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

పరికరంతో పరస్పర చర్య జరపడానికి ప్రాథమిక ప్రోటోకాల్ క్రింది విధంగా ఉంది.


డ్రైవ్ సిద్ధంగా ఉండటానికి వేచి ఉండండి.


కమాండ్ రిజిస్టర్‌లకు పారామితులను వ్రాయండి.


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.

ERROR బిట్ ఆన్‌లో ఉంటే, వివరాల కోసం ఎర్రర్ రిజిస్టర్‌ను చదవండి.


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.

రెండవది 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()ని పిలుస్తారు.


అంతరాయాలు ఒక పురాతన ఆలోచన.


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?

ఆధునిక హార్డ్-డిస్క్ డ్రైవ్‌లు డేటాను ఎలా నిల్వ చేస్తాయి?


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.

థ్రెడ్‌లు, క్యూలు మరియు ఈవెంట్-ఆధారిత నిర్వహణను ఒక క్రమబద్ధమైన మొత్తం లోకి కలిపే ఈవెంట్-ఆధారిత సర్వింగ్‌పై మంచి మలుపు.


అయితే, ఇప్పుడు మీ తల నొప్పిగా ఉందా?


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.

నిజమే. కాన్కరెంట్ ఎగ్జిక్యూషన్ జరిగినప్పుడు, చాలా తక్కువ లైన్ల కోడ్ అర్థం చేసుకోవడం దాదాపు అసాధ్యం కావడం నాకు ఎప్పుడూ ఆశ్చర్యం కలిగిస్తుంది.


అధ్యాపకులు ... ఉహ్ ... తప్పు చేయవచ్చు?


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 concurrency 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 simplified forms.

మూడవది, మీకు నిజంగా సమాంతరత అవసరమైతే, ఇతర సరళీకృత రూపాల్లో వెతకండి.


Student: Map-Reduce, huh? Sounds interesting – I’ll have to read more about it on my own.

విద్యార్థి: మ్యాప్-రెడ్యూస్, హహ్? ఆసక్తికరంగా ఉంది - నేను దాని గురించి సొంతంగా మరింత చదవాలి.


Good! You should. In the end, you’ll have to do a lot of that, as what we learn together can only serve as the barest introduction to the wealth of knowledge that is out there.

మంచిది! మీరు చేయాలి. చివరికి, మీరు చాలా చేయాలి, ఎందుకంటే మనం కలిసి నేర్చుకున్నది అక్కడ ఉన్న జ్ఞాన సంపదకు చాలా పరిచయంగా మాత్రమే ఉపయోగపడుతుంది.


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?

మీరు మూడు స్తంభాలు అని చెప్పారా, లేక నాలుగు అని చెప్పారా? నాల్గవది ఏమిటి?


Imagine you are outside, in a field, and you pick a –

మీరు బయట, ఒక పొలంలో ఉన్నారని ఊహించుకోండి, మరియు మీరు ఒకదాన్ని తీసుకుంటారు -


The Cheetah and Barracuda drives have different characteristics.

చిరుత మరియు బారకుడా డ్రైవ్‌లు వేర్వేరు లక్షణాలను కలిగి ఉన్నాయి.


These drives nicely summarize two important components of the disk drive market.

ఈ డ్రైవ్‌లు డిస్క్ డ్రైవ్ మార్కెట్‌లోని రెండు ముఖ్యమైన భాగాలను చక్కగా సంగ్రహిస్తాయి.


The first is the “high performance” drive market.

మొదటిది “అధిక పనితీరు” డ్రైవ్ మార్కెట్.


రెండవది “సామర్థ్యం” మార్కెట్.


Cost per byte is the most important aspect.

ప్రతి బైట్‌కు అయ్యే ఖర్చు చాలా ముఖ్యమైన అంశం.


The drives are slower but pack as many bits as possible.

డ్రైవ్‌లు నెమ్మదిగా ఉంటాయి, కానీ వీలైనన్ని ఎక్కువ బిట్‌లను ప్యాక్ చేస్తాయి.


Let’s start by looking at the random workload.

యాదృచ్ఛిక పనిభారాన్ని పరిశీలించడం ద్వారా ప్రారంభిద్దాం.


Assuming each 4 KB read occurs at a random location on disk.

ప్రతి 4 KB రీడ్ డిస్క్‌లో యాదృచ్ఛిక స్థానంలో జరుగుతుందని అనుకుందాం.


The average seek time is just taken as the average time reported by the manufacturer.

సగటు శోధన సమయం తయారీదారు నివేదించిన సగటు సమయంగా తీసుకోబడుతుంది.


Transfer data to and from disks in a sequential manner.

డేటాను సీక్వెన్షియల్ పద్ధతిలో డిస్క్‌లకు బదిలీ చేయండి.


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

అనుక్రమం సాధ్యం కాకపోతే, కనీసం పెద్ద ముక్కలుగా డేటాను బదిలీ చేయడం గురించి ఆలోచించండి.


I/O performance will suffer dramatically.

I/O పనితీరు నాటకీయంగా ప్రభావితమవుతుంది.


The average rotational delay is calculated from the RPM directly.

సగటు భ్రమణ ఆలస్యం నేరుగా RPM నుండి లెక్కించబడుతుంది.


The rates of I/O are thus very nearly the peak transfer rates.

అందువల్ల, I/O రేట్లు గరిష్ట బదిలీ రేట్లకు చాలా దగ్గరగా ఉంటాయి.


There is a huge gap in drive performance between random and sequential workloads.

యాదృచ్ఛిక మరియు సీక్వెన్షియల్ పనిభారాల మధ్య డ్రైవ్ పనితీరులో భారీ అంతరం ఉంది.


People are often willing to pay top dollar for the former.

మునుపటి వాటి కోసం ప్రజలు తరచుగా ఎక్కువ డబ్బు చెల్లించడానికి సిద్ధంగా ఉంటారు.


డిస్క్‌ను ట్రాక్‌ల సమితిగా ఊహించుకోండి.


SSTF orders the queue of I/O requests by track.

SSTF I/O అభ్యర్థనల క్యూను ట్రాక్ ద్వారా ఆర్డర్ చేస్తుంది.


ఈ ఉదాహరణలో SSTF బాగా పనిచేస్తుంది.


The second problem is more fundamental: starvation.

రెండవ సమస్య మరింత ప్రాథమికమైనది: ఆకలి.


RAID systems can tolerate the loss of a disk and keep operating.

RAID వ్యవస్థలు ఒక డిస్క్ నష్టాన్ని భరించగలవు మరియు పనిచేస్తూనే ఉంటాయి.


Administrators could install a SCSI-based RAID storage array instead of a SCSI disk.

నిర్వాహకులు SCSI డిస్క్‌కు బదులుగా SCSI-ఆధారిత RAID నిల్వ శ్రేణిని వ్యవస్థాపించవచ్చు.


RAID was made more successful from day one because it solved the problem of deployment.

RAID వ్యవస్థాపన సమస్యను పరిష్కరించినందున మొదటి రోజు నుంచే మరింత విజయవంతమైంది.


A RAID just looks like a big disk to the host system.

RAID హోస్ట్ సిస్టమ్‌కు పెద్ద డిస్క్ లాగా కనిపిస్తుంది.


The operating system and client applications continue to operate without modification.

ఆపరేటింగ్ సిస్టమ్ మరియు క్లయింట్ అప్లికేషన్‌లు మార్పు లేకుండా పనిచేస్తూనే ఉంటాయి.


Transparency greatly improves the deployability of RAID.

పారదర్శకత RAID యొక్క విస్తరణను బాగా మెరుగుపరుస్తుంది.


We now discuss some of the important aspects of RAIDs.

ఇప్పుడు మనం RAIDల యొక్క కొన్ని ముఖ్యమైన అంశాలను చర్చిద్దాం.


A RAID looks like a big, fast, and reliable disk to a file system.

RAID ఫైల్ సిస్టమ్‌కు పెద్దది, వేగవంతమైనది మరియు నమ్మదగిన డిస్క్ లాగా కనిపిస్తుంది.


The exact nature of these physical I/Os depends on the RAID level.

ఈ భౌతిక I/Oల యొక్క ఖచ్చితమైన స్వభావం 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 have a processor, memory, and disks.

RAIDలకు ప్రాసెసర్, మెమరీ మరియు డిస్క్‌లు ఉన్నాయి.


RAIDs are designed to detect and recover from certain kinds of disk faults.

కొన్ని రకాల డిస్క్ లోపాలను గుర్తించడానికి మరియు వాటి నుండి కోలుకోవడానికి RAIDలు రూపొందించబడ్డాయి.


In this model, a disk can be in exactly one of two states: working or failed.

ఈ నమూనాలో, ఒక డిస్క్ ఖచ్చితంగా రెండు స్థితులలో ఒకదానిలో ఉండవచ్చు: పని చేయడం లేదా విఫలమవడం.


We will evaluate each RAID design along three axes.

మేము మూడు అక్షాల వెంట ప్రతి RAID డిజైన్‌ను మూల్యాంకనం చేస్తాము.


మొదటి అక్షం సామర్థ్యం.


Striping delivers N disks worth of useful capacity.

స్ట్రిపింగ్ N డిస్క్‌ల విలువైన ఉపయోగకరమైన సామర్థ్యాన్ని అందిస్తుంది.


Any disk failure will lead to data loss.

ఏదైనా డిస్క్ వైఫల్యం డేటా నష్టానికి దారి తీస్తుంది.


Performance is excellent: all disks are utilized, often in parallel, to service user I/O requests.

పనితీరు చాలా బాగుంది: వినియోగదారు I/O అభ్యర్థనలను అందించడానికి అన్ని డిస్క్‌లు ఉపయోగించబడతాయి, తరచుగా సమాంతరంగా.


I want to call stat() on each file to get more information.

ప్రతి ఫైల్ గురించి మరింత సమాచారం పొందడానికి నేను ప్రతి ఫైల్‌పై stat()ని పిలవాలనుకుంటున్నాను.


This is exactly what ls does when you pass it the -l flag.

మీరు -l ఫ్లాగ్‌ను పాస్ చేసినప్పుడు ls చేసేది ఇదే.


Try trace on ls with and without that flag to see for yourself.

మీరే స్వయంగా చూడటానికి ఆ ఫ్లాగ్ లేకుండా మరియు లేకుండా lsలో ట్రేస్ చేయడానికి ప్రయత్నించండి.


Finally, you can delete a directory with a call to rmdir().

చివరగా, మీరు rmdir()కి కాల్ చేయడంతో డైరెక్టరీని తొలగించవచ్చు.


Unlike file deletion, removing directories is more dangerous.

ఫైల్ తొలగింపుతో పోలిస్తే, డైరెక్టరీలను తొలగించడం మరింత ప్రమాదకరం.


The rmdir() has the requirement that the directory be empty.

rmdir() డైరెక్టరీ ఖాళీగా ఉండాలనే అవసరాన్ని కలిగి ఉంది.


If you try to delete a non-empty directory, the call to rmdir() will fail.

మీరు ఖాళీగా లేని డైరెక్టరీని తొలగించడానికి ప్రయత్నిస్తే, rmdir()కి కాల్ విఫలమవుతుంది.


We now come back to the mystery of why removing a file is performed via unlink().

ఫైల్‌ను తొలగించడం ఎందుకు unlink() ద్వారా చేయబడుతుందనే రహస్యానికి ఇప్పుడు తిరిగి వద్దాం.


The link() system call takes two arguments.

link() సిస్టమ్ కాల్ రెండు వాదనలను తీసుకుంటుంది.


When you link a new file name to an old one, you essentially create another way to refer to the same file.

మీరు కొత్త ఫైల్ పేరును పాతదానికి లింక్ చేసినప్పుడు, మీరు తప్పనిసరిగా ఒకే ఫైల్‌ను సూచించడానికి మరొక మార్గాన్ని సృష్టిస్తారు.


The command-line program ln is used to do this.

దీన్ని చేయడానికి కమాండ్-లైన్ ప్రోగ్రామ్ ln ఉపయోగించబడుతుంది.


Here we created a file with the word hello in it.

ఇక్కడ మేము హలో అనే పదం ఉన్న ఫైల్‌ను సృష్టించాము.


We then create a hard link to that file using the ln program.

అప్పుడు మేము ln ప్రోగ్రామ్‌ని ఉపయోగించి ఆ ఫైల్‌కు హార్డ్ లింక్‌ను సృష్టిస్తాము.


After this, we can examine the file by either opening file or file2.

దీని తరువాత, మేము ఫైల్ లేదా ఫైల్2ని తెరవడం ద్వారా ఫైల్‌ను పరిశీలించవచ్చు.


The way link works is that it simply creates another name in the directory.

లింక్ పని చేసే విధానం ఏమిటంటే, ఇది డైరెక్టరీలో మరొక పేరును సృష్టిస్తుంది.


ఫైల్ ఏ విధంగానూ కాపీ చేయబడలేదు.


We can even see this in the directory itself.

దీనిని మనం డైరెక్టరీలోనే చూడవచ్చు.


By passing the -i flag to ls, it prints out the inode number of each file.

lsకి -i ఫ్లాగ్‌ను పంపడం ద్వారా, ఇది ప్రతి ఫైల్ యొక్క ఐనోడ్ నంబర్‌ను ప్రింట్ చేస్తుంది.


When you create a file, you are really doing two things.

మీరు ఫైల్‌ను సృష్టించినప్పుడు, మీరు నిజంగా రెండు పనులు చేస్తున్నారు.


Thus, to remove a file from the file system, we call unlink().

అందువల్ల, ఫైల్ సిస్టమ్ నుండి ఫైల్‌ను తీసివేయడానికి, మేము unlink()ని పిలుస్తాము.


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, బిట్‌లలో సరి సంఖ్యలో 1లు ఉంటే 0ని మరియు బేసి సంఖ్యలో 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 నిర్వహించాల్సిన స్థిరమైనది ఇదే.


Imagine the column la- beled C2 is lost.

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-ఆధారిత సమానత్వ పథకంలో పునర్నిర్మాణం ఎలా పనిచేస్తుందో!


Note also how we compute the reconstructed value: we just XOR the data bits and the parity bits together, in the same way that we calculated the parity in the first place.

పునర్నిర్మించిన విలువను మనం ఎలా లెక్కిస్తామో కూడా గమనించండి: మనం డేటా బిట్‌లను మరియు పారిటీ బిట్‌లను కలిపి 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 బ్లాక్ కంటే చాలా చిన్నది, కానీ మీకు అర్థమవుతుంది), అవి ఇలా ఉండవచ్చు:


As you can see from the figure, the parity is computed for each bit of each block and the result placed in the parity block.

చిత్రంలో చూసినట్లుగా, ప్రతి బ్లాక్ యొక్క ప్రతి బిట్‌కు సమానత్వం లెక్కించబడుతుంది మరియు ఫలితం పారిటీ బ్లాక్‌లో ఉంచబడుతుంది.


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).


The directory 'foo' would have an entry ('foo', '10') that maps the user-readable name to the low-level name.

'foo' అనే డైరెక్టరీలో ('foo', '10') అనే ఎంట్రీ ఉంటుంది, ఇది యూజర్-రీడబుల్ పేరును లో-లెవెల్ పేరుకు మ్యాప్ చేస్తుంది.


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.

డైరెక్టరీలను ఇతర డైరెక్టరీలలో ఉంచడం ద్వారా, వినియోగదారులు ఒక నిర్దిష్ట డైరెక్టరీ ట్రీని నిర్మించగలరు.


The directory hierarchy starts at a root directory.

డైరెక్టరీ శ్రేణి ఒక రూట్ డైరెక్టరీ వద్ద ప్రారంభమవుతుంది.


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.

ఉదాహరణకు, ఒక వినియోగదారు రూట్ డైరెక్టరీలో 'foo' అనే డైరెక్టరీని సృష్టించి, ఆపై 'foo' డైరెక్టరీలో 'bar.txt' అనే ఫైల్‌ను సృష్టించినట్లయితే, మేము దాని పూర్తి మార్గం ద్వారా ఫైల్‌ను సూచించవచ్చు.


Directories and files can have the same name as long as they are in different locations in the file-system tree.

ఫైల్-సిస్టమ్ ట్రీలో అవి వేర్వేరు స్థానాల్లో ఉన్నంత కాలం డైరెక్టరీలు మరియు ఫైల్‌లు ఒకే పేరును కలిగి ఉండవచ్చు.


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.

పేరు పెట్టడంలో ఈ ఏకరూపత మీ సిస్టమ్ యొక్క భావన నమూనాను సులభతరం చేస్తుంది.


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.

దీనిని ఓపెన్ సిస్టమ్ కాల్‌తో సాధించవచ్చు.


Here is some example code to create a file called “foo” in the current working directory.

ప్రస్తుత వర్కింగ్ డైరెక్టరీలో “foo” అనే ఫైల్‌ను సృష్టించడానికి ఇక్కడ కొన్ని ఉదాహరణ కోడ్ ఉంది.


The routine open() takes a number of different flags.

ఓపెన్() అనే రొటీన్ అనేక విభిన్న ఫ్లాగ్‌లను తీసుకుంటుంది.


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

ఓపెన్() యొక్క ఒక ముఖ్యమైన అంశం ఏమిటంటే అది ఏమి అందిస్తుంది: ఒక ఫైల్ డిస్క్రిప్టర్.


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

మనకు కొన్ని ఫైల్‌లు ఉన్న తర్వాత, మనం వాటిని చదవడానికి లేదా వ్రాయడానికి ఇష్టపడవచ్చు.


The inode is a structure that holds metadata for a file.

ఒక ఫైల్ కోసం మెటాడేటాను కలిగి ఉన్న నిర్మాణం ఇనోడ్.


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

ఆన్-డిస్క్ ఇనోడ్‌ల శ్రేణిలోకి సూచిక చేయడానికి ఇనోడ్ సంఖ్య ఉపయోగించబడుతుంది.


Most modern systems have a structure like this for every file they track.

చాలా ఆధునిక వ్యవస్థలు వారు ట్రాక్ చేసే ప్రతి ఫైల్ కోసం ఇలాంటి నిర్మాణాన్ని కలిగి ఉంటాయి.


Each inode is implicitly referred to by a number, which we’ve earlier called the low-level name of the file.

ప్రతి ఇనోడ్‌ను ఒక సంఖ్య ద్వారా సూచిస్తారు, దీనిని మేము ఇంతకు ముందు ఫైల్ యొక్క లో-లెవెల్ పేరు అని పిలిచాము.


In vsfs, given an i-number, you should directly be able to calculate where on the disk the corresponding inode is located.

vsfsలో, i-సంఖ్య ఇచ్చినట్లయితే, సంబంధిత ఇనోడ్ డిస్క్‌లో ఎక్కడ ఉందో మీరు నేరుగా లెక్కించగలగాలి.


The inode table of vsfs is 20-KB in size and consists of 80 inodes.

vsfs యొక్క ఇనోడ్ టేబుల్ 20-KB పరిమాణంలో ఉంది మరియు 80 ఇనోడ్‌లను కలిగి ఉంది.


To read inode number 32, the file system would first calculate the offset into the inode region.

ఇనోడ్ సంఖ్య 32ని చదవడానికి, ఫైల్ సిస్టమ్ మొదట ఇనోడ్ ప్రాంతంలోకి ఆఫ్‌సెట్‌ను లెక్కిస్తుంది.


Inside each inode is virtually all of the information you need about a file.

ప్రతి ఇనోడ్‌లో మీకు ఫైల్ గురించి అవసరమైన దాదాపు మొత్తం సమాచారం ఉంటుంది.


One simple approach would be to have one or more direct pointers inside the inode.

ఒక సాధారణ విధానం ఏమిటంటే ఇనోడ్‌లో ఒకటి లేదా అంతకంటే ఎక్కువ ప్రత్యక్ష పాయింటర్‌లను కలిగి ఉండటం.


To support bigger files, file system designers have had to introduce different structures within inodes.

పెద్ద ఫైల్‌లకు మద్దతు ఇవ్వడానికి, ఫైల్ సిస్టమ్ డిజైనర్లు ఇనోడ్‌లలో వేర్వేరు నిర్మాణాలను ప్రవేశపెట్టవలసి వచ్చింది.


One common idea is to have a special pointer known as an indirect pointer.

ఒక సాధారణ ఆలోచన ఏమిటంటే, పరోక్ష పాయింటర్ అని పిలువబడే ప్రత్యేక పాయింటర్‌ను కలిగి ఉండటం.


If a file grows large enough, an indirect block is allocated.

ఒక ఫైల్ తగినంత పెద్దదిగా పెరిగితే, ఒక పరోక్ష బ్లాక్ కేటాయించబడుతుంది.


A different approach is to use extents instead of pointers.

వేరే విధానం ఏమిటంటే పాయింటర్‌లకు బదులుగా ఎక్స్‌టెంట్‌లను ఉపయోగించడం.


Extent-based approaches are less flexible but more compact.

ఎక్స్‌టెంట్-ఆధారిత విధానాలు తక్కువ సౌకర్యవంతంగా ఉంటాయి కానీ మరింత కాంపాక్ట్‌గా ఉంటాయి.


To do so, just add another pointer to the inode: the double indirect pointer.

అలా చేయడానికి, ఇనోడ్‌కు మరొక పాయింటర్‌ను జోడించండి: డబుల్ పరోక్ష పాయింటర్.


Overall, this imbalanced tree is referred to as the multi-level index approach.

మొత్తంమీద, ఈ అసమతుల్య చెట్టును బహుళ-స్థాయి సూచిక విధానంగా సూచిస్తారు.


Many file systems use a multi-level index.

అనేక ఫైల్ సిస్టమ్‌లు బహుళ-స్థాయి సూచికను ఉపయోగిస్తాయి.


Another simpler approach in designing inodes is to use a linked list.

ఇనోడ్‌లను రూపొందించడంలో మరొక సాధారణ విధానం లింక్డ్ జాబితాను ఉపయోగించడం.


Linked file allocation performs poorly for some workloads.

కొన్ని వర్క్‌లోడ్‌ల కోసం లింక్డ్ ఫైల్ కేటాయింపు సరిగ్గా పని చేయదు.


డైరెక్టరీలు ఒక సాధారణ సంస్థను కలిగి ఉంటాయి.


How can a file system accomplish any of this with reasonable efficiency?

ఒక ఫైల్ సిస్టమ్ ఈ పనిని ఎలా సహేతుకమైన సామర్థ్యంతో సాధించగలదు?


Even the simplest of operations like opening, reading, or writing a file incurs a huge number of I/O operations, scattered over the disk.

ఒక ఫైల్‌ను తెరవడం, చదవడం లేదా వ్రాయడం వంటి సాధారణ కార్యకలాపాలు కూడా చాలా I/O కార్యకలాపాలను కలిగి ఉంటాయి, ఇవి డిస్క్‌పై చెల్లాచెదురుగా ఉంటాయి.


To remedy what would clearly be a huge performance problem, most file systems aggressively use system memory (DRAM) to cache important blocks.

స్పష్టంగా భారీ పనితీరు సమస్యను పరిష్కరించడానికి, చాలా ఫైల్ సిస్టమ్‌లు ముఖ్యమైన బ్లాక్‌లను కాష్ చేయడానికి సిస్టమ్ మెమరీని (DRAM) దూకుడుగా ఉపయోగిస్తాయి.


Imagine the open example above: without caching, every file open would require at least two reads for every level in the directory hierarchy.

పై ఓపెన్ ఉదాహరణను ఊహించండి: కాషింగ్ లేకుండా, ప్రతి ఫైల్ తెరవడానికి డైరెక్టరీ శ్రేణిలోని ప్రతి స్థాయికి కనీసం రెండు రీడ్‌లు అవసరం.


Early file systems thus introduced a fix-sized cache to hold popular blocks.

అందువల్ల ప్రారంభ ఫైల్ సిస్టమ్‌లు ప్రసిద్ధ బ్లాక్‌లను కలిగి ఉండటానికి స్థిర పరిమాణ కాష్‌ను ప్రవేశపెట్టాయి.


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

ఆధునిక వ్యవస్థలు వర్చువల్ మెమరీ పేజీలు మరియు ఫైల్ సిస్టమ్ పేజీలను ఏకీకృత పేజీ కాష్‌గా అనుసంధానిస్తాయి.


The first open may generate a lot of I/O traffic to read in directory inode and data, but subsequent file opens of that same file will mostly hit in the cache and thus no I/O is needed.

మొదటి ఓపెన్ డైరెక్టరీ ఐనోడ్ మరియు డేటాను చదవడానికి చాలా I/O ట్రాఫిక్‌ను ఉత్పత్తి చేయవచ్చు, కానీ అదే ఫైల్ యొక్క తదుపరి ఫైల్ ఓపెన్‌లు ఎక్కువగా కాష్‌లో హిట్ అవుతాయి మరియు అందువల్ల I/O అవసరం లేదు.


First, by delaying writes, the file system can batch some updates into a smaller set of I/Os.

ముందుగా, వ్రాతలను ఆలస్యం చేయడం ద్వారా, ఫైల్ సిస్టమ్ కొన్ని నవీకరణలను చిన్న I/Oల సమితిగా సమూహపరచవచ్చు.


Second, by buffering a number of writes in memory, the system can then schedule the subsequent I/Os and thus increase performance.

రెండవది, మెమరీలో అనేక వ్రాతలను బఫరింగ్ చేయడం ద్వారా, సిస్టమ్ తదుపరి I/Oలను షెడ్యూల్ చేయగలదు మరియు తద్వారా పనితీరును పెంచుతుంది.


Finally, some writes are avoided altogether by delaying them; for example, if an application creates a file and then deletes it, delaying the writes to reflect the file creation to disk avoids them entirely.

చివరగా, కొన్ని వ్రాతలను వాటిని ఆలస్యం చేయడం ద్వారా పూర్తిగా నివారించవచ్చు; ఉదాహరణకు, ఒక అప్లికేషన్ ఒక ఫైల్‌ను సృష్టించి, ఆపై దాన్ని తొలగిస్తే, ఫైల్ సృష్టిని డిస్క్‌కు ప్రతిబింబించేలా వ్రాతలను ఆలస్యం చేయడం వాటిని పూర్తిగా నివారిస్తుంది.


For the reasons above, most modern file systems buffer writes in memory for anywhere between five and thirty seconds.

పై కారణాల వల్ల, చాలా ఆధునిక ఫైల్ సిస్టమ్‌లు ఐదు నుండి ముప్పై సెకన్ల వరకు ఎక్కడైనా మెమరీలో వ్రాతలను బఫర్ చేస్తాయి.


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

ఫైల్ సిస్టమ్‌ను నిర్మించడానికి అవసరమైన ప్రాథమిక యంత్రాంగాన్ని మనం చూశాము.


There needs to be some information about each file (metadata), usually stored in a structure called an inode.

ప్రతి ఫైల్ గురించి కొంత సమాచారం (మెటాడేటా) ఉండాలి, సాధారణంగా ఐనోడ్ అని పిలువబడే నిర్మాణంలో నిల్వ చేయబడుతుంది.


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

డైరెక్టరీలు పేరు→ఐనోడ్-సంఖ్య మ్యాపింగ్‌లను నిల్వ చేసే ఒక నిర్దిష్ట రకం ఫైల్ మాత్రమే.


And other structures are needed too; for example, file systems often use a structure such as a bitmap to track which inodes or data blocks are free or allocated.

మరియు ఇతర నిర్మాణాలు కూడా అవసరం; ఉదాహరణకు, ఫైల్ సిస్టమ్‌లు తరచుగా ఏ ఐనోడ్‌లు లేదా డేటా బ్లాక్‌లు ఉచితంగా ఉన్నాయో లేదా కేటాయించబడ్డాయో ట్రాక్ చేయడానికి బిట్‌మ్యాప్ వంటి నిర్మాణాన్ని ఉపయోగిస్తాయి.


The terrific aspect of file system design is its freedom; the file systems we explore in the coming chapters each take advantage of this freedom to optimize some aspect of the file system.

ఫైల్ సిస్టమ్ రూపకల్పన యొక్క అద్భుతమైన అంశం దాని స్వేచ్ఛ; రాబోయే అధ్యాయాలలో మనం అన్వేషించే ఫైల్ సిస్టమ్‌లు ప్రతి ఒక్కటి ఫైల్ సిస్టమ్ యొక్క కొన్ని అంశాలను ఆప్టిమైజ్ చేయడానికి ఈ స్వేచ్ఛను ఉపయోగించుకుంటాయి.


When the UNIX operating system was first introduced, the UNIX wizard himself Ken Thompson wrote the first file system.

UNIX ఆపరేటింగ్ సిస్టమ్‌ను మొదట పరిచయం చేసినప్పుడు, UNIX విజార్డ్ కెన్ థాంప్సన్ మొదటి ఫైల్ సిస్టమ్‌ను రాశారు.


సమస్య: పనితీరు చాలా దారుణంగా ఉంది.


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

ప్రధాన సమస్య ఏమిటంటే పాత UNIX ఫైల్ సిస్టమ్ డిస్క్‌ను యాదృచ్ఛిక-యాక్సెస్ మెమరీగా పరిగణించింది.


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

FFS డిస్క్‌ను సిలిండర్ సమూహాలుగా పిలువబడే సమూహాలుగా విభజిస్తుంది.


The file system manages data structures to implement abstractions like files and directories.

ఫైల్ సిస్టమ్ ఫైల్స్ మరియు డైరెక్టరీల వంటి అబ్‌స్ట్రాక్షన్‌లను అమలు చేయడానికి డేటా నిర్మాణాలను నిర్వహిస్తుంది.


Power loss or system crashes can lead to inconsistent on-disk structures.

విద్యుత్ అంతరాయం లేదా సిస్టమ్ క్రాష్‌లు అస్థిరమైన ఆన్-డిస్క్ నిర్మాణాలకు దారి తీయవచ్చు.


The crash-consistency problem is a key challenge in file system design.

క్రాష్-స్థిరత్వం సమస్య ఫైల్ సిస్టమ్ రూపకల్పనలో ఒక ముఖ్యమైన సవాలు.


Fsck is a tool used to find and repair inconsistencies in file systems.

Fsck అనేది ఫైల్ సిస్టమ్‌లలోని అసమానతలను గుర్తించడానికి మరియు మరమ్మత్తు చేయడానికి ఉపయోగించే ఒక సాధనం.


Journaling adds overhead but allows for faster recovery from crashes.

జర్నలింగ్ ఓవర్‌హెడ్‌ను జోడిస్తుంది, కానీ క్రాష్‌ల నుండి వేగంగా కోలుకోవడానికి అనుమతిస్తుంది.


The inode stores metadata about a file, such as its size and permissions.

ఐనోడ్ ఫైల్ గురించి మెటాడేటాను నిల్వ చేస్తుంది, దాని పరిమాణం మరియు అనుమతులు వంటివి.


A data bitmap is used to track which data blocks are allocated.

డేటా బ్లాక్‌లు ఏవి కేటాయించబడ్డాయో ట్రాక్ చేయడానికి డేటా బిట్‌మ్యాప్ ఉపయోగించబడుతుంది.


When appending to a file, the inode, bitmap, and data block must be updated.

ఒక ఫైల్‌కు జోడించేటప్పుడు, ఐనోడ్, బిట్‌మ్యాప్ మరియు డేటా బ్లాక్‌ను అప్‌డేట్ చేయాలి.


Crash scenarios can lead to inconsistent file system states.

క్రాష్ దృశ్యాలు అస్థిరమైన ఫైల్ సిస్టమ్ స్థితికి దారి తీయవచ్చు.


Fsck operates in phases to check and repair the file system.

ఫైల్ సిస్టమ్‌ను తనిఖీ చేయడానికి మరియు మరమ్మత్తు చేయడానికి fsck దశల్లో పనిచేస్తుంది.


The superblock contains critical information about the file system.

సూపర్‌బ్లాక్ ఫైల్ సిస్టమ్ గురించి క్లిష్టమైన సమాచారాన్ని కలిగి ఉంది.


Fsck checks for free blocks and ensures the allocation bitmaps are correct.

Fsck ఉచిత బ్లాక్‌లను తనిఖీ చేస్తుంది మరియు కేటాయింపు బిట్‌మ్యాప్‌లు సరైనవని నిర్ధారిస్తుంది.


Inode state is checked for corruption and other problems.

అవినీతి మరియు ఇతర సమస్యల కోసం ఐనోడ్ స్థితిని తనిఖీ చేస్తారు.


Fsck verifies the link count of each allocated inode.

Fsck ప్రతి కేటాయించిన ఐనోడ్ యొక్క లింక్ కౌంట్‌ను ధృవీకరిస్తుంది.


Duplicate pointers and bad blocks are also checked by fsck.

fsck ద్వారా నకిలీ పాయింటర్‌లు మరియు చెడు బ్లాక్‌లను కూడా తనిఖీ చేస్తారు.


Directory checks ensure the integrity of directory contents.

డైరెక్టరీ తనిఖీలు డైరెక్టరీ విషయాల సమగ్రతను నిర్ధారిస్తాయి.


Fsck can be slow on very large disk volumes.

చాలా పెద్ద డిస్క్ వాల్యూమ్‌లలో fsck నెమ్మదిగా ఉండవచ్చు.


Journaling is an alternative approach to fsck for crash consistency.

క్రాష్ స్థిరత్వం కోసం fsckకి జర్నలింగ్ ఒక ప్రత్యామ్నాయ విధానం.


The goal is to move the file system from one consistent state to another atomically.

ఫైల్ సిస్టమ్‌ను ఒక స్థిరమైన స్థితి నుండి మరొకదానికి పరమాణు స్థాయిలో తరలించడం లక్ష్యం.


Modern file systems often use journaling to improve crash recovery.

ఆధునిక ఫైల్ సిస్టమ్‌లు తరచుగా క్రాష్ రికవరీని మెరుగుపరచడానికి జర్నలింగ్‌ను ఉపయోగిస్తాయి.


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.

డిస్క్‌ను అప్‌డేట్ చేసేటప్పుడు, ఉన్న నిర్మాణాలను తిరిగి వ్రాయడానికి ముందు, మొదట ఒక చిన్న నోట్ రాయండి.


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.

నోట్‌ను డిస్క్‌కు రాయడం ద్వారా, అప్‌డేట్ సమయంలో క్రాష్ జరిగితే మీరు హామీ ఇస్తున్నారు.


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.

ప్రసిద్ధ జర్నలింగ్ ఫైల్ సిస్టమ్ అయిన Linux ext3, ఫైల్ సిస్టమ్‌లోకి జర్నలింగ్‌ను ఎలా చేర్చుకుంటుందో ఇప్పుడు వివరిస్తాము.


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

కొత్త కీ నిర్మాణం జర్నల్, ఇది విభజనలో కొంత చిన్న స్థలాన్ని ఆక్రమిస్తుంది.


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.

వాటిని తుది డిస్క్ స్థానాలకు వ్రాయడానికి ముందు, మేము ఇప్పుడు వాటిని మొదట లాగ్‌కు వ్రాయబోతున్నాము.


You can see we have written five blocks here.

మేము ఇక్కడ ఐదు బ్లాక్‌లను వ్రాసినట్లు మీరు చూడవచ్చు.


During replay, the recovery process simply replays everything in the log.

పునరుద్ధరణ సమయంలో, రికవరీ ప్రక్రియ లాగ్ లోని ప్రతిదాన్ని తిరిగి ప్లే చేస్తుంది.


Clearly this is not a correct recovery action, and certainly it will be a surprise to the user when reading the file.

ఖచ్చితంగా ఇది సరైన రికవరీ చర్య కాదు, మరియు ఫైల్ చదివేటప్పుడు ఇది వినియోగదారునికి ఆశ్చర్యాన్ని కలిగిస్తుంది.


One could, for example, never reuse blocks until the delete of said blocks is checkpointed out of the journal.

ఉదాహరణకు, సదరు బ్లాక్‌లను తొలగించే వరకు బ్లాక్‌లను మళ్లీ ఉపయోగించకూడదు.


When replaying the journal, the system first scans for such revoke records.

జర్నల్‌ను తిరిగి ప్లే చేస్తున్నప్పుడు, సిస్టమ్ మొదట అలాంటి రద్దు రికార్డ్‌ల కోసం స్కాన్ చేస్తుంది.


In each table, time increases in the downward direction, and each row in the table shows the logical time that a write can be issued or might complete.

ప్రతి పట్టికలో, సమయం కింది దిశలో పెరుగుతుంది మరియు పట్టికలోని ప్రతి వరుస వ్రాతను జారీ చేయగల లేదా పూర్తి చేయగల తార్కిక సమయాన్ని చూపుతుంది.


The only guarantees about ordering that we have are those that must be enforced for protocol correctness.

ప్రోటోకాల్ యొక్క సరైన పనితీరు కోసం అమలు చేయవలసిన వాటి గురించి మాత్రమే మాకు హామీలు ఉన్నాయి.


We’ve thus far described two options in keeping file system metadata consistent.

ఫైల్ సిస్టమ్ మెటాడేటాను స్థిరంగా ఉంచడంలో మేము ఇప్పటివరకు రెండు ఎంపికలను వివరించాము.


Implementing Soft Updates can be a challenge, however.

అయితే, సాఫ్ట్ అప్‌డేట్‌లను అమలు చేయడం ఒక సవాలుగా ఉంటుంది.


This technique never overwrites files or directories in place.

ఈ పద్ధతి ఎప్పుడూ ఫైల్‌లను లేదా డైరెక్టరీలను స్థానంలో తిరిగి రాయదు.


After a number of updates are completed, COW file systems flip the root structure of the file system.

అనేక నవీకరణలు పూర్తయిన తర్వాత, COW ఫైల్ సిస్టమ్‌లు ఫైల్ సిస్టమ్ యొక్క రూట్ నిర్మాణాన్ని మారుస్తాయి.


We’ll be learning more about this technique when we discuss the log-structured file system (LFS) in a future chapter.

భవిష్యత్ అధ్యాయంలో లాగ్-నిర్మిత ఫైల్ సిస్టమ్ (LFS) గురించి చర్చించినప్పుడు మేము ఈ పద్ధతి గురించి మరింత తెలుసుకుంటాము.


In this technique, entitled backpointer-based consistency (or BBC), no ordering is enforced between writes.

ఈ పద్ధతిలో, బ్యాక్‌పాయింటర్-ఆధారిత స్థిరత్వం (లేదా BBC) అనే శీర్షికతో, వ్రాతల మధ్య ఎటువంటి క్రమం అమలు చేయబడదు.


When accessing a file, the file system can determine if the file is consistent by checking if the forward pointer points to a block that refers back to it.

ఒక ఫైల్‌ను యాక్సెస్ చేస్తున్నప్పుడు, ఫైల్ స్థిరంగా ఉందో లేదో తెలుసుకోవడానికి ఫార్వర్డ్ పాయింటర్ దానికి తిరిగి సూచించే బ్లాక్‌కు పాయింట్ చేస్తుందో లేదో తనిఖీ చేయవచ్చు.


For some workloads, these optimistic techniques can improve performance by an order of magnitude.

కొన్ని వర్క్‌లోడ్‌ల కోసం, ఈ ఆశావాద పద్ధతులు పనితీరును ఒక పరిమాణ క్రమంలో మెరుగుపరుస్తాయి.


We have introduced the problem of crash consistency, and discussed various approaches to attacking this problem.

క్రాష్ స్థిరత్వం సమస్యను మేము పరిచయం చేసాము మరియు ఈ సమస్యను పరిష్కరించడానికి వివిధ విధానాలను చర్చించాము.


Journaling reduces recovery time from O(size-of-the-disk-volume) to O(size-of-the-log), thus speeding recovery substantially after a crash and restart.

జర్నలింగ్ రికవరీ సమయాన్ని O(size-of-the-disk-volume) నుండి O(size-of-the-log)కి తగ్గిస్తుంది, తద్వారా క్రాష్ మరియు పునఃప్రారంభం తర్వాత రికవరీని గణనీయంగా వేగవంతం చేస్తుంది.


For this reason, many modern file systems use journaling.

ఈ కారణంగా, చాలా ఆధునిక ఫైల్ సిస్టమ్‌లు జర్నలింగ్‌ను ఉపయోగిస్తాయి.


We have also seen that journaling can come in many different forms.

జర్నలింగ్ అనేక విభిన్న రూపాల్లో వస్తుందని కూడా మేము చూశాము.


The motivation to do so was based on the following observations.

దీనికి ప్రేరణ క్రింది పరిశీలనలపై ఆధారపడి ఉంది.


As more data is cached, disk traffic would increasingly consist of writes, as reads would be serviced in the cache.

మరింత డేటాను కాష్ చేసినప్పుడు, డిస్క్ ట్రాఫిక్ ఎక్కువగా వ్రాతలతో కూడి ఉంటుంది, ఎందుకంటే రీడ్‌లు కాష్‌లో అందించబడతాయి.


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ని మొదట చదవడం ద్వారా ఐనోడ్ మ్యాప్ భాగాలను కనుగొనవచ్చు.


Thus, the overall structure of the on-disk layout contains a checkpoint region (which points to the latest pieces of the in- ode map); the inode map pieces each contain addresses of the inodes; the inodes point to files (and directories) just like typical UNIXfile systems.

అందువల్ల, ఆన్-డిస్క్ లేఅవుట్ యొక్క మొత్తం నిర్మాణం చెక్‌పాయింట్ ప్రాంతాన్ని కలిగి ఉంటుంది (ఇది ఐనోడ్ మ్యాప్ యొక్క తాజా భాగాలకు సూచిస్తుంది); ఐనోడ్ మ్యాప్ ముక్కలు ఒక్కొక్కటి ఐనోడ్‌ల చిరునామాలను కలిగి ఉంటాయి; సాధారణ UNIX ఫైల్ సిస్టమ్‌ల వలె ఐనోడ్‌లు ఫైల్‌లకు (మరియు డైరెక్టరీలకు) సూచిస్తాయి.


Here is an example of the checkpoint region (note it is all theway at the beginning of the disk, at address 0), and a single imap chunk, inode, and data block.

ఇక్కడ చెక్‌పాయింట్ ప్రాంతానికి ఒక ఉదాహరణ ఉంది (ఇది డిస్క్ ప్రారంభంలో, చిరునామా 0 వద్ద ఉంది) మరియు ఒకే imap ముక్క, ఐనోడ్ మరియు డేటా బ్లాక్.


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 readis 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 read a block from the file, at this point, LFS proceeds exactly as a typical UNIXfile system, by using direct pointers or indirect pointers or doubly-indirect pointers as need be.

ఈ సమయంలో ఫైల్ నుండి ఒక బ్లాక్‌ను చదవడానికి, LFS నేరుగా పాయింటర్‌లను లేదా పరోక్ష పాయింటర్‌లను లేదా అవసరమైన విధంగా డబ్లీ-పరోక్ష పాయింటర్‌లను ఉపయోగించడం ద్వారా సాధారణ UNIX ఫైల్ సిస్టమ్‌గా కొనసాగుతుంది.


In the common case, LFS should perform the same number of I/Os as a typical file system when reading a file from disk; the entire imap is cached and thus the extra work LFS does during a read is to look up the inode’s address in the imap.

సాధారణ సందర్భంలో, డిస్క్ నుండి ఫైల్‌ను చదివేటప్పుడు LFS సాధారణ ఫైల్ సిస్టమ్‌గా అదే సంఖ్యలో I/Oలను నిర్వహించాలి; మొత్తం imap కాష్ చేయబడుతుంది మరియు అందువల్ల LFS రీడ్ సమయంలో చేసే అదనపు పని imapలో ఐనోడ్ యొక్క చిరునామాను చూడటం.


Thus far, we’ve simplified our discussion a bit by only considering in- odes and data blocks.

ఇప్పటివరకు, మేము ఐనోడ్‌లు మరియు డేటా బ్లాక్‌లను మాత్రమే పరిగణించడం ద్వారా మా చర్చను కొంచెం సరళీకృతం చేసాము.


However, 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, creatinga filefooin a directory would lead to the following new structures on disk:

అందువల్ల, డైరెక్టరీలో filefooని సృష్టించడం వలన డిస్క్‌లో కింది కొత్త నిర్మాణాలు ఏర్పడతాయి:


There is one other serious problem in LFS that the inode map solves, known as therecursive update problem[Z+12].

ఐనోడ్ మ్యాప్ పరిష్కరించే LFSలో మరొక తీవ్రమైన సమస్య ఉంది, దీనిని పునరావృత అప్‌డేట్ సమస్య [Z+12] అని పిలుస్తారు.


The problem arises in any file system that never updates in place (such as LFS), but rather moves updates to new locations on the disk.

ఈ సమస్య ఎప్పుడూ స్థానంలో అప్‌డేట్‌లను చేయని ఏదైనా ఫైల్ సిస్టమ్‌లో (LFS వంటివి) తలెత్తుతుంది, కానీ అప్‌డేట్‌లను డిస్క్‌లోని కొత్త స్థానాలకు తరలిస్తుంది.


Specifically, whenever an inode is updated, its location on disk changes.

ప్రత్యేకంగా, ఐనోడ్ అప్‌డేట్ అయినప్పుడల్లా, డిస్క్‌లో దాని స్థానం మారుతుంది.


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

ఒక పనిచేస్తున్నట్లు కనిపించే డిస్క్‌ను యాక్సెస్ చేస్తున్నప్పుడు, అది లోపాన్ని తిరిగి ఇవ్వవచ్చు.


Both of these types of faults are somewhat rare.

ఈ లోపాలు రెండూ కొంతవరకు అరుదైనవి.


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

కనీసం ఒక LSE లేదా బ్లాక్ అవినీతిని ప్రదర్శించిన డ్రైవ్‌ల శాతం పట్టిక చూపుతుంది.


As you can see from the table, while 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 కలిగిన ఖరీదైన డ్రైవ్‌లు చౌకైన డ్రైవ్‌ల వలెనే అదనపు లోపాలను అభివృద్ధి చేసే అవకాశం ఉంది.


డిస్క్ పరిమాణంతో LSEలు పెరుగుతాయి.


LSEలు ఉన్న చాలా డిస్క్‌లలో 50 కంటే తక్కువ ఉంటాయి.


Disks with LSEs are more likely to develop additional LSEs.

LSEలు ఉన్న డిస్క్‌లు అదనపు LSEలను అభివృద్ధి చేసే అవకాశం ఉంది.


డిస్క్ స్కబ్బింగ్ ఉపయోగకరంగా ఉంటుంది.


Chance of corruption varies greatly across different drive models within the same drive class.

అవినీతికి సంబంధించిన అవకాశం ఒకే డ్రైవ్ తరగతిలోని వివిధ డ్రైవ్ మోడళ్లలో బాగా మారుతుంది.


To learn more about these failures, you should likely read the original papers.

ఈ వైఫల్యాల గురించి మరింత తెలుసుకోవడానికి, మీరు అసలు పత్రాలను చదవాలి.


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

మీరు నిజంగా నమ్మదగిన నిల్వ వ్యవస్థను నిర్మించాలనుకుంటే, మీరు LSEలు మరియు బ్లాక్ అవినీతి రెండింటినీ గుర్తించడానికి మరియు వాటి నుండి కోలుకోవడానికి యంత్రాంగాన్ని చేర్చాలి.


When a storage system tries to access a block, and the disk returns an error, the storage system should simply use whatever redundancy mechanism it has to return the correct data.

నిల్వ వ్యవస్థ ఒక బ్లాక్‌ను యాక్సెస్ చేయడానికి ప్రయత్నించినప్పుడు, మరియు డిస్క్ లోపాన్ని తిరిగి ఇచ్చినప్పుడు, నిల్వ వ్యవస్థ సరైన డేటాను తిరిగి ఇవ్వడానికి దాని వద్ద ఉన్న ఏదైనా రిడెండెన్సీ విధానాన్ని ఉపయోగించాలి.


In a mirrored RAID, for example, the system should access the alternate copy.

ఉదాహరణకు, మిర్రర్డ్ RAIDలో, సిస్టమ్ ప్రత్యామ్నాయ కాపీని యాక్సెస్ చేయాలి.


The growing prevalence of LSEs has influenced RAID designs over the years.

LSEల పెరుగుతున్న ప్రాబల్యం సంవత్సరాలుగా RAID డిజైన్‌లను ప్రభావితం చేసింది.


When an LSE is discovered during reconstruction, the extra parity helps to reconstruct the missing block.

పునర్నిర్మాణం సమయంలో LSE కనుగొనబడినప్పుడు, అదనపు సమానత్వం తప్పిపోయిన బ్లాక్‌ను పునర్నిర్మించడానికి సహాయపడుతుంది.


How can we prevent users from getting bad data when corruption arises?

అవినీతి ఏర్పడినప్పుడు చెడు డేటాను పొందకుండా వినియోగదారులను మనం ఎలా నిరోధించగలం?


The primary mechanism used by modern storage systems to preserve data integrity is called the checksum.

డేటా సమగ్రతను కాపాడటానికి ఆధునిక నిల్వ వ్యవస్థలు ఉపయోగించే ప్రాథమిక విధానాన్ని చెక్‌సమ్ అంటారు.


A checksum is simply the result of a function that takes a chunk of data as input and computes a function over said data, producing a small summary of the contents of the data.

చెక్‌సమ్ అనేది డేటా ముక్కను ఇన్‌పుట్‌గా తీసుకుని, ఆ డేటాపై ఒక ఫంక్షన్‌ను లెక్కిస్తుంది, ఇది డేటాలోని విషయాల యొక్క చిన్న సారాంశాన్ని ఉత్పత్తి చేస్తుంది.


There’s No Such Thing As A Free Lunch, or TNSTAAFL for short, is an old American idiom.

ఉచిత భోజనం అంటూ ఏమీ లేదు, లేదా క్లుప్తంగా TNSTAAFL, ఇది ఒక పాత అమెరికన్ పదబంధం.


It turns out that file systems can be quite complex.

ఫైల్ సిస్టమ్‌లు చాలా సంక్లిష్టంగా ఉంటాయని తేలింది.


The paper discusses how file systems handle failures.

ఫైల్ సిస్టమ్‌లు వైఫల్యాలను ఎలా నిర్వహిస్తాయో ఈ పేపర్ చర్చిస్తుంది.


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

మేము ఫైల్ సిస్టమ్‌లో అనేక లోపాలు మరియు డిజైన్ లోపాలను కనుగొన్నాము.


This research helped improve the robustness of file systems.

ఈ పరిశోధన ఫైల్ సిస్టమ్‌ల దృఢత్వాన్ని మెరుగుపరచడానికి సహాయపడింది.


The paper is about improving write performance in file systems.

ఈ పేపర్ ఫైల్ సిస్టమ్‌లలో రైట్ పనితీరును మెరుగుపరచడం గురించి.


This classic paper defines terms related to fault-tolerant services.

ఈ క్లాసిక్ పేపర్ లోపం-తట్టుకునే సేవల సంబంధిత పదాలను నిర్వచిస్తుంది.


Building fault-tolerant services is crucial for distributed systems.

పంపిణీ వ్యవస్థల కోసం లోపం-తట్టుకునే సేవలను నిర్మించడం చాలా ముఖ్యం.


Our work focuses on data protection in the page cache.

మా పని పేజీ కాష్‌లో డేటా రక్షణపై దృష్టి పెడుతుంది.


The student found file systems interesting but complicated.

విద్యార్థి ఫైల్ సిస్టమ్‌లను ఆసక్తికరంగా, కానీ సంక్లిష్టంగా కనుగొన్నాడు.


Managing data persistently is harder than managing data in memory.

డేటాను శాశ్వతంగా నిర్వహించడం మెమరీలో డేటాను నిర్వహించడం కంటే కష్టం.


Forever is a long time, especially for data in file systems.

శాశ్వతంగా ఉండటం చాలా కాలం, ముఖ్యంగా ఫైల్ సిస్టమ్‌లలోని డేటాకు.


Updating persistent storage devices is complicated due to crash considerations.

క్రాష్ పరిగణనల కారణంగా శాశ్వత నిల్వ పరికరాలను నవీకరించడం సంక్లిష్టంగా ఉంటుంది.


Disk scheduling and data protection techniques are cool topics.

డిస్క్ షెడ్యూలింగ్ మరియు డేటా రక్షణ పద్ధతులు మంచి అంశాలు.


Erasure codes can be mathematically challenging.

ఎరేజర్ కోడ్‌లు గణితపరంగా సవాలుగా ఉంటాయి.


Technology-aware systems like FFS and LFS are neat.

FFS మరియు LFS వంటి సాంకేతిక పరిజ్ఞానం కలిగిన వ్యవస్థలు చక్కగా ఉన్నాయి.


Flash Translation Layers use log-structuring internally.

ఫ్లాష్ ట్రాన్స్‌లేషన్ లేయర్‌లు అంతర్గతంగా లాగ్-నిర్మాణాన్ని ఉపయోగిస్తాయి.


Many of the ideas we have studied will continue to be useful.

మనం అధ్యయనం చేసిన అనేక ఆలోచనలు ఉపయోగకరంగా కొనసాగుతాయి.


Distributed systems have changed the world.

పంపిణీ వ్యవస్థలు ప్రపంచాన్ని మార్చాయి.


Building distributed systems is hard because things fail.

విషయాలు విఫలమవుతాయి కాబట్టి పంపిణీ వ్యవస్థలను నిర్మించడం కష్టం.


Modern web services are built from a large collection of machines.

ఆధునిక వెబ్ సేవలు పెద్ద సంఖ్యలో యంత్రాల నుండి నిర్మించబడ్డాయి.


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

క్లయింట్, క్లయింట్-సైడ్ ఫైల్ సిస్టమ్‌కు సిస్టమ్ కాల్‌లను జారీ చేస్తుంది.


The server stores the data on its disks, and clients request data through well-formed protocol messages.

సర్వర్ దాని డిస్క్‌లలో డేటాను నిల్వ చేస్తుంది మరియు క్లయింట్‌లు బాగా రూపొందించబడిన ప్రోటోకాల్ సందేశాల ద్వారా డేటాను అభ్యర్థిస్తారు.


In this case, parts of these data structures would suddenly become unavailable.

ఈ సందర్భంలో, ఈ డేటా నిర్మాణాలలో భాగాలు అకస్మాత్తుగా అందుబాటులో ఉండవు.


Dealing with failure when parts of your address space go missing is hard.

మీ చిరునామా స్థలం యొక్క భాగాలు తప్పిపోయినప్పుడు వైఫల్యంతో వ్యవహరించడం కష్టం.


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

తదుపరి పాయింటర్ పోయిన చిరునామా స్థలం యొక్క భాగానికి సూచించే లింక్ చేయబడిన జాబితాను ఊహించండి.


One usually assumes, when writing code, that access to memory is cheap.

కోడ్ రాసేటప్పుడు, మెమరీని యాక్సెస్ చేయడం చౌకగా ఉంటుందని సాధారణంగా భావిస్తారు.


In DSM systems, some accesses are inexpensive, but others cause page faults and expensive fetches from remote machines.

DSM సిస్టమ్‌లలో, కొన్ని యాక్సెస్‌లు చౌకగా ఉంటాయి, కానీ మరికొన్ని పేజీ లోపాలకు మరియు రిమోట్ మెషీన్‌ల నుండి ఖరీదైన ఫెచ్‌లకు కారణమవుతాయి.


Thus programmers of such DSM systems had to be very careful to organize computations such that almost no communication occurred at all, defeating much of the point of such an approach.

అందువల్ల, అలాంటి DSM సిస్టమ్‌ల ప్రోగ్రామర్‌లు దాదాపుగా ఎటువంటి కమ్యూనికేషన్ జరగకుండా గణనలను నిర్వహించడానికి చాలా జాగ్రత్తగా ఉండాలి, అలాంటి విధానం యొక్క చాలా పాయింట్‌ను ఓడిస్తారు.


Though much research was performed in this space, there was little practical impact.

ఈ స్థలంలో చాలా పరిశోధనలు చేసినప్పటికీ, ఆచరణాత్మక ప్రభావం చాలా తక్కువగా ఉంది.


Remote procedure call packages all have a simple goal: to make the process of executing code on a remote machine as simple and straightforward as calling a local function.

రిమోట్ విధాన కాల్ ప్యాకేజీలన్నీ ఒక సాధారణ లక్ష్యాన్ని కలిగి ఉన్నాయి: రిమోట్ మెషీన్‌లో కోడ్‌ను అమలు చేసే ప్రక్రియను స్థానిక ఫంక్షన్‌ను పిలిచినంత సరళంగా మరియు నేరుగా మార్చడం.


The server simply defines some routines that it wishes to export.

సర్వర్ ఎగుమతి చేయాలనుకుంటున్న కొన్ని రొటీన్‌లను నిర్వచిస్తుంది.


The stub generator’s job is simple: to remove some of the pain of packing function arguments and results into messages by automating it.

స్టబ్ జనరేటర్ పని సులభం: ఫంక్షన్ వాదనలు మరియు ఫలితాలను సందేశాలలో ప్యాక్ చేయడం ద్వారా దానిని ఆటోమేట్ చేయడం ద్వారా కొంత నొప్పిని తొలగించడం.


Numerous benefits arise: one avoids, by design, the simple mistakes that occur in writing such code by hand.

అనేక ప్రయోజనాలు ఉన్నాయి: ఒకరు, రూపకల్పన ద్వారా, అలాంటి కోడ్‌ను చేతితో వ్రాసేటప్పుడు సంభవించే సాధారణ తప్పులను నివారిస్తారు.


The input to such a compiler is simply the set of calls a server wishes to export to clients.

అటువంటి కంపైలర్‌కు ఇన్‌పుట్ అనేది సర్వర్ క్లయింట్‌లకు ఎగుమతి చేయాలనుకునే కాల్‌ల సమితి.


For the client, a client stub is generated, which contains each of the functions specified in the interface.

క్లయింట్ కోసం, క్లయింట్ స్టబ్ ఉత్పత్తి చేయబడుతుంది, ఇది ఇంటర్‌ఫేస్‌లో పేర్కొన్న ప్రతి ఫంక్షన్‌ను కలిగి ఉంటుంది.


సందేశ బఫర్‌ను సృష్టించండి.


Pack the needed information into the message buffer.

అవసరమైన సమాచారాన్ని సందేశ బఫర్‌లో ప్యాక్ చేయండి.


Send the message to the destination RPC server.

గమ్యస్థాన RPC సర్వర్‌కు సందేశాన్ని పంపండి.


ప్రత్యుత్తరం కోసం వేచి ఉండండి.


రిటర్న్ కోడ్ మరియు ఇతర వాదనలను అన్‌ప్యాక్ చేయండి.


The client application will want to call open(), read(), write(), close() and other standard API calls to access files and directories.

క్లయింట్ అప్లికేషన్ ఫైల్స్ మరియు డైరెక్టరీలను యాక్సెస్ చేయడానికి open(), read(), write(), close() మరియు ఇతర ప్రామాణిక API కాల్‌లను కోరుకుంటుంది.


Imagine the server crashes after the first read completes, but before the client has issued the second one.

మొదటి రీడ్ పూర్తయిన తర్వాత, కానీ క్లయింట్ రెండవదాన్ని జారీ చేయడానికి ముందు సర్వర్ క్రాష్ అయితే ఊహించండి.


In this example, the file descriptor is a piece of shared state between the client and the server.

ఈ ఉదాహరణలో, ఫైల్ డిస్క్రిప్టర్ అనేది క్లయింట్ మరియు సర్వర్ మధ్య భాగస్వామ్య స్థితి.


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 a particular operation is going to operate upon.

ఒక నిర్దిష్ట ఆపరేషన్ నిర్వహించబోయే ఫైల్ లేదా డైరెక్టరీని ప్రత్యేకంగా వివరించడానికి ఫైల్ హ్యాండిల్స్ ఉపయోగించబడతాయి.


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

వాల్యూమ్ ఐడెంటిఫైయర్ సర్వర్‌కు అభ్యర్థన ఏ ఫైల్ సిస్టమ్‌ను సూచిస్తుందో తెలియజేస్తుంది.


The inode number tells the server which file within that partition the request is accessing.

ఆ విభజనలోని ఏ ఫైల్‌ను అభ్యర్థన యాక్సెస్ చేస్తుందో ఐనోడ్ సంఖ్య సర్వర్‌కు తెలియజేస్తుంది.


Once a file handle is available, the client can issue READ and WRITE protocol messages on a file.

ఫైల్ హ్యాండిల్ అందుబాటులోకి వచ్చిన తర్వాత, క్లయింట్ ఫైల్‌లో READ మరియు WRITE ప్రోటోకాల్ సందేశాలను జారీ చేయవచ్చు.


The READ protocol message requires the protocol to pass along the file handle of the file along with the offset within the file and number of bytes to read.

READ ప్రోటోకాల్ సందేశానికి ఫైల్ హ్యాండిల్‌ను, ఫైల్‌లోని ఆఫ్‌సెట్‌తో పాటు చదవాల్సిన బైట్‌ల సంఖ్యను ప్రోటోకాల్ ద్వారా పంపాలి.


The client-side file system tracks open files, and generally translates application requests into the relevant set of protocol messages.

క్లయింట్-సైడ్ ఫైల్ సిస్టమ్ తెరిచిన ఫైల్‌లను ట్రాక్ చేస్తుంది మరియు సాధారణంగా అప్లికేషన్ అభ్యర్థనలను సంబంధిత ప్రోటోకాల్ సందేశాల సమితిగా అనువదిస్తుంది.


The server simply responds to each protocol message, each of which has all the information needed to complete request.

సర్వర్ ప్రతి ప్రోటోకాల్ సందేశానికి ప్రతిస్పందిస్తుంది, ప్రతి ఒక్కటి అభ్యర్థనను పూర్తి చేయడానికి అవసరమైన మొత్తం సమాచారాన్ని కలిగి ఉంటుంది.


When a client sends a message to the server, it sometimes does not receive a reply.

క్లయింట్ సర్వర్‌కు సందేశాన్ని పంపినప్పుడు, కొన్నిసార్లు అది ప్రత్యుత్తరం అందుకోదు.


In NFSv2, a client handles all of these failures in a single, uniform, and elegant way: it simply retries the request.

NFSv2లో, క్లయింట్ ఈ వైఫల్యాలన్నింటినీ ఒకే, ఏకరీతి మరియు సొగసైన మార్గంలో నిర్వహిస్తుంది: ఇది కేవలం అభ్యర్థనను మళ్లీ ప్రయత్నిస్తుంది.


An operation is called idempotent when the effect of performing the operation multiple times is equivalent to the effect of performing the operating a single time.

ఒక ఆపరేషన్‌ను అనేకసార్లు నిర్వహించడం యొక్క ప్రభావం ఒకేసారి ఆపరేషన్‌ను నిర్వహించడం యొక్క ప్రభావానికి సమానంగా ఉన్నప్పుడు ఆపరేషన్‌ను ఐడెంపోటెంట్ అంటారు.


LOOKUP and READ requests are trivially idempotent, as they only read information from the file server and do not update it.

LOOKUP మరియు READ అభ్యర్థనలు చాలా సులభంగా ఐడెంపోటెంట్, ఎందుకంటే అవి ఫైల్ సర్వర్ నుండి సమాచారాన్ని మాత్రమే చదువుతాయి మరియు దాన్ని అప్‌డేట్ చేయవు.


If a WRITE fails, the client can simply retry it.

ఒక WRITE విఫలమైతే, క్లయింట్ దాన్ని మళ్లీ ప్రయత్నించవచ్చు.


The NFS client-side file system caches file data (and metadata) that it has read from the server in client memory.

NFS క్లయింట్-సైడ్ ఫైల్ సిస్టమ్ సర్వర్ నుండి చదివిన ఫైల్ డేటాను (మరియు మెటాడేటాను) క్లయింట్ మెమరీలో కాష్ చేస్తుంది.


The cache consistency problem is best illustrated with two clients and a single server.

రెండు క్లయింట్లు మరియు ఒకే సర్వర్‌తో కాష్ స్థిరత్వం సమస్యను ఉత్తమంగా వివరించవచ్చు.


When opening a file, the client-side file system will issue a GETATTR request to the server to fetch the file’s attributes.

ఒక ఫైల్‌ను తెరిచినప్పుడు, ఫైల్ యొక్క లక్షణాలను పొందడానికి క్లయింట్-సైడ్ ఫైల్ సిస్టమ్ సర్వర్‌కు GETATTR అభ్యర్థనను జారీ చేస్తుంది.


The server checks if the cached file is valid.

సర్వర్ కాష్ చేయబడిన ఫైల్ చెల్లుబాటు అవుతుందో లేదో తనిఖీ చేస్తుంది.


If the file is valid, the client can use it.

ఫైల్ చెల్లుబాటు అయితే, క్లయింట్ దానిని ఉపయోగించవచ్చు.


Otherwise, 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.

సర్వర్ క్రాష్ అయిందని క్లయింట్‌లు తప్పనిసరిగా గుర్తించాలి.


They must treat all cache contents as suspect.

అన్ని కాష్ విషయాలను అనుమానాస్పదంగా పరిగణించాలి.


Reestablish 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 can check that the server is alive.

క్లయింట్‌లు సర్వర్ సజీవంగా ఉందో లేదో తనిఖీ చేయవచ్చు.


There is a cost to building a scalable caching model.

స్కేలబుల్ కాషింగ్ మోడల్‌ను నిర్మించడానికి కొంత ఖర్చు ఉంది.


With NFS, clients hardly noticed a server crash.

NFSతో, సర్వర్ క్రాష్‌ను క్లయింట్‌లు దాదాపుగా గుర్తించలేదు.


AFSv2 was measured and found to be 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.

డేటాను డిస్క్‌కు రాయడానికి ముందు సర్వర్ క్రాష్ అయింది.


NFS servers must commit each write to stable storage before informing the client of success.

క్లయింట్‌కు విజయాన్ని తెలియజేసే ముందు NFS సర్వర్లు ప్రతి వ్రాతను స్థిరమైన నిల్వకు కట్టుబడి ఉండాలి.


క్లయింట్‌కు దాని విజయం గురించి తెలియజేయబడింది.


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

క్లయింట్ ద్వారా జారీ చేయబడిన వ్రాతల క్రింది క్రమాన్ని ఊహించండి.


This requirement gives rise to in NFS server implementation is that write performance, without great care, can be the major performance bottleneck.

ఈ అవసరం NFS సర్వర్ అమలులో పెరుగుతుంది, వ్రాత పనితీరు, గొప్ప జాగ్రత్త లేకుండా, ప్రధాన పనితీరు అడ్డంకిగా ఉంటుంది.


The original NFS paper; though a bit of a challenging read, it is worthwhile to see the source of these wonderful ideas.

అసలు NFS పేపర్; కొంచెం సవాలుగా ఉన్నప్పటికీ, ఈ అద్భుతమైన ఆలోచనలకు మూలాన్ని చూడటం విలువైనది.


Kerberos is an early and hugely influential authentication service.

కెర్బెరోస్ ఒక ప్రారంభ మరియు అత్యంత ప్రభావవంతమైన ప్రమాణీకరణ సేవ.


We probably should write a book chapter about it sometime...

మేము బహుశా దాని గురించి ఎప్పుడైనా ఒక పుస్తక అధ్యాయాన్ని వ్రాయాలి...


The small modifications that underlie NFS version 3.

NFS వెర్షన్ 3కి సంబంధించిన చిన్న మార్పులు.


A great NFS reference; incredibly thorough and detailed per the protocol itself.

గొప్ప NFS సూచన; ప్రోటోకాల్ ప్రకారం చాలా పూర్తి మరియు వివరణాత్మకమైనది.


The dreaded specification; read it if you must, i.e., you are getting paid to read it.

భయంకరమైన స్పష్టీకరణ; మీరు తప్పనిసరిగా చదవండి, అంటే, మీరు దానిని చదవడానికి చెల్లించబడుతున్నారు.


The Andrew File System was introduced by researchers at Carnegie-Mellon University (CMU) in the 1980’s.

1980లలో కార్నెగీ-మెల్లన్ విశ్వవిద్యాలయం (CMU) పరిశోధకులు ఆండ్రూ ఫైల్ సిస్టమ్‌ను ప్రవేశపెట్టారు.


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

అత్యంత ముఖ్యమైనది ఏమిటంటే క్లయింట్‌లు మరియు సర్వర్‌ల మధ్య ప్రోటోకాల్ యొక్క రూపకల్పన.


In NFS, cache consistency is hard to describe because it depends directly on low-level implementation details.

NFSలో, కాష్ స్థిరత్వం వివరించడం కష్టం, ఎందుకంటే ఇది నేరుగా తక్కువ-స్థాయి అమలు వివరాలపై ఆధారపడి ఉంటుంది.


When the file is opened, a client will generally receive the latest consistent copy from the server.

ఫైల్ తెరిచినప్పుడు, క్లయింట్ సాధారణంగా సర్వర్ నుండి తాజా స్థిరమైన కాపీని అందుకుంటుంది.


మేము AFS యొక్క రెండు వెర్షన్లను చర్చిస్తాము.


When you open() a file, the entire file (if it exists) is fetched from the server and stored in a file on your local disk.

మీరు ఫైల్‌ను open() చేసినప్పుడు, మొత్తం ఫైల్ (అది ఉంటే) సర్వర్ నుండి తీసుకోబడుతుంది మరియు మీ స్థానిక డిస్క్‌లోని ఫైల్‌లో నిల్వ చేయబడుతుంది.


Subsequent read() and write() operations are redirected to the local file system where the file is stored.

తదుపరి read() మరియు write() కార్యకలాపాలు ఫైల్ నిల్వ చేయబడిన స్థానిక ఫైల్ సిస్టమ్‌కు మళ్లించబడతాయి.


మరింత వివరాల్లోకి వెళ్దాం.


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

అప్పుడు క్లయింట్-సైడ్ కోడ్ ఫైల్‌ను క్లయింట్ యొక్క స్థానిక డిస్క్‌లో కాష్ చేస్తుంది.


Time sharing is a fundamental concept in operating systems.

ఆపరేటింగ్ సిస్టమ్స్‌లో టైమ్ షేరింగ్ ఒక ప్రాథమిక భావన.


The operating system manages virtual memory.

ఆపరేటింగ్ సిస్టమ్ వర్చువల్ మెమరీని నిర్వహిస్తుంది.


Virtualization is a key feature of modern computing.

వర్చువలైజేషన్ ఆధునిక కంప్యూటింగ్‌లో ఒక ముఖ్యమైన లక్షణం.


Threads allow for concurrent execution within a process.

ఒక ప్రక్రియలో ఏకకాలంలో అమలు చేయడానికి థ్రెడ్‌లు అనుమతిస్తాయి.


The TLB (Translation Lookaside Buffer) speeds up address translation.

TLB (ట్రాన్స్‌లేషన్ లుక్‌అసైడ్ బఫర్) చిరునామా అనువాదాన్ని వేగవంతం చేస్తుంది.


How to efficiently virtualize the CPU with control?

నియంత్రణతో CPUని సమర్థవంతంగా ఎలా వర్చువలైజ్ చేయాలి?


సమయం-స్థలం యొక్క ట్రేడ్-ఆఫ్‌లను అర్థం చేసుకోండి.


The principle of isolation is important.

అలౌకిక సూత్రం ముఖ్యం.


ఒక పరిస్థితి కోసం ఎలా వేచి ఉండాలి?


సమయ భాగస్వామ్యం (మరియు స్థల భాగస్వామ్యం) ఉపయోగించండి.


సమయం ముగింపు విలువను సెట్ చేసేటప్పుడు జాగ్రత్త వహించండి.


లాక్‌ను ఎలా నిర్మించాలి?


The system crashed due to a software bug.

సాఫ్ట్‌వేర్ లోపం కారణంగా సిస్టమ్ క్రాష్ అయింది.


The file system is responsible for data storage.

డేటా నిల్వకు ఫైల్ సిస్టమ్ బాధ్యత వహిస్తుంది.


The RAID consistent-update problem is complex.

RAID స్థిరమైన-నవీకరణ సమస్య సంక్లిష్టమైనది.


సాధారణ ఏకకాల లోపాలను ఎలా నిర్వహించాలి?


The importance of workload is often underestimated.

వర్క్‌లోడ్ యొక్క ప్రాముఖ్యతను తరచుగా తక్కువ అంచనా వేస్తారు.


ఎక్స్‌టెంట్-ఆధారిత విధానాలను పరిగణించండి.


How to make all writes sequential writes?

అన్ని రచనలను సీక్వెన్షియల్ రచనలుగా ఎలా మార్చాలి?


అనుమానం వచ్చినప్పుడు, ప్రయత్నించండి.