Чи поліпшить це швидкість запису, щоб заповнити переформатований диск нулями?


14

У мене накопичувач на 2 ТБ, який був заповнений> 99%. Я видалив розділи з fidskі відформатував їх mkfs.ext4.

Наскільки я знаю, фактичні дані, які були на диску, все ще існують. Таблиця розділів все ж була переназначена.

Питання полягає в тому, чи поліпшить це ефективність запису для подальших дій запису, якщо диск буде очищено ? З очищеним я маю на увазі заповнення диска нулями?

Щось на зразок

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496

8
Немає переваги перед початком нуля, оскільки це перезапише все, що там для початку.
Моаб

7
Якби це був SSD, відповідь буде "пекло ні", оскільки mkfs.ext4 фактично використовує TRIM для відкидання всього вмісту розділу, тому вручну, записуючи нулі поверх цього, це трохи знизить продуктивність.
користувач1686

2
@grawity Мені було цікаво, чи є SSD, який автоматично перетворює записи всіх нулів на TRIM.
kasperd

@kasperd: добре запитання!
liori

Ще одне можливе подальше запитання: якщо згаданий диск був VM, встановлений на SAN, який робив відображення диска низького рівня, чи могло б це допомогти (у тому випадку, якщо дані, які були видалені на рівні VM, якщо система не використовує API, відомий для VM , він побачить для SAN, що всі ці видалені блоки повинні триматися навколо, тоді як встановлення їх на всі нулі закінчиться купою дублюваних блоків, що все вказувало на нульову річ)
Foon

Відповіді:


36

Ні, це не покращило б продуктивність.

TL; DR: обертові магнітні накопичувачі жорсткого диска не працюють так.

По-перше, коли ви записуєте будь-які задані дані на обертовий накопичувач магнітних накопичувачів, ці дані перетворюються на магнітні домени, які насправді можуть виглядати дуже різними від бітового шаблону, який ви пишете. Це робиться частково тому , що набагато легше підтримувати синхронізацію , коли шаблон лічений з тарілочки має певну кількість мінливості, і, наприклад , довгий рядок «нуль» або «один» значення буде зробити дуже важко підтримувати синхронізацію . (Ви читали 26 393 біт або 26 394 біт? Як розпізнати межу між бітами?) Методи здійснення цього перетворення між комп'ютерними бітами даних і фрагментами, що зберігаються, розвивалися з часом; наприклад, шукайте модифіковану модуляцію частоти , MMFM,Запис групового коду та більш загальна технологія обмеженої довжини кодувань .

Сам процес запису, такі як HAMR , PMR , дранка і так далі orthgonal до цього в тому , що вони описують механіку того , як магнітні домени зберігаються на фізичних носіях.

По-друге, коли ви записуєте нові дані в сектор, магнітні домени відповідних ділянок блюдо просто встановлюються на потрібне значення. Це робиться незалежно від того, який попередній магнітний домен був у цьому конкретному фізичному місці. Блюдо вже крутиться під головою для запису; спершу зчитування поточного значення, потім записування нового значення, якщо і лише якщо воно інше, спричинить, що для кожного запису потрібно два оберти (або додаткова головка для кожної тарілки), внаслідок чого затримка запису збільшується вдвічі або значно збільшує складність накопичувача, у свою чергу збільшує вартість. Оскільки обмежуючим фактором у послідовній продуктивності вводу / виводу жорсткого диска є те, як швидко кожен біт проходить під головою для читання / запису, це навіть не принесе користі користувачеві. (Убік, обмежуючим фактором у випадкових роботах вводу / виводу є те, наскільки швидко головка читання / запису може бути розміщена в потрібному циліндрі, а потім бажаний сектор потрапляє під головку. Основна причина, по якій SSD можуть бути настільки швидкими у випадкових навантаженнях вводу / виводу, полягає в тому, що вони повністю усувають обидва ці фактори.)

Як відзначили JakeGould , одна з причин , чому ви можете перезаписати диск з деяким фіксованим малюнком (наприклад, все нулями) буде гарантувати , що ніяких залишки раніше збережені дані не можуть бути відновлені , або навмисно або випадково. Але це не матиме ніякого впливу на продуктивність диска вперед з причин, зазначених вище. Ще одна причина, про яку можна було б сказати, що «покращує продуктивність», як вказував Ліорі , - це допомогти стисненню невикористаних частин збережених образів дисків, але навіть це не покращує продуктивність використовуваної системи.


