Sunday, February 19, 2012

Как работи хард диска

Хард диска е устройство  за четене, запис и съхранение на данни. Хард диска представлява метална кутия, направена от алуминиеви сплави, за да няма магнитни свойства. Вътре в тази кутия има един мощен електромотор, екраниран разбира се, който задвижва шпиндел на който има закачени един или няколко алуминиеви диска, покрити с магнитно покритие, наречени плочи. Шпиндела и втулките които държат отделните плочи на определено разстояние една от друга също са от алуминиеви сплави. Това масово ползване на алуминиеви сплави се прави за да може частите да нямат магнитни свойства. Всъщност всички части вътре в диска са от алуминиеви сплави или ако се наложително да са от желязо и/ или стомана или има магнити те са в собствени “клетки” в кутията на диска заобиколени от алуминиевата сплав. Всичко това се прави с единствената цел, да се изолират външни и вътрешни магнитни полета, и да се избегне интерференция с частите вътре в диска която би причинила  грешки при запис, четене или дори загуби на данни.
При запис и четене, механично рамо за което е закачена четящата/ пишещата глава придвижва главата по радиуса на плочите, без да се допират до плочите. При високите обороти с които се въртят плочите, вече масовите дискове са на 7200 оборота а бързите на по 10 000 SATA или SATA 2 дори най-лекото докосване ще нанесе сериозни щети на магнитното покритие и ще повреди главите. Главите се поддържат във въздуха, от въздушен поток който се завихря от плочите, докато се въртят. Когато изключите компютъра, диска първо сам прибира главата си в безопасната зона и тогава спира да върти плочите – това се нарича паркиране на главата. При пускане диска първо завърта плочите, и тогава извежда главите от позиция от безопасната зона до пътека 0 където е записан Master boot record, таблицата на дяловете на диска (partition table), файловата таблица за всеки дял.
Основните таблици под ДОС и Windows са:
File Allocation Table 16 Bit  16 битова файлова таблица, за ДОС, уин 3.Х и уин 95
File Allocation Table 32 Bit  32 битова файлова таблица, за уин 98/98SE/Me/win 2000/win xp/win 2003
MFT Master File table това е файловата таблица на NTFS дял. За Win NT 3.5/4.0/2000/xp/2003
В тези таблици се съдържа информация за файла:
Размер на файла
Тип на файла
Физически на кои сектори се намират парчетата от файла
В коя директория/ поддиректория се намира файла
Атрибути на файла – дали е скрит, системен, или само за четене
В случая на NTFS и MFT се съдържа копие на ACL – Access Control List където се определя кой потребител какви права за достъп има до файла.
Съвременните хард дискове IDE или EIDE което значи Integrated Drive Electronics или Enhanced Integrated Drive Electronics идват с електроника – с контролер закачен направо на диска. Всички дискове с обем ДО 512 мб са IDE хард дискове, Всички дискове с обем ПОВЕЧЕ от 512 мегабайта са EIDE така че независимо дали ползва UATA 33/66/100/133 интерфейс – parallel ATA или SATA/SATA2 Serial ATA/Serial ATA2 интерфейс или SCSI вариантите като интерфейс за пренос на данни, тези хард дискове са все EIDE защото имат техен собствен контролер монтиран от външната страна на алуминиевата кутия.

Запис и съхранение на данни
Когато си купувате нов диск, той идва форматиран на ниско ниво от производителя. Тоест с вече обособени пътеки и сектори.

