Твердотельные накопители от Samsung оправданы. Проблема оказалась в ядре Linux

[@edwardoid]

Шикарно, пацаны! Молодцы и Angolia, и Samsung, и коммитеры Oracle/FB!

[@HomoLuden]

Angolia Algolia

[@mclander]

Эти тоже молодцы

[@MaximChistov]

Вот это круто) Никогда ничего такого не было бы возможно в не опенсорс софте

[@MaximChistov]

Я про нахождение и исправление ошибки в самой ОС, если что…

[@ildarz]

«Такое» (исправление ошибок в софте при совместной работе вендора оборудования и производителя софта, иногда с вовлечением клиента) в проприентарном софте происходит столько, сколько вы на свете не живете, судя по вашему профилю.

[@MaximChistov]

То есть Microsoft на ваш взгляд так же легко отдает исходники винды всем, у кого странные проблемы с ней?

[@CodeRush]

Большая часть проблем с оборудованием в любой приприетарной ОС решается засылом этого оборудования производителю ОС и дальнейшей совместной отладкой. Так делают все крупные игроки, и Intel, и MS, и WindRiver, и все остальные. Если вам действительно нужно и у вас контракт на тех. поддержку подписан давно и надолго — коммерческие компании вас один на один с проблемой не оставят.
Исходники никто не раздает, т.к. разбираться в них инженеры разработчиков железа не обязаны и не будут — они в нем не понимают ничего, в отличие от тех, кто его писал и поддерживает. Понятно, что сначала заставят прогнать тесты Hardware Certification Kit'а, потом будет пару недель переписки из серии «попробуйте выключить и включить», но по итогу все проблемы, которые были у нас поддержкой оборудования со стороны MS удалось успошно решить.

[@poxvuibr]

Это, понятное дело, если у вас уже давно и очень долго есть деньги на подписание контракта на техподдержку. Много денег.

[@Mixalych]

Бред сивой кобылы. Сорри, но по-другому сказать — язык не поворачивается. Зачастую коммерческий софт написан… хотя, код закрыт. Я видел несколько корпоративных продуктов, код там до ужаса неадекватный. Конечно, далеко не у всех. А опенсорс — его смотрят тысячи, тут в любом случае код причесывается. Да и народ охотно поддерживает все опенсорсное. «Не опенсоср» — там, как правило, все очень и очень медленно исправляется, причем, в прямо-пропорциональной зависимости. Чем дороже продукт, тем больше клали на ваше «хочу». Ну кроме тех, кто за монету может все исправить дабы не потерять репутацию.

Это мое имхо.

[@rinat_crone]

Фраза «моё имхо» – самое маслянистое из всех маслянистых масельных масел. ИМХО.

[@Mixalych]

Согласен, каюсь. Без сарказма.

[@newdya]

Нет, самое масло это «по моему скромному имхо» или «в этом ITT треде».

[@kingpin]

IT-технологии — моё любимое.

[@Aquahawk]

АвтоВаз

[@youROCK]

драйвер SCSI/SATA не предполагает что разные запросы могут использовать одну область памяти и перезаписывает содержимое по адресу, указанному в bio_vec

А это вообще законно для драйвера? Переписывать содержимое памяти, которое ему дают на вход.

[@KawaiDesu]

Подразумевается память на диске. А как ещё? Драйвер должен быть оракулом и сам догадаться по какому адресу потребовать у диска затереть данные?

[@lovecraft]

Ну, драйвер справедливо полагает, что раз запрос спустился на его уровень, то с памятью запроса можно делать что угодно.

[@youROCK]

Может, я что-то неправильно понял? Например, давайте посмотрим на системный вызов write(int fildes, const void *buf, size_t nbyte) — ему на вход дают указатель на буфер buf, из которого нужно взять данные для записи в файл. Я лично не могу представить себе ситуацию, когда в этот буфер будет что-нибудь записано операционной системой, «потому что это её буфер». Грубо говоря, вы можете спокойно разделять этот буфер с другими системными вызовами и не беспокоиться о сохранности данных. Почему для драйвера не используется тот же самый подход?

[@lovecraft]

В объявлении write() указатель const void *buf константный, что в какой-то мере защищает его от случайных изменений, а вот как объявлена функция драйвера, которая меняет содержимое в bio_vec — большой вопрос. А вообще, вопрос интересный: то что у нас драйвер меняет данные в команде — еще не худший вариант. Например данные, которые пишутся на диск, могут быть изменены извне в процессе исполнения диском команды записи. Процитирую уважаемого amarao:

В линуксе давным-давно идёт срач на тему персистентных страниц при записи. Другими словами, «можно ли писать в грязные страницы». Срач типовой для подобной ситуации — одних ужасает, что данные могут меняться в середине записи (и записываться непонятно как), других ужасает то, как дорого и медленно выглядит решение проблемы.

[Решение: полный отказ от кешей на запись любого уровня и переход на ssd].

при этом на lvm.net считают дефект чисто косметическим.

[@Mithgol]

Этот комментарий стёрт, потому что тег <twitter> на Хабрахабре глючит и результат работы его непригляден.

[@aml]

Воистину, преждевременная оптимизация — корень всех зол.