Size: a a a

2019 November 11

S

Stanislav in uptime.community
А вот завязка сюжета. Для тех, кто не может чуточку отскроллить назад.
источник

S

Stanislav in uptime.community
источник
2019 November 12

GM

Gleb Mekhrenin in uptime.community
Stanislav
сервер времени RU ntp.psn.ru врёт на 1799 секунд.
Попадало море сервисов , завязанных на него.

эксперты ... только вот уже дошло до нерабочих таймсерверов :)

блин - это же просто ПОЗОРИЩЕ!
никогда такого не было и вот опять. ждем на харбе статей на тему "миллениалы узнали как работает ntp"?
источник
2019 November 16

SM

Sergey Mutin in uptime.community
источник
2019 November 26

S

Stanislav in uptime.community
Ошибка в прошивке SSD-накопителей HPE, приводящая к потере данных через  32768 часов работы https://opennet.ru/51934/
источник

VS

Vladimir Smirnov in uptime.community
прелестно
источник

S

Slach in uptime.community
хехе, я кстати за последнее время насмотрелся на то, как эти ошибки появляются при разработке
источник

S

Slach in uptime.community
не знаю как теперь с этим жить ;(
источник

C

Constantine in uptime.community
источник

VS

Vladimir Smirnov in uptime.community
Slach
не знаю как теперь с этим жить ;(
постоянно молится
источник

AZ

Andrey Zavada ITSumma in uptime.community
HP, Crucial, Intel
надеюсь остальные посмотрять diff или займутся  усебя поиском аналогичных ошибок
источник

VR

Vadim Rybalko in uptime.community
Можно просто менять накопители через каждые 32767 часов работы.
источник

S

Slach in uptime.community
Andrey Zavada ITSumma
HP, Crucial, Intel
надеюсь остальные посмотрять diff или займутся  усебя поиском аналогичных ошибок
Друг, ты не очень хорошо представляешь как устроена эта индустрия и какая там конкуренция

никто никакой diff смотреть не будет, просто потому что там по этому diff нихрена не понятно, там кумулятивно там дофига всего может прилететь

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

поиском "аналогичных проблем" все вендоры занимаются перманентно, наверное в этой индустрии кол-во независимых qualification и тестов, просто овердохрена

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

S

Slach in uptime.community
а причины кроются в том факте, что современные диски, по факту, ничего не хранят, точнее очень хорошо претворяются что что-то куда то записали,
постоянно размазывая данные тонким слоем на перманентно деградирующей NAND ;)
и потом это что-то через коды коррекции и через кучу всяких физических уловок достали
источник

S

Stanislav in uptime.community
Slach
а причины кроются в том факте, что современные диски, по факту, ничего не хранят, точнее очень хорошо претворяются что что-то куда то записали,
постоянно размазывая данные тонким слоем на перманентно деградирующей NAND ;)
и потом это что-то через коды коррекции и через кучу всяких физических уловок достали
👍
источник
2019 November 27

S

Slach in uptime.community
Slach
Друг, ты не очень хорошо представляешь как устроена эта индустрия и какая там конкуренция

никто никакой diff смотреть не будет, просто потому что там по этому diff нихрена не понятно, там кумулятивно там дофига всего может прилететь

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

поиском "аналогичных проблем" все вендоры занимаются перманентно, наверное в этой индустрии кол-во независимых qualification и тестов, просто овердохрена

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

VS

Vladimir Smirnov in uptime.community
Slach
Друг, ты не очень хорошо представляешь как устроена эта индустрия и какая там конкуренция

никто никакой diff смотреть не будет, просто потому что там по этому diff нихрена не понятно, там кумулятивно там дофига всего может прилететь

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

поиском "аналогичных проблем" все вендоры занимаются перманентно, наверное в этой индустрии кол-во независимых qualification и тестов, просто овердохрена

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

AN

Anton Noginov in uptime.community
Slach
имитировать это где то "на симуляторе" или даже в физической лабе невозможно...
а автопроме даже наработка на отказ тоже не делается на реальное кол-во часов
Справедливости ради - этом конкретном случае цифра 32768 наводит на мысль, что бангалорский селянин, писавший прошивку, жахнул signed вместо unsigned. Что должно было отловится делевянным юнит-тестом.
источник

S

Slach in uptime.community
Anton Noginov
Справедливости ради - этом конкретном случае цифра 32768 наводит на мысль, что бангалорский селянин, писавший прошивку, жахнул signed вместо unsigned. Что должно было отловится делевянным юнит-тестом.
без обид, я сам когда то такие выводы делал

нет, на самом деле в этом случае после 32768 часов работы например   могла какая нибудь служебная SLC область тупо перетереться слишком большое кол-во раз и после любого ребута тупо не получилось бы таблицу соответсвия Где там на флешке ваши данные физически
в SRAM памяти контроллера восстановить...
диск при этом рабочий, только "данные утеряны"
источник

AN

Anton Noginov in uptime.community
Все может быть.
источник