Сектора е най-малката организационна единица за съхранение на данни, с която хард диска работи, сектора има обем от 512 байта – половин килобайт. За да се постигне баланс между скорост и разхищение на излишно място, секторите се групират в клъстери. Клъстерите са най-малката логическа единица с която ОС работи. Клъстерите биват заети (allocated) ако в тях има записан файл или парче от файл, и то може да се достъпи и ползва от потребителя и системата, или не може да бъде достъпен, заради повреден запис във файловата таблица или липсваща такава, но там има файл или парче от файла което е било достъпно за системата и потребителя преди появата на грешката, или празни (Unallocated) ако в тях няма нищо записано, или от тях току що е изтрит файла. По-голям клъстер, значи повече сектори, по-висока скорост, и по-голяма загуба на място и обратно, по-малки клъстери значи по-малко сектори в клъстер, по-малко разхищение на място и по-ниска скорост. Оптималната настройка е 4кб клъстери (8 сектора). Ако запишете много малък файл, той заема цял клъстер на хард диска, и следващият файл ще бъде записан в друг клъстер, дори ако първия файл не е запълнил клъстера. От там идва и неизбежното разхищение на място. Колко място ще бъде загубено зависи от големината на файла, колко килобайта от клъстера остават незаписани ако файла се събира в един клъстер, или ако файла се събира в няколко клъстера, колко килобайта остават неизползвани в последния клъстер. Ако има 2 или повече файла в един клъстер, се счита за логическа грешка преплетени файлове. Ако записвате много голям файл, той ще се запише в толкова клъстери, колкото са необходими, за да може обема на всички клъстери да е равен или по-голям от файла. Възможно е при голям файл последният клъстер да се запълни частично. На практика нещата не са толкова прости. Реално при ежедневната работа, когато се създават множество временни файлове, други програми създават и трият временни файлове, вие записвате файлове, независимо дали е програма или игра. При запис, хард диска, търси първите свободни клъстери и записва там, ако те не са достатъчни, като ги запълни търси следващата най-близка група клъстери, и продължава записа, и така докато целия файл бъде записан. Това е причината файловете да се записват на парчета из диска, а не в поредни клъстери. Това се нарича фрагментиране. Това забавя работата на хард диска, защото диска трябва да търси отделните парчета, да ги чете едно по едно, а това изисква време да се направи. тук дефрагменитрането е нож с 2 остриета. От една страна подрежда файловете да са в поредни клъстери, което намалява времето на търсене и улеснява потенциално възстановяване, от друга страна можа да попречи на възстановяване на предишни изтрити файлове, файловете ще бъдат изцяло подредени и записвани в поредни клъстери, ако е необходимо свободни ще се записват, заети ще се изпразват когато парчета се преместят, това презаписва клъстерите, които може да съдържат вече изтрит файл, правейки го невъзстановим за софтуерно възстановяване. След като файл или парче от файла бъде записано някъде, информацията за файла или парчето бива записана във файлова таблица, така операционната система и хард диска винаги знаят къде е файла или парчето то файла. Фрагментирането на файла може да е пречка, за възстановяващите програми, защото методите за възстановяване на данни работят най-добре на подредени дискове, и изпитват много сериозни затруднения и забавяне когато файловете са фрагментирани. Понякога, може да се възстанови файл който съдържа парчета от няколко фрагментирани файла, защото по някаква причина възстановяващата програма не е открила информацията за тези парчета към кои файлове принадлежат. Това е често явление при RAW Reading Recovery когато се търсят директно парчета на сляпо, без да се използва информацията от файловата таблица. В такива случаи се прибягва ако файловата таблица е силно повредена или изтрита, пример: форматиран диск, неуспешно конвертиране или преоразмеряване на дяловете, вируси, червеи, троянски коне... при преоразмеряване на дяла, се променя и дължината на файловата таблица, ако дяла се уголемява, и файловата таблица се разширява, за да опише новите сектори и клъстери, и при намаляването на обема на дяла, намалява броят сектори и клъстери и съответно от файловата таблица, се премахват записите за тези сектори и клъстери които вече не са част от този дял. 
 
какво става когато искате да отворите един файл?
Когато отваряте файл, хард диска първо проверява във файловата таблица, къде се намира първото парче от файла, Като го прочете, се обръща за справка във файловата таблица, къде е следващото парче, и така докато прочете целият файл.  когато файла е фрагментиран, диска губи време и празни обороти, докато главата се намести над следващата пътека, където трябва да изчака сектора да мине под  нея за да прочете съдържанието. това чакане и губене на време, е причината днес да има дефрагментиращи програми, те подреждат частите от файла в съседни клъстери, така че времето за достъп да се намали, като се елиминират излишните разходки на главата из плочите. до тук добре. имаме ефект, но като цяло ефекта е по-малък от очакваният. Защо? За разберем отговора трябва да се намесим по-дълбоко в работата на хард диска. Да видим какво става под капака. първите дискове, бяха сравнително бавни, защото всичките клъстери бяха съседни.

ставаше следната ситуация, главата прочиташе данните в клъстер 1 и ги пращана контролера, докато контролера се убеди че данните са прочетени коректно, да подаде на главата информацията че следващото парче е в клъстер 2 и докато главата стигне до пътечката, тя вече е изпуснал клъстер 2 и трябва да чака цял оборот за да може клъстер 2 да мине под главата и да прочете данните. За да се елиминира този недостатък, производителите на хард дискове решиха да направят прекомпенсация, като разместят местата на клъстерите, така че да не се губи време.  

