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

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 кроме забивания умет ещё и проверять при чтении.

о! знакомая модель! единственная которую я на гарантии как брак сдавал. основная проблема с ними:

84 51 31 07 fb c8 0b Error: ICRC, ABRT at LBA = 0x0bc8fb07 = 197720839
60 40 a0 b8 07 c9 40 08 21:49:33.028 READ FPDMA QUEUED

если у тя написало, что ошибка и не продолжила - значит там совсем хана. и надо думать куда с этого диска данные спасти

покажи smartctl -l error ? (это к вопросу о кабеле и БП)

у меня в основном pending были - это как раз лечится -t long и потом прогоняешь запись в нужное место, проще всего badblocks -n на нужные сектора, лучше с запасом чтобы всю дорожку переписал

Я в таких непонятных ситуациях прогонял сомнительный диск через mhdd 4.6 на «старом компе без UEFI». В режиме чтения всего диска с включённым ремапом (F4-remap-F4) справа колонка со временем доступа. Если большое количество (>10) секторов со временем доступа 500, то «условно всё плохо». Для нормальной «быстрой» работы такой диск не пригоден. Разные программы по разному реагируют на такой тупящий диск. Кто-то будет просто ждать, кто-то отваливаться с ошибками чтения/записи. Если его засунуть в рэйд, то рэйд будет периодически разваливаться, из-за того что диск не успел вовремя ответить. Хотя при этом диск целый будет. Один из вариантов более-менее использования нарезать несколько разделов избегая областей с медленными секторами. И отдать эти разделы под торренты.

while true; do openssl rand -out $(mktemp) 1G

npm install

покажи smartctl -l error ? (это к вопросу о кабеле и БП)

https://pastebin.com/nxd9NCSn

у меня в основном pending были - это как раз лечится -t long и потом прогоняешь запись в нужное место, проще всего badblocks -n на нужные сектора, лучше с запасом чтобы всю дорожку переписал

Я вот только не понимаю. Я хотел на уровне файлов - сначала изолировать. zfs определили битые файлы, но это были толстые образы загрузочных флэшек. Я их удалил, сделал f3write пока не забил раздел, затем f3read - всё прочиталось без ошибок.
Ладно, запустил: dd if=/dev/sdd of=/dev/null bs=1M status=progress conv=noerror 2>&1|tee -a dd-read.log
Всё тоже прочиталось без ошибок.
Лишь badblocks дал:

Checking for bad blocks in non-destructive read-write mode
From block 0 to 2930266583
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 1676243644ne, 15:48:22 elapsed. (0/0/0 errors)
1676243645ne, 15:48:26 elapsed. (1/0/0 errors)
1676243646ne, 15:48:29 elapsed. (2/0/0 errors)
1676243647ne, 15:48:33 elapsed. (3/0/0 errors)
1676243648ne, 15:48:37 elapsed. (4/0/0 errors)
1676243649ne, 15:48:40 elapsed. (5/0/0 errors)
1676243650ne, 15:48:44 elapsed. (6/0/0 errors)
1676243651ne, 15:48:47 elapsed. (7/0/0 errors)
 68.30% done, 21:14:45 elapsed. (8/0/0 errors)

у меня в основном pending были - это как раз лечится -t long и потом прогоняешь запись в нужное место, проще всего badblocks -n на нужные сектора, лучше с запасом чтобы всю дорожку переписал

А это подробнее можешь разъяснить?
Типа -t long и потом пишешь в сектор на котором он остановился?
И наверное не badblocks -n а badblocks -w ?

Я в таких непонятных ситуациях прогонял сомнительный диск через mhdd 4.6 на «старом компе без UEFI»

Для UEFI Есть такая штука - Ventoy, грузишься хоть из UEFI с флэшки и выбираешь загрузочный ISO, думаю можно подсунуть ISO с mhdd. Только мне больше нравится hdd-regenerator, но тоже им давно не пользовался. Вообще есть подозрение что badblocks в Linux - делает то же. Но не просто читает и пишет, а читает, пишет и читает несколько шаблонов данных в каждый сектор и если всё в порядке - записывает то что было.

Врут.

Это всё тот же изврат с zfs-массивом на usb дисках?

Это всё тот же изврат с zfs-массивом на usb дисках?

Что значит zfs-массив?
В данном случае это тот хост, которого был сделан рсинк на USB3 винты. Но вот есть у меня каталог, с одной стороны барахло, а сдругой - ценное барахло. То что я много лет качал с интернета, папка: DL я решил её держать не на рейде, а на отдельном винте. Вот он и посыпался. 8 секторов.
Оно с одной стороны барахло - но сейчас пожалуй и не найдёшь источники этого 10летнего барахла. Всякие подборки загрузочных флешек, мультисистемные.

Это всё тот же изврат с zfs-массивом на usb дисках?

Мне другое покоя не даёт :(
Я удалил битые файлы. Запустил f3write. Забил всё пустое место и они прочитались без ошибок.
Я предположил что zfs изолировал битые сектора,
запустил dd - тот прочитал без ошибок весь диск!
Для контроля запустил badblocks -n - Он нашел уже 8 битых секторов и ему ещё 30% осталось. Но битые они подряд.

Почему это не проявилось на zfs и dd?

npm install

Сначала уж apt install npm но зачем?

да.

нет. -n. просто мне обычно важна инфа в тех секторах и обычно это pending. YMMV. -w если данные совсем не важны. хотя он по понятным причинам быстрее. ещё -p1 -t шаблон - твои друзья.

а, да, в твоём случае можно selective делать и после диска для badblocks указывать с какого и по какой

ну и судя по соседству проблем - у тя там черкаш на поверхности скорее всего, надо remap.

if=/dev/random