Комментарии 24
Шикарно, пацаны! Молодцы и Angolia, и Samsung, и коммитеры Oracle/FB!
Вот это круто) Никогда ничего такого не было бы возможно в не опенсорс софте
Я про нахождение и исправление ошибки в самой ОС, если что…
«Такое» (исправление ошибок в софте при совместной работе вендора оборудования и производителя софта, иногда с вовлечением клиента) в проприентарном софте происходит столько, сколько вы на свете не живете, судя по вашему профилю.
То есть Microsoft на ваш взгляд так же легко отдает исходники винды всем, у кого странные проблемы с ней?
Большая часть проблем с оборудованием в любой приприетарной ОС решается засылом этого оборудования производителю ОС и дальнейшей совместной отладкой. Так делают все крупные игроки, и Intel, и MS, и WindRiver, и все остальные. Если вам действительно нужно и у вас контракт на тех. поддержку подписан давно и надолго — коммерческие компании вас один на один с проблемой не оставят.
Исходники никто не раздает, т.к. разбираться в них инженеры разработчиков железа не обязаны и не будут — они в нем не понимают ничего, в отличие от тех, кто его писал и поддерживает. Понятно, что сначала заставят прогнать тесты Hardware Certification Kit'а, потом будет пару недель переписки из серии «попробуйте выключить и включить», но по итогу все проблемы, которые были у нас поддержкой оборудования со стороны MS удалось успошно решить.
Исходники никто не раздает, т.к. разбираться в них инженеры разработчиков железа не обязаны и не будут — они в нем не понимают ничего, в отличие от тех, кто его писал и поддерживает. Понятно, что сначала заставят прогнать тесты Hardware Certification Kit'а, потом будет пару недель переписки из серии «попробуйте выключить и включить», но по итогу все проблемы, которые были у нас поддержкой оборудования со стороны MS удалось успошно решить.
Бред сивой кобылы. Сорри, но по-другому сказать — язык не поворачивается. Зачастую коммерческий софт написан… хотя, код закрыт. Я видел несколько корпоративных продуктов, код там до ужаса неадекватный. Конечно, далеко не у всех. А опенсорс — его смотрят тысячи, тут в любом случае код причесывается. Да и народ охотно поддерживает все опенсорсное. «Не опенсоср» — там, как правило, все очень и очень медленно исправляется, причем, в прямо-пропорциональной зависимости. Чем дороже продукт, тем больше клали на ваше «хочу». Ну кроме тех, кто за монету может все исправить дабы не потерять репутацию.
Это мое имхо.
Это мое имхо.
драйвер SCSI/SATA не предполагает что разные запросы могут использовать одну область памяти и перезаписывает содержимое по адресу, указанному в bio_vec
А это вообще законно для драйвера? Переписывать содержимое памяти, которое ему дают на вход.
Подразумевается память на диске. А как ещё? Драйвер должен быть оракулом и сам догадаться по какому адресу потребовать у диска затереть данные?
Ну, драйвер справедливо полагает, что раз запрос спустился на его уровень, то с памятью запроса можно делать что угодно.
Может, я что-то неправильно понял? Например, давайте посмотрим на системный вызов write(int fildes, const void *buf, size_t nbyte) — ему на вход дают указатель на буфер buf, из которого нужно взять данные для записи в файл. Я лично не могу представить себе ситуацию, когда в этот буфер будет что-нибудь записано операционной системой, «потому что это её буфер». Грубо говоря, вы можете спокойно разделять этот буфер с другими системными вызовами и не беспокоиться о сохранности данных. Почему для драйвера не используется тот же самый подход?
В объявлении write() указатель const void *buf константный, что в какой-то мере защищает его от случайных изменений, а вот как объявлена функция драйвера, которая меняет содержимое в bio_vec — большой вопрос. А вообще, вопрос интересный: то что у нас драйвер меняет данные в команде — еще не худший вариант. Например данные, которые пишутся на диск, могут быть изменены извне в процессе исполнения диском команды записи. Процитирую уважаемого amarao:
при этом на lvm.net считают дефект чисто косметическим.
В линуксе давным-давно идёт срач на тему персистентных страниц при записи. Другими словами, «можно ли писать в грязные страницы». Срач типовой для подобной ситуации — одних ужасает, что данные могут меняться в середине записи (и записываться непонятно как), других ужасает то, как дорого и медленно выглядит решение проблемы.
[Решение: полный отказ от кешей на запись любого уровня и переход на ssd].
при этом на lvm.net считают дефект чисто косметическим.
Этот комментарий стёрт, потому что тег <twitter> на Хабрахабре глючит и результат работы его непригляден.
Воистину, преждевременная оптимизация — корень всех зол.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Твердотельные накопители от Samsung оправданы. Проблема оказалась в ядре Linux