3
Ще одна причина нулювання розділів / накопичувачів полягає в тому, якщо ви плануєте взяти неперероблений дамп розділів / дисків (наприклад, як резервне копіювання, створення зображення ОС для декількох машин, як техніка міграції системи тощо). Нулі добре стискаються, що може відрізнятися від попереднього вмісту, який зберігався на диску.
liori

@liori Добре, але це не є загальним сценарієм для кінцевих користувачів, і це далеко не те, що описує ОП.
CVn

Отже оптичні диски або не обертаються, або є магнітними?
Макс Рід

4

Ви говорите так:

Питання полягає в тому, чи поліпшить це ефективність запису для подальших дій запису, якщо диск буде очищено? З очищеним я маю на увазі заповнення диска нулями?

100% ніп. Запис нулів на диск не покращує продуктивність. Ви зробите це лише для знищення даних. Знаючи це, ви говорите це:

Наскільки я знаю, фактичні дані, які були на диску, все ще існують.

Технічно так ... Дані, які раніше існували на диску, все ще існують на диску на якомусь фундаментальному рівні. Однак це не існує у формі, до якої легко отримати доступ чи відновити, але це може викликати занепокоєння, якщо ви по-справжньому переживаєте, що дані ставлять під загрозу той, хто готовий докласти зусиль для відновлення тих фрагментів даних, які залишаються.

Тож якщо безпека та конфіденційність викликають занепокоєння, то, можливо, ви захочете записати нулі на накопичувач, щоб переконатися, що весь вільний простір справді витерто Але безпека та конфіденційність - це абсолютна єдина причина, коли ви коли-небудь знищуватимете вільний простір нулями, оскільки щось подібне ніколи не покращує продуктивність.


Чи запуск інструменту типу recoverне вважається "простим"? Виявилося б багато-багато файлів на повному диску, який щойно був mkfs.
варення

0

Мої два центові подарунки від усіх вас - це мій власний досвід, ТАК це допомагає, але обережно.

У мене було багато SSD, і на основі власних тестів я рекомендую повністю заповнити нулі перед перезаписом основної таблиці та замість видалення розділів відтворити головну таблицю.

Пізніше я поясню, чому, але кроки будуть ˋddˋ, щоб заповнити весь SSD, використовувати bs = 1M, набагато швидше, ніж bs = 1, і забути параметр count, щоб зробити його до кінця (це дасть помилку не більше місця, коли доходити до кінця, що прописано, тому не хвилюйтеся побачити таку помилку, вона повинна бути показана); після повного заповнення використовуйте gparted або все, що ви хочете написати головну таблицю (MBR / GPT / тощо) за потребою, це "обріже" весь диск, а потім створить розділи з потрібним форматом тощо.

Навіщо заповнювати це нулями? Короткий відгук полягає в тому, що мій досвід, коли я заповнюю його нулями на деяких SSD-дисках, там, де виправлення 2-24 нечитабельних блоків, більше немає блоків, які неможливо здійснити.

Тепер перше, що я роблю, коли отримую новий SSD, перед його використанням - це заповнити його нулями, щоб переконатися, що я більше не зазнаю загальних випадкових помилок нечитабельних блоків 1KiB.

Мій досвід: Використовуючи програмне забезпечення для читання / тестування всього SSD (це говорить вам, скільки часу займає читання кожного "сектора"), я отримував багато пар "512байтових секторів" (1KiB блоки), які є недосяжними, і їх положення змінюється випадковим чином, кількість відмов коливається від 2 до 24 тощо; після повного заповнення нулів і відтворення основної таблиці (що скасовує обрізку) більше не читаються секторів.

Мій тест на краш: Якщо я заповнив нулі, щоб відновитись після таких помилок, я дозволив використовувати один SSD через декілька годин і лише один терабайт, записаний на ньому (120GiB SSD), він загинув помилково, він не дозволяє доступ до нього більше, біоси материнської плати не бачать його, USB-корпуси забувають при доступі до нього, тому ні Windows не бачить, ні Linix fdisk не бачать.

Це був тест 'die' з декількома SSD, які я купував одночасно, однакові ... всі, які я не занулював, загинули, у решти багато блоків перерозподілено, але без жодних нечитаних помилок.

Звичайно, мій висновок полягає в тому, що всі SSD не надійні, незалежно від марки та потужності.

Тож перше, що з ними, на мій досвід, - змусити їх хоча б один раз повністю заповнити, краще з нулями, ніж зі випадковими (це швидше).

Більше того, більшість SSD роблять внутрішні обрізки, коли вони записуються нулями (алгоритми спогаду гарбе, тощо)

Крім того, якщо ви вперше заповнюєте їх один раз, перерозподіляється будь-який блок, який дає помилку запису. Набагато краще, що таке трапляється без життєвих даних, коли записані нулі, якщо дані втрачаються (усі були нулями), це не має значення, але якщо дані є "життєво важливими" для операційної системи, це дуже погано.

Більшість SSD перерозподіляють це, але втрачаючи дані на блоці, який призвів до помилки запису, лише «підприємство» (вони коштують> 10 € за ГіБ) повторно спробує записати після перерозподілу правильно. Деякі SSD також втратять усі інші "сектори" на такому невдалому блоці (як, наприклад, "скасування").

Тому найкраще спробуйте спочатку, після повного заповнення перевірте дані SMART, щоб побачити, скільки перерозподілів ще можна зробити.

Не так важливо, скільки перерозподілів було зроблено; більшість SSD прийшли від виробника з деякими блоками, які вже перерозподілені, знайти один з нулем менше 1%, тому важливим є співвідношення, перерозподілення та майбутні можливості перерозподілу.

Це мій досвід після того, як сотні SSD померли протягом 5 п'яти років, одні померли в першу годину використання, інші через тиждень, інші через місяць; але все, що я робив таку нульову повну заповнення, жив протягом 2 - 3 років, з 13GiB, що пишеться щодня, 3 * 365 * 13 GiB = 13,9 TiB, набагато менше, ніж кажуть виробництво (> 100TiB).

Але швидкість має значення, більшість, якщо в Windows (в Linux хороший 2xHDD LVM2-смуга дає чіткі ж завантажувальні часи, але це не виходить з ладу> 25 років), тому використання SSD з ціною 0,21 € за гігабайт (120GiB = 25 €) є варто того (для Windows), серед яких вони змінюються через 2 або 3 роки; Я сподіваюся, що технологія покращить надійність.

Для Linux я не хочу більше SSD, поки thay не стане більш надійним, але для Windows (Vista, 7 та 10) системний розділ є обов'язковим (завантаження в десятки разів нижче в деяких випадках, для Windows Vista, замість> 30 хвилин завантаження його чоботи на> 4 хвилини на моєму старому ноутбуці).

Так, повне заповнення нулів є обов'язковим, враховуючи мій досвід.

Але лише тоді, коли ви отримаєте SSD та перед тим, як використовувати його для чого-небудь.

Порада: Якщо SSD не працює добре на збиранні сміття, а операційна система не каже йому обрізати все, краще виконайте повне заповнення нулів, врешті-решт, це все, що відбувається на SSD, коли він відкидає блоки. Також запис нулів очистить електронні, тому це допомагає відновити несправні блоки зчитування.

Крім того, щоразу, коли ви змінюєте дані про нього, намагайтеся зробити клон, SSD повідомить, що написання було в порядку, також на нечитаних секторах (вони можуть бути написані нормально, але не читаються), жодна операційна система не розроблена для підтримки такої умови всі вони вважають, що якщо з віттом все в порядку, можна прочитати дані; не плутайте читабельність з прочитаними різними даними, які були написані.

Такий мій досвід роботи з SSD і HDD. Для завантаження та додатків Windows я використовую SSD, але завжди з клоном, який робиться на звичайних жорстких дисках, оскільки SSD помирає менше ніж за 3 роки, але за версією Linux я використовую 2x або 3x хороший 2,5-дюймовий HDD, ви отримуєте аналогічні часи при звичайному використанні, як і SSD , але триває набагато довше (> 25 років).

Мені не доплачувати> 1000 € за SSD 100GiB, який працює добре протягом 10 років, я бажаю платити 25 € за 130GiB кожні 2 або 3 роки. Ціна має значення 100 євро на рік (підприємство) проти 10 євро на рік (Yucon, Samsung тощо), просто займайтеся математикою.


Змусити писати над поганими секторами - це справді досить надійний спосіб їх "виправити", якщо все ще є зарезервовані сектори.
конфетті
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.