Напомните команду пишущую гигабайтные файлы пока не исчерпается место?

f3

запись:
f3write

Проверка:
f3read

SD карта, фото повреждены (комментарий)

dd if=/dev/zero of=file.dat. Команда завершится, когда будет достигнут максимальный размер файла, или когда кончится место.

badblocks

Не знаю зачем это нужно ТС, но:

и писались не нули, а случайные данные

может ему нужен /dev/urandom, может ″openssl enc″ на /dev/zero. Хотя пишут, что shred быстрее генерит мусор:

i=0; while {>trash-$i; shred -n 1 -s 1G trash-$i; } ; do ((i++)) ; done

и писались не нули, а случайные данные

/dev/zero

У меня тоже бывает, что читаю тем, что сзади.

Спасибо, это я и искал, но проснулся и полез в чат с тем от кого про неё и узнал. Там вспомнил.

dd if=/dev/zero of=file.dat. Команда завершится, когда будет достигнут максимальный размер файла, или когда кончится место.

Зачем? В исходном было описание того что делало приложение. Им был f3write, я тогда фейковые флешки мучал.

badblocks

Тоже вариант, но его я на устройство напускал, а не на файл.

Сейчас похоже на винте, появились бэды.

smartctl?

может ему нужен /dev/urandom, может ″openssl enc″ на /dev/zero. Хотя пишут, что shred быстрее генерит мусор:

Ну в заголовке топикстарта: «Напомните команду». Ей оказался f3write, специализированная тулза. Впрочем я написал «команду», а под эту спецификацию попадает и сложная командная строка.

smartctl?

Это из другой оперы. Я пойду с конца, посмотрю как zfs это сможет отработать. Потом и smartctl и другой инструментарий.
Главное вспомнить что я использовал в Linux для инициации ремапа в прошлые разы.
Надо перечитать прошлые мои треды здесь.

Прочитал заголовок темы, пришёл посоветовать dd. Естественно, оказалось, что я не первый такой хитрожоп, всё благополучно :)

badblocks

Кстати у badblocks есть ещё одна фича - она перезаписывает информацию на диске - т.е. обновляет её, и теоретически, бэды могут появляться и в результате потери намагниченности, а она её обновляет.
Но вот запускать её надо на размонтированный диск.
Хочу практиковать регулярный badblocks на мои винты - но руки не доходят... :(

Просто были прецеднты исправления БЭДа - перезаписью 0 в сектор, но конечно это мог сработать и авторемап.

достаточно smartctl -t short делать периодически и -t long по случаю.

достаточно smartctl -t short делать периодически и -t long по случаю.

«Достаточно» Для чего?
Насколько я знаю, ты там сможешь только узнать о наличии ЕДИНСТВЕННОЙ ОШИБКИ, после её нахождения он встаёт.
У меня уже попалась пара нечитаемых файлов.
zfs это показывает по #zpool status -v
Сейчас начну заниматься извращениями:
Уже удалил битые файлы (Толстые многогигабайтные образы флэшек).
Сейчас запустил f3write ./ Уже часов 6 трудится.
Как кончит - пущу f3read ./ и посмотрю. Ошибка появится или zfs сама в недрах изолирует битый сектор после того как я удалил файл его содержащий?
Ну а там, загружусь с флешки и начну жужжать всем что попадёт под руку, начиная с Виктории и заканчивая hdd-regenerator-ом.
Кстати уже были прецеденты когда hddregenerator восстанавливал то что не могла Виктория (я так понимаю, что у badblocks - тот же функционал, он обновляет записаную информацию, читая и перезаписывая её). Ну и конечно же #badblocks. Викторией скорее всего просто отсканирую до и после badblocks и запротоколирую результаты.
Благо мой основной комп - уже не основной, всё рсинкнул на 3 USB3 винта включенных в МикроПК. Вот как буду рсинкать обратно - пока технологию не придумал.
Но теперь не напрягаясь, могу использовать МикроПК, а десктоп с рейдом - гонять загрузившись с флешки.

о наличии ЕДИНСТВЕННОЙ ОШИБКИ, после её нахождения он встаёт
это откуда такие сведения? ;-)

ничо он не встаёт. ещё и полечить иногда удаётся.

причём ошибка может быть не в самом диске, а (например) в кабеле.