При тази подредба, прекомпенсация 1:3 (това е примерна прекомпенсация за илюстрация в статията), всеки следващ клъстер е на 3 клъстера разстояние от предният така контролера може да се увери че всички е прочетено правилно, да подаде на главата команда да прочете клъстер 2 и главата да отиде на нужното място. Тъй като клъстер 1 и клъстер 2 са на по-голямо разстояние една от друга контролера като завърши работата си и главата като отиде на място, ще хване точно клъстер 2 и ще го прочете, без да го изпуска и без да чака цял нов оборот. Това ускорява значително работата на диска. Намалява се изчакването и се намалява времето за достъп до следващият клъстер. Производителите на Хард дискове бързо усвоиха тази схема на форматиране прекомпенсирани клъстери но непрекомпансирани пътеки. Оказва се че това има ефект само ако всичките части на файла са на една и съща пътека. 

Не след дълго се оказа че замисъла е добър, но самата подредба не е удачна. Къде е недостатъка?  Ами ако главата трябва да прочете парче на друга пътека? Прекомпенсацията по клъстери няма да помогне. Във времето в което контролера ще е завършил работата си и главата ще е готова за четене клъстер 2 на съседната пътека ще е на място, но докато главата се придвижи до пътеката, клъстера ще е преминал и главата отново трябва да чака да се завърти цял оборот, за да прочете новия клъстер. Това доведе до втора прекомпенсация но този път на пътеките. 

На пръв поглед изглежда каша, но реално погледнато не е каша. Тази подредба показва че и секторите и пътеките са прекомпенсирани. Пътеките са прекомпенсирани с фактор: 1:3 една спрямо друга, което ще рече че: клъстер 1 на втората пътека е 3 клъстера напред спрямо клъстер 1 на първа пътека, клъстер 1 на трета пътека е 3 клъстера напред спрямо клъстер 1 на втора пътека пътека 2, и 6 клъстера напред спрямо клъстер 1 на първа пътека. Така ако главата е прочела клъстер 1 от едната пътека, и трябва да отиде да прочете клъстер 2 в съседната пътека, то хард диска има времето да го направи, без да изпуска клъстера, защото клъстера е изместен с още 3 позиции напред заради прекомпенсацията на пътеките. Така се получава че при перкомпенсацията на пътеките и клъстерите едновременно, хард диска, има време да провери дали е прочетено правилно, да вземе информацията от файловата таблица за местоположението, на втората част от файла, да и да премести главата на новата пътека. Така когато главата е вече преместена на новата пътека, въпросният клъстер е на място, и се прочита веднага без да се губи време в чакане на цял оборот, защото главата и клъстера се срещат, а не се разминават и хард диска не е принуден да чака цял оборот. Получава се че клъстер 2 на втора пътека е 6 позиции напред пред клъстер 1 на първа пътека, и е необходимо повече време да се превъртят повече позиции, точно колкото му трябва на контролера да провери прочетеното, да вземе информацията за следващото парче, и главата да стигне до нужната позиция на съседната пътека за да прочете клъстера.

Какво става когато изтрием един файл?
Когато натиснете клавиша дел, файла не се изтрива, файла се премества, от папката в която е бил в служебната папка recycle bin. В тази папка файла се съхранява докато не бъде възстановен или окончателно изтрит. Това е предпазна мярка, ако изтриете файл по погрешка или ако промените мнението си и поискате да го възстановите. Самото изтриване на файла става когато изпразните кошчето или кажете на уиндоус да го изтрие директно с клавишната комбинация shift+del. Когато файл се изтрие и премести, срещу името му в неговия запис за директорията в която е бил се слага специален символ, който маркира файла като изтрит. Така ОС заблуждава програмите и себе си че файла го няма, и че тези клъстери са свободни. Когато кошчето се изпразни същото става и с файловете там. Ако изтриете файл през recycle bin оставяте 2 следи по които файла да бъде открит. Едната в папката на recycle bin втората в оригиналната папка където е бил. Когато файла се премести от една папка в друга, или в recycle bin остава следата в оригиналната папка. Когато файл се извади от recycle.bin файла оставя следа в recycle bin и се записва на ново място, оставяйки и следата където е бил преди да се изтрие, или се записва на същото място е бил преди да се изтрие. Ако се запише на същото място където е бил, тогава остава следа само в Recycle.bin. Кое от двете ще стане, зависи от това дали мястото където е бил файла е презаписано на някаква причина (фрагментиране, дефрагментиране, запис на нов файл...) или същото място е свободно. Ако мястото е частично презаписано, то файла изваден от кошчето, ще се запише на 2 и повече места, като се фрагментира. Ако цялото място е свободно, файла ще отиде на същото място където е бил. Ако цялото място е заето, файла ще се презапише на нови клъстери и ако новото място може събере файла, то файла ще се запише без да се фрагментира, а ако новото място не може да събера файла, тогава файла ще се фрагментира и ще се запише на 2 или повече парчета.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.