The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Проблема с повреждением разделов Ext4 оказалась в md-raid0

23.05.2015 08:22

Проблема с потерей данных на разделах с файловой системой Ext4, о которой сообщалось несколько дней назад, оказалась не специфична для файловой системы Ext4. Проблема присутствует в коде подсистемы md и может привести к непредсказуемому нарушению целостности файловой системы при изменении или удалении файлов. Проблема проявляется только для ФС, установленных поверх RAID 0 и примонтированных с опцией DISCARD.

Ошибка проявляется в ветках ядра 4.0 и 3.14 LTS, начиная с выпусков 4.0.2 и 3.14.41. В настоящее время исправление доступно в виде патча, который уже включён в Git-репозиторий ветки 4.1. Для Arch Linux уже выпущены устраняющие проблему обновления ядра linux 4.0.4-2 и linux-lts 3.14.43-2. В основном ядре исправления ожидаются в выпусках 4.0.5 и 3.14.44. Пользователям ядер 4.0.2+ и 3.14.41+, у которых применяется RAID0 с опцией DISCARD, рекомендуется перемонтировать раздел без DISCARD и проверить целостность файловой системы при помощи fsck.

  1. Главная ссылка к новости (https://lkml.org/lkml/2015/5/2...)
  2. OpenNews: В ядре Linux выявлены ошибки, приводящие к зависанию процессов и повреждению разделов EXT4
  3. OpenNews: Для файловой системы Ext4 представлена поддержка шифрования
  4. OpenNews: В Ext4 исправлена ошибка, которая потенциально могла привести к разрушению данных
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/42286-ext4
Ключевые слова: ext4, raid
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (67) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, A.Stahl (ok), 08:44, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +31 +/
    >оказалась не специфична для файловой системы Ext4.

    Ну вот, поспешили с выводами. Не разобрались.
    А свидетели стабильного btrfs чуть второе пришествие не объявили (эти странные фанатики почему-то уверены, что достаточно найти хоть одну какую-то ошибку или уязвимость в Ext*, чтобы объявить о тотальном превосходстве btrfs).

     
     
  • 2.4, rob pike (?), 09:03, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Та же история что и с провозвестниками чудесного нового мира systemd.
    Очень приятно себя чувствовать прогрессивными, а всех остальных - луддитами.
     
     
  • 3.66, Аноним (-), 23:05, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень приятно себя чувствовать прогрессивными, а всех остальных - луддитами.

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

     
     
  • 4.79, cryo (??), 13:34, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Для того, чтобы не щипать волосы на ж.пе, достаточно для любой из extX использовать сторонние продукты live-бэкапа. Например, appassure. Для домашнего тазика - не решение, а для корпоративной сети - самое оно.
     
  • 2.9, Xasd (ok), 10:20, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • –14 +/
    ооххх как же это знакомо - старпёры почему-то уверенны что стоит найти хоть о... большой текст свёрнут, показать
     
     
  • 3.10, Аноним (-), 11:08, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > стоит найти хоть одну какую-то ошибку в Btrfs

    Одну? Скорее тысячу и одну. Видите ли, именно потому бывают новости "обнаружена ошибка в ext4", но не бывает таких новостей про btrfs.

    Вы сами, не-старпер, готовы поставить целостность своей задницы в зависимость от сохранности данных, лежащих на btrfs?

     
     
  • 4.13, неважнокто (?), 12:02, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Вы сами, не-старпер, готовы поставить целостность своей задницы в зависимость от сохранности данных, лежащих на btrfs?

    Он готов. Только при этом четыре раза в день будет делать бэкапы на соседний раздел, который ext4. А в случае проблем будет с него восстанавливаться. Но да, кричать везде будет, что у него "btrfs на основном разделе и за полгода никаких проблем. Просто делайте бэкапы".

     
     
  • 5.16, Xasd (ok), 12:31, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    бекапы -- на любую файловую систему можно закачивать - вероятность того что... большой текст свёрнут, показать
     
     
  • 6.22, Xasd (ok), 14:16, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну вообще, конечно, всякое может случиться - поэтому я и оперирую термином ... большой текст свёрнут, показать
     
     
  • 7.27, iZEN (ok), 17:57, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Вообще же, в русском языке новое предложение начинается с заглавной буквы. На клавиатуре есть клавиша Shift. Так вот, раскрываю секрет! Удерживая её и нажимая клавишу с буквой, можно очень быстро ввести заглавную букву вместо строчной, соответствующей клавиши.
     
     
  • 8.43, Аноним (-), 01:57, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Хоть изен и ламо, но придется ему поставить плюс Все-таки нельзя так класть ... текст свёрнут, показать
     
  • 7.32, Michael Shigorin (ok), 23:00, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ну вообще, конечно, всякое может случиться :-) . поэтому я и оперирую
    > термином "вероятность" :-D . и не называю точные цифры!

    Ну почему же, Вы ведь их знаете -- 50/50, или случится, или не случится.

    > а расчитать эти вероятности -- не так-то просто

    Раз уж берётесь оценивать сложность оценки вероятности -- прошу для развлечения произвести таковую для ошибки вроде исправленной этим двустрочником хотя бы в нулевом приближении.

    Нас-то в школе учили не пытаться оцифривать то, для чего данных недостаточно...

     
  • 7.62, Аноним (-), 16:58, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > я тоже так думал, пока на одном сервере не умерло два винта одновременно. А на предыдущей работе 4 винта в полке ;) Но да, вероятность маленькая :D

    Возможно у них была общая причина - неисправный БП.

     
  • 3.31, Michael Shigorin (ok), 22:57, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > старпёры почему-то уверенны что стоит найти хоть одну какую-то ошибку в Btrfs
    > -- и сразу значит можно объявлять о "Btrfs ещё не готова".. :)

    Никогда не сидели над блокдевайсом, припоминая старые добрые времена, когда эти циферки были структурами данных?

    Да, ОДНОЙ найденной в новой ФС неприятной ошибки ДОСТАТОЧНО, чтобы отложить на несколько лет следующую оценку пригодности к работе.  Если Вы этого не поняли -- не трогайте чужие данные, гробьте только свои.

    Помнится, про ZFS здесь писал аналогичное, указывая на приплывший Joyent.

     
     
  • 4.39, Аноним (-), 01:49, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > не поняли -- не трогайте чужие данные, гробьте только свои.

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

    > Помнится, про ZFS здесь писал аналогичное, указывая на приплывший Joyent.

    А теперь - пойдем и посмотрим git log на fs/ и узнаем как страшно жить :)

    На самом деле ошибки бывают в любом достаточно сложном коде и если ждать пока их выловят ВООБЩЕ ВСЕ - можно умереть стариком, боясь использовать даже FAT12. А с практической точки зрения есть такая штука как резервирование. Ну там бэкапы, например. Поскольку раз в год и палка стреляет.

     
     
  • 5.58, Michael Shigorin (ok), 11:30, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А теперь - пойдем и посмотрим git log на fs/ и узнаем, как страшно жить :)

    Например, ровно из таких соображений до 2.6.30 и не думал доверять свои данные пресловутой ext4 (а на SSD пришлось ещё некоторое время выждать).

    > А с практической точки зрения есть такая штука как резервирование.

    Это понятно, но не отменяет.

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

     
     
  • 6.65, Аноним (-), 23:03, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И это правильно - в ext4 до 2 6 28 включительно были довольно убедительные баги ... большой текст свёрнут, показать
     
     
  • 7.74, Michael Shigorin (ok), 00:44, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы в 2.6.30 и далее пользовались фс ... которая на очень больших томах с очень
    > большими файлами рассыпалась. Просто столь огромные файлы были далеко не у
    > каждого первого. Но баг был убедительный.

    Именно, и в этих "каждого первого" не входил -- а в какие входил, то уже успели вытоптать на поголовье федоры и готовых к сюрпризам в полном сознании.

    > Но если переборщить - так можно за FAT16 цепляться до самой могилы.

    А тут уж каждый сам для себя баланс находит :)  Как там -- "моё дело мяукнуть"...

     
  • 3.44, Аноним (-), 02:05, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зря копья ломаете. Смысл? Ну путь юзают что кому удобнее, лишь бы не винду.
     
     
  • 4.63, iZEN (ok), 20:20, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Зря копья ломаете. Смысл? Ну путь юзают что кому удобнее, лишь бы не винду.

    А винда-то тут причём? Надёжная и проверенная временем операционная система, с которой знакомо подавляющая часть населения (кроме упоротых линуксоидов). Юзают — не плачут.


     
     
  • 5.64, Michael Shigorin (ok), 21:32, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > знокомо
    > знакомо

    Ух ты, первую ашибку заметил сам; вторую, может, допетрит после подсказки; главное, чтоб с разгону и "третью" не нашёл, а переключился на логические. :)

     
  • 3.77, XoRe (ok), 01:23, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ни кто из пользователей Ext4 не использует md-raid0 (ды и с discard)?

    Кстати, используют, когда нужен быстрый кеш на SSD с рабочим discard.
    Не все хардварные контроллеры прокидывают discard.
    Но использовать raid0 - это подписаться под "мне насрать на данные в массиве".

     
  • 2.38, Аноним (-), 01:32, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А свидетели стабильного btrfs чуть второе пришествие не объявили

    ...наверное потому что у них свой RAID, с шахматами и поэтессами, силами самой ФС, так что md-raid им ни в п...у ни в красну армию. Сделать RAID0 средствами btrfs будет умнее т.к. это даст больше возможностей + возможность плавной миграции на какой-нибудь иной уровень, если хочется :)

     
     
  • 3.46, Gannet (ok), 02:12, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Сделать raid силами Btrfs просто несколько проще, чем использовать EXT4+mdamd. И не надо тут язвить. Когда есть EXT4 и нужен raid, пользуем mdadm, когда btrfs - всё уже средствами самой ФС делаем.
     
     
  • 4.71, ffirefox (?), 00:24, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда есть EXT4 и нужен raid, пользуем mdadm

    Ну, зачем так категорично...RedHat усиленно продвигает LVM как альтернативу.

     
  • 3.61, Crazy Alex (ok), 15:01, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Из общих соображений - поймать багу в коде RAID btrfs куда как больше шансов - он моложе, его мало гоняли.
     

  • 1.2, Старшина Кириллов (?), 08:49, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Поздно, тролли уже успели обгадить со всех сторон ext4.
     
     
  • 2.5, Аноним (-), 09:18, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  Поздно, тролли уже успели обгадить со всех сторон ext4.

    Ниче не поздно: к черту троллей.

     
  • 2.24, arisu (ok), 15:39, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Поздно, тролли уже успели обгадить со всех сторон ext4.

    и что?

     

  • 1.3, Аноним (-), 08:50, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ZFS cамая стабильная
     
     
  • 2.7, Аноним (-), 09:28, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Только оперативы не напасешься
     
  • 2.19, InventoRs (ok), 13:50, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ZFS cамая стабильная

    какая конкретно её реализация или портирование?

     
     
  • 3.21, Аноним (-), 14:10, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Illumos/BSD
     
  • 2.33, Michael Shigorin (ok), 23:01, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ZFS cамая стабильная

    Сановская на спарочке?  Напоминаю недавнее: http://techcrunch.com/2008/01/15/joyent-suffers-major-downtime-due-to-zfs-bug

     
     
  • 3.36, wulf (ok), 23:44, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > 2008

    Это писец насколько свежее. Уже прошло 7(семь)!!!! лет и несколько месяцев.

     
     
  • 4.37, wulf (ok), 23:47, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> 2008
    > Это писец насколько свежее. Уже прошло 7(семь)!!!! лет и несколько месяцев.

    Михаил, Вам еще в самый раз вспомнить знаменитую страшилку из блога лисяры про разваленый райд

     
     
  • 5.56, Michael Shigorin (ok), 10:57, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Михаил, Вам еще в самый раз вспомнить знаменитую страшилку из блога лисяры
    > про разваленый райд

    Если это про тот vinum в очумелых ручках Dear Never -- не, там давность вдвое больше, а релевантность платформы в стораджевом сегменте на сколько-то порядков (пяток там, десяток) меньше...

     
  • 4.45, Аноним (-), 02:07, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> 2008
    >Уже прошло 7(семь)!!!! лет и несколько месяцев.

    Просто он не так молод как некоторые. Ощущение времени другое.
    Он еще байки из 90-х любит рассказывать про каких-то студентов и прочие заговоры.

     
  • 3.40, Аноним (-), 01:51, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Сановская на спарочке?  Напоминаю недавнее: http://techcrunch.com/2008

    Ничего себе недавнее. Хотя если вы законспирированный МакЛауд - для вас 7 лет, несомненно, ерунда.

     
     
  • 4.55, Michael Shigorin (ok), 10:55, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Сановская на спарочке?  Напоминаю недавнее: http://techcrunch.com/2008
    > Ничего себе недавнее.

    Иэхх, прям перепись тех, кого к чужим данным пускать не стоит.  Да, недавнее для *такого* попадалова с учётом тогдашней репутации ещё Sun и дальнейшей траектории этого кода по рукам.

    Если бы Вас лично вроде бы хороший друг основательно кинул пятую часть жизни тому -- точно бы опять уже ему всё доверили?

     
     
  • 5.59, wulf (ok), 12:57, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Иэхх, прям перепись тех, кого к чужим данным пускать не стоит.

    Сразу заметен манагер с привычками "лить гуано в уши клиентов". Как поймали за руку сразу начал изворачиваться и дальше продолжать врать.

    А ничего что там в joyent-e стоял оооочень бородатый solaris-express из тех годов (2005?) когда zfs еще не попала в релизы и эти дятлы забив на обновление бета-версий словили баг исправленный за 2 года до этого? Причем Вы это прекрасно знаете но продолжаете врать не краснея.

    Вы не разу не то что не работали с zfs, но даже и не видели ее, но с умным видом несете всякую напетую различными Цеперовичами хрень! Стыдно, Михаил

     
     
  • 6.67, Аноним (-), 23:20, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Сразу заметен манагер с привычками "лить гуано в уши клиентов".

    Справедливости ради, сан это умел получше Шигорина, раз так в эн. До сих пор лезут упыри, защищающие древний и достаточно грабельный дизайн с аргументом "патамучта гладиолус".

    В смысле, технически аргументировть на уровне структур файлухи и логики работы почему сановское нечто хорошее они не могут, но зато яростно набрасываются на всех кто смеет в этом усомниться.

     
     
  • 7.73, Аноним (-), 00:40, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > В смысле, технически аргументировть на уровне структур файлухи и логики работы почему сановское нечто хорошее они не могут, но зато яростно набрасываются на всех кто смеет в этом усомниться.

    Нет. Просто все помнят слова Иисуса Христа про бисер, свиней и user-а294

     
     
  • 8.75, Michael Shigorin (ok), 00:46, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то там растерзают , а не поюзают , так что не надо ... текст свёрнут, показать
     
     
  • 9.76, Аноним (-), 01:11, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В первоисточнике не было растерзают или поюзают Было мечут ... текст свёрнут, показать
     
     
  • 10.80, Michael Shigorin (ok), 13:37, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Было --- Не давайте святыни псам и не бросайте жемчуга вашего перед свиньями, ч... текст свёрнут, показать
     
  • 5.70, Аноним (-), 23:38, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В данном случае 294-го Который умеет и в резервное копирование, и вопросы ка... большой текст свёрнут, показать
     
     
  • 6.72, Michael Shigorin (ok), 00:39, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > по поводу чего мысль о том кого там к чьим данным пускать не надо ...
    > ну ... наверное здорово ощущать себя самым умным на планете.
    > Жаль что это ощущение редко оказывается истинным.

    Вот и я о чём.  Если ещё не теряли чужие данные (необязательно из-за сбоя ФС) -- ну... наверное, всё ещё впереди.  А чувствуешь в таком случае себя самым большим дураком на свете -- потому как мог, но не предусмотрел что-то даже не за себя -- за других.

     

  • 1.8, Михрютка (ok), 09:37, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Проблема проявляется только для ФС, установленных поверх RAID 0  и
    > примонтированных с опцией DISCARD.

    предлагаю добавить в mount новую опцию

    mount -o я-прогрессивный-поэтому-включаю-любую-НЁХ-про-которую-на-похорониксе-или-опеннете-написали-что-это-круто

    которая будет прописывать нулями один случайный блок при монтировании ФС.

     
     
  • 2.11, Xasd (ok), 11:13, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    слишком универсальное решение :-) ..

    нужно время от времени менять название этой опции.. и объявлять новое актуальное название в новостях :-)

    (а старое название объявлять устаревшим, и делать kernel-panic при его использовании)

     
     
  • 3.14, Аноним (-), 12:03, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше менять поведение старой опции, повышая грабельность — сегодня 1 блок, завтра 2, послезавтра 1 +1 с вероятностью 30%
     
  • 2.17, rob pike (?), 12:34, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Думаете это их остановит? Студенты еще 100 лет назад ради ощущения собственной избранности, правоты и прогрессивности на каторгу шли и бомбами в царя кидались.
    А тут какой-то случайный блок.
     
     
     
    Часть нити удалена модератором

  • 4.53, rob pike (?), 10:28, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы завязывайте лучше с алкоголем.
    Речь была про свидетелей секты самых-прогрессивных-systemd-и-btrfs
     
  • 2.18, Аноним (-), 13:35, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    DISCARD вроде как SSD-шный TRIM включает, при чём тут НЁХ?
     
     
  • 3.20, ALex_hha (ok), 14:07, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > вероятность того что поломаются одновременно в один день сразу оба накопителя (и боевой и бэкап) -- не сильно высока. :-) не зависимо от того какая там файловая система на любом из них..

    я тоже так думал, пока на одном сервере не умерло два винта одновременно. А на предыдущей работе 4 винта в полке ;) Но да, вероятность маленькая :D

     
     
  • 4.34, Michael Shigorin (ok), 23:04, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > я тоже так думал, пока на одном сервере не умерло два винта одновременно.
    > А на предыдущей работе 4 винта в полке ;) Но да, вероятность маленькая :D

    Если сигейты, то не такая уж и маленькая...

    Ну и для RAID5 хорошо известен эффект double fault, когда следующий в очереди на вылетание диск под повышенной нагрузкой при resync не успевает отдать все данные.

     
     
  • 5.68, Михрютка (ok), 23:28, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну и для RAID5 хорошо известен эффект double fault, когда следующий в
    > очереди на вылетание диск под повышенной нагрузкой при resync не успевает
    > отдать все данные.

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

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

     
  • 5.88, s7demon (ok), 07:21, 26/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да чёрт с ней,с ФС.Миша ,скажи честно Альт сдох?Даже на вашем форуме всего два бойца,а англоязычная часть сайта обновлялась два года назад.
     
     
  • 6.89, Michael Shigorin (ok), 16:47, 26/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Миша, скажи честно Альт сдох?

    Не дождётесь (ц)

    > Даже на вашем форуме всего два бойца,

    Странно, на http://forum.altlinux.org их поболе будет...

    > а англоязычная часть сайта обновлялась два года назад.

    Ну вот новость про 7.0.5 попросили перевести -- может, появится.  Посмотрите на основной altlinux.ru и скажите, какие именно новости за это время животрепещут на английском, но отсутствуют.

    А ещё лучше пойдёмте в соседнюю https://www.opennet.ru/opennews/art.shtml?num=42299 и не будем спамить здесь.

     
  • 3.41, Аноним (-), 01:51, 24/05/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > DISCARD вроде как SSD-шный TRIM включает, при чём тут НЁХ?

    Он как раз нулями затирает блоки. Правда, не случайные. А которые более не используются ФС :)

     

  • 1.23, OberonForGood (?), 15:32, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Писали бы на нормальном языке - не возникло бы таких проблем.
     
     
  • 2.35, rob pike (?), 23:26, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Возникли бы другие.
    there is no one silver bullet
     

  • 1.25, manster (ok), 16:00, 23/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    оперативно нашли, наверное bisect-ом
     
     
  • 2.29, Ananas (?), 19:53, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вероятно. Отличный инструмент, к слову. Намедни с помощью него нашёл баг в одном из 160 коммитов. Не знаю, сколько бы руками искал.
     
  • 2.30, pkunk (ok), 21:25, 23/05/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://bugzilla.kernel.org/show_bug.cgi?id=98501
     

  • 1.78, Ващенаглухо (ok), 09:04, 25/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Все, кто использует raid0 должны быть готовы, что настанет жопа и делать бекапы.
     
     
  • 2.84, ALex_hha (ok), 22:06, 25/05/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Если сигейты, то не такая уж и маленькая...

    в полке вроде hitachi были, sas

    > Ну и для RAID5 хорошо известен эффект double fault, когда следующий в очереди на вылетание диск под повышенной нагрузкой при resync не успевает отдать все данные.

    два диска были в зеркале


     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру