Начална » как да » Ще напишете ли подобрение на производителността, ако преформатираният твърд диск беше изпълнен с нули?

    Ще напишете ли подобрение на производителността, ако преформатираният твърд диск беше изпълнен с нули?

    Ако смятате да преформатирате твърд диск, има ли нещо, което би „подобрило“ изпълнението на записа след това или е нещо, за което дори не трябва да се тревожите? Днешната публикация за въпроси и отговори SuperUser има отговори на любопитни въпроси на читателя.

    Днешната сесия за въпроси и отговори идва при нас с любезното съдействие на SuperUser - подразделение на Stack Exchange, групирано от общността уеб сайтове за въпроси и отговори.

    Снимката е предоставена от Крис Банистър (Flickr).

    Въпроса

    Четецът на SuperUser Brettetete иска да знае дали запълването на твърд диск с нули ще подобри производителността на запис:

    Имам 2TB твърд диск, който е 99% пълен. Изтрих дяловете с Fdisk и го форматирали като ext4. Доколкото знам, действителните данни, които са били на твърдия диск, все още съществуват, но таблицата за дяловете е преназначена.

    Въпросът ми е: дали ще подобри производителността на запис за по-нататъшни писмени действия, ако твърдият диск е чист? С „чист“ искам да кажа, да запълниш хард диска с нули? Нещо като:

    • dd, ако = / dev / zero от = / dev / sdx bs = 1 count = 4503599627370496

    Ще запълни хард диска с нули, за да подобри производителността на запис?

    Отговорът

    Авторът на SuperUser Майкъл Кьорлинг има отговор за нас:

    Не, това няма да подобри работата. Твърдите дискове не работят така.

    Първо, когато пишете дадени данни на ротационен диск, той се трансформира в магнитни домейни, които в действителност могат да изглеждат много различни от модела на битовете, който пишете. Това се прави отчасти, защото е много по-лесно да се поддържа синхронизация, когато образецът, прочетен от блюдото, има известна променливост. Например дългият низ от „нула“ или „един“ стойности би затруднил синхронизирането. Чели ли сте 26,393 бита или 26,394 бита? Как разпознавате границата между битовете?

    Техники за това се развиват с течение на времето. Например, вижте Модифицирана честотна модулация, MMFM, запис на групов код и по-общата технология на кодиране с ограничена дължина.

    Второ, когато записвате нови данни в сектор, магнитните домейни на съответните части на блюдото просто се настройват на желаната стойност. Това се прави независимо от това, което предишният магнитен домейн „е бил“ на това конкретно физическо място. Платото вече се върти под главата за писане; първо четене на текущата стойност, след което записва новата стойност, ако и само ако е различна. Това би накарало всеки запис да изисква две обороти (или допълнителна глава за всяко блюдо), което води до забавяне на писането, за да се удвои или значително да се увеличи сложността на задвижването, от своя страна увеличаване на разходите.

    Тъй като ограничаващият фактор при последователното I / O производителност на твърдия диск е колко бързо всеки бит преминава под главата за четене / запис, това дори не би предоставило никаква полза за потребителя. Като изключение, ограничаващият фактор при произволно I / O изпълнение е колко бързо главата за четене / запис може да бъде позиционирана в желания цилиндър и след това желаният сектор пристига под главата. Основната причина, поради която SSD-тата могат да бъдат толкова бързи при случайни I / O работни натоварвания, е, че те напълно елиминират и двата фактора.

    Както беше посочено от JakeGould, една от причините, поради които бихте искали да презапишете устройството с някакъв фиксиран модел (като всички нули), би било да се гарантира, че няма остатъци от предварително съхранени данни, които могат да бъдат възстановени умишлено или случайно. Но това няма да окаже никакво влияние върху работата на твърдия диск напред, поради посочените по-горе причини.


    Имате ли какво да добавите към обяснението? Звучи в коментарите. Искате ли да прочетете повече отговори от други технологични потребители на Stack Exchange? Вижте пълната тема за дискусия тук.