у тя носитель-то ваще какой?

Это вполне практическое соображение, но невозможность делать такое онлайн действительно мешает. В винде, как это ни смешно, этот полезный эффект достигается плановой дефрагментацией. В онтопике можно перенамагничивать на лету через pvmove туда-сюда, если, конечно, тома лежат на LVM, что не особо популярно. Мб на xfs есть похожая операция, конечно.

ничо он не встаёт. ещё и полечить иногда удаётся.

4.2

dd if=/dev/random что ли?

Как вариант, badblocks -n можно вызывать для каждого файла. Хотя mtime слетает.

что это?

mtime можно по touch восстановить

Как кончит - пущу f3read ./ и посмотрю. Ошибка появится или zfs сама в недрах изолирует битый сектор после того как я удалил файл его содержащий?

Запись отработала за 6.5 часов. Записала 390 файлов по 1Gb
Чтение за 1:13, все файлы прочитались без ошибок!
А вот при попытке пометить их все в mc и удалить - компьютер, не висший лет 12 - повис наглухо! Десктоп замёрз, Alt-SysRQ не работало. Перед этим mc показал пустой каталог.
Перезагрузился. В тестовом каталоге осталось 375 файлов.
Сейчас отправлю и ещё раз попробую удалить из mc

Сейчас отправлю и ещё раз попробую удалить из mc

Результат повторился. Теперь осталось 349 файлов.

Результат повторился. Теперь осталось 349 файлов.

попытался #rm * - результат тот же, 335 файлов.

попытался #rm * - результат тот же, 335 файлов.

Решил удалять кусочками по 70-100 файлов. После каждого удаления - пару минут ждал пока zfs не остановит обращение к диску. Скажем mc 30 секунд удалял 100 файлов, а потом 2:30 было активное обращение к HDD системными процессами zfs.
Таким алгоритмом всё удалил, и компьютер не повис.
По результатам этой ситуации - как нибудь сделаю ещё одну попытку забить в ноль zfs и удалить все файлы, уже на другом ПК.

В винде, как это ни смешно, этот полезный эффект достигается плановой дефрагментацией.

Не уверен что оно дефрагментирует нефрагментированные файлы.

mtime можно по touch восстановить

Это «танцы с бубном».

пару минут ждал пока zfs не остановит обращение к диску

Надо же, а говорили, что 12309 пофикшен

не, эта нулями забьёт, там толи /dev/urandom толи /dev/random надо вместо /dev/zero

Забивания нулями в большинстве случаев достаточно. Но вообще, конечно, нужно не просто затирать рандомными байтами, а и проверять каждый записанный байт чтением, и если всë читается достаточно быстро, можно с уверенностью говорить, что с диском всë нормально.

впринципе довольно глупо затирать нулями или рандомом диск, на параною или адский костыль смахивает, однако ТС спросил, лорчанин ответил, разве не так? Зачем докапываться и/или писать не полностью подходящую под вопрос команду?

о наличии ЕДИНСТВЕННОЙ ОШИБКИ, после её нахождения он встаёт

это откуда такие сведения? ;-)

По результатам -t long. В отчёте так и пишется - осталось 40%

ничо он не встаёт. ещё и полечить иногда удаётся.

Этокак?

причём ошибка может быть не в самом диске, а (например) в кабеле.

Если ошибку дал -t то она в диске!

у тя носитель-то ваще какой?

Device Model:     TOSHIBA DT01ACA300
  9 Power_On_Hours          0x0012   095   095   000    Old_age   Always       -       39855

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       40%     39752         3352487288

Запустил тест, почти 6 часов:

smartctl -t long /dev/sdd
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-40-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 354 minutes for test to complete.
Test will complete after Thu Oct 30 07:16:34 2025 MSK
Use smartctl -X to abort test.

Перед этим забив до 0 zfs и прочитав файлы без ошибок.

Забивания нулями в большинстве случаев достаточно. Но вообще, конечно, нужно не просто затирать рандомными байтами, а и проверять каждый записанный байт чтением, и если всë читается достаточно быстро, можно с уверенностью говорить, что с диском всë нормально.

У меня zfs с упаковкой, нули не катят.
Впрочем f3write кроме забивания умет ещё и проверять при чтении.