LINUX.ORG.RU

История изменений

Исправление nebularia, (текущая версия) :

Мне кажется ты считаешь жёсткие диски и файловые системы слишком умными. При натыкании на реальный бэд во время такой записи нулями у тебя всё очень надолго зависнет и скорее всего диск в итоге в прицепе отобьёт из системы по i/o error.

А fsck условной ext4 никакие бэды не ищет и не ремапит.

По поводу «решится» тут на мой взгляд у тебя два пути при обнаружении бэдов. Первый и правильный - слить данные с диска и отправить его на помойку. Второй - найти области с бэдами и разметить разделы вокруг них с запасом. Тогда если проблема была единичной, диск ещё долго проработает, но сильно надёжным его после такого считать всё равно нельзя.

Исправление nebularia, :

Мне кажется ты считаешь жёсткие диски и файловые системы слишком умными. При натыкании на реальный бэд во время такой записи нулями у тебя всё очень надолго зависнет и скорее всего диск в итоге в прицепе отобьёт из системы по i/o error.

А fsck условной ext4 никакие бэды не ищет и не ремапит.

По поводу «решится» тут на мой взгляд у тебя два пути. Первый и правильный - слить данные с диска и отправить его на помойку. Второй - найти области с бэдами и разметить разделы вокруг них с запасом. Тогда если проблема была единичной, диск ещё долго проработает, но сильно надёжным его после такого считать всё равно нельзя.

Исходная версия nebularia, :

Мне кажется ты считаешь жёсткие диски и файловые системы слишком умными. При натыкании на реальный бэд во время такой записи нулями у тебя всё очень надолго зависнет и скорее всего диск в итоге в прицепе отобьёт из системы по i/o error.

А fsck условной ext4 никакие бэды не ищет.

По поводу «решится» тут на мой взгляд у тебя два пути. Первый и правильный - слить данные с диска и отправить его на помойку. Второй - найти области с бэдами и разметить разделы вокруг них с запасом. Тогда если проблема была единичной, диск ещё долго проработает, но сильно надёжным его после такого считать всё равно нельзя.