Свіже оновлення Windows 11 може паралізувати роботу SSD та HDD

[Ekz0rcyst]

Scoffer
А нащо тоді мета використовує цю fs?

[Scoffer]

Ekz0rcyst
А нашо мета використовує, хай простять боги, PHP? Бо як в тому анекдоті про лева. Бо може. Коли станете метою, тоді і почнете мірятись на неї.

Відправлено через 11 хвилин 3 секунди:
Перш за все для мети, а також гугли і всіх подібних сервісів основна маса даних це користувацькі дані, і вони для них не критичні. От прям взагалі нічого страшного не станеться для контори якщо частина даних зникне в невідомому напрямку. Скоріш за все навіть відновлювати не стануть, цитую:

To the fullest extent permitted by applicable law under no circumstance will we be liable to you for any lost profits, revenues, information, or data, or consequential, special, indirect, exemplary, punitive, or incidental damages arising out of or related to these Terms or the Meta Products (however caused and on any theory of liability, including negligence), even if we have been advised of the possibility of such damages.

А задедуплікувати всіх котиків в одного всяко економно. Ви теж тримаєте у себе сто тишь однакових картинок на харді і не сильно страждатимете коли вони пропадуть? Тоді так, має сенс. Хоча VDO все одно надійніше і production ready.

Відправлено через 40 хвилин 48 секунд:

Хоча VDO все одно надійніше і production ready.

Ймовірно мета почала коли VDO ще тільки зароджувався, а в btrfs воно вже якось фуричило. Проблема в тому що в btrfs фуриче все ще якось, а VDO вже більш-менш стабільне рішення. А тому що не треба натягувати сову на глобус, юнікс-вей де кожний компонент робить лише одне, зато робить його добре не самі дурні люди вигадали.

[Ekz0rcyst]

Scoffer
Без образ, але на відповідь це мало схоже.
"Коли станете метою, тоді і почнете мірятись на неї."? Дитячий садок.

[Scoffer]

Ekz0rcyst
Це від абсолютного нерозуміння масштабів і можливостей контори. Я недаремно навів приклад пхп. Подивись що вони з пхп зробили, так від нього одна лише назва, та і то частково. З оригінальним інтерпритатором от взагалі немає нічого спільного. Те ж саме амазон зробив з постгре, котрий крутить у себе в хмарах, і котрий тільки зовнішнім інтерфейсом походить на оригінал а під капотом працює зовсім не так. У тебе є кілька тишь розробників, котрим можна поставити дурні завдання? Немає? Ну жо ж, коли з'являються то тоді і почнеш мірятись на них. А зараз треба мірятись на те що надають вендори з інтеграторами як готові рішення для корпоратів. І бажано не ті що з'явились вчора, а котрі років 10 вже відстоялись.

[nazar-pc]

Scoffer
А нащо тоді мета використовує цю fs?

Якщо правильно пам'ятаю з презентацій, вони активно використовують знімки файлової системи, і по суті використовують це для деплою ПЗ, як один з прикладів використання.
З тим же Docker, наприклад, різні шари в образі контейнера можуть зберігатися як знімки файлової системи при відповідній конфігурації замість городити багатошаровий бутерброд з overlayfs або подібного.

[l-m]

Оно XFS і то вистачає в 99.(9)% випадків, а вона погірше за NTFS буде.

Вона не гірша за NTFS.
У неї є своя спеціалізація, і це висока швидкодія.
XFS як високопродуктивна ФС, для чого її розробляли, архітектурно чудова.
Вона як була 30 років тому найшвидшою при роботі з величезними обсягами даних, так і залишається досі. Бо те, що було добре для серверів з великими дисковими масивами, прекрасно підійшло для сучасних багатоядерних десктопів з новими SSD.
Користувачі Віндовс, які безальтернативно сидять на застарілій NTFS, того не зрозуміють, але у серед UNIX/Linux файлових систем висока конкуренція, їх багато та вони постійно розвиваються. Тому це справжнє досягнення розробників, що XFS, без серйозних змін, через десятки років, досі може показувати найкращу швидкодію.

[Scoffer]

l-m
Ствердження засноване на замірах через fuse? Наразі не існує жодного методу порівняння цих двох фс в однакових умовах.
А щодо продуктивності то страйп на рівні FS (allocation groups) ніяк не пришвидшує одиночні накопичувачі, навіть навпаки, так що до ссд тут ніяким боком від слова зовсім, це до рейдів, та і то далеко не всих. До того ж це не ультиматична фіча XFS, наприклад всі варіації EXT її теж мають, і шо, кому з того легше?

Відправлено через 13 хвилин 3 секунди:
NTFS, створена командами з MS i IBM в 93му - застаріла фс
XFS, створена напівдохлою на той час SGI в 94му і ледве доведена до продакшн реді стану десь в 2014му - свіжак і топ
Ох вже ці фантазери

[Alligator]

А можна піти далі, давати і відбирати права на запуск софту на рдп-фермах, хоча про що це я, який рдп в лінуксі))) Чи навіть просто права на локальний запуск софта з мережевої шари.

RDP в лінуксі то xRDP, але якщо задача не робити пародію вінди то краще VNC.

[Scoffer]

Справедливості заради XFS колись дуже давно мала спеціальне апі для QoS і це було реально круто, аналогів я не знаю. Але ця фіча жодну секунду часу не працювала на лінуксі, це виключно IRIX-тема. Я тому не раз вже казав що лінукс занапастив половину того що вміли юнікси.

Alligator
VNC це зовсім з іншої опери.

[Alligator]

VNC це зовсім з іншої опери.

Чому? Віддалений доступ - віддалений доступ, за замовчування у Linux Mint коли xRDP треба ставити, але простіше використовувати саме для віддаленого робочого столу вінду та не парити мізки, а для разових підключень можно енідеск без встановлення бо тімвьювер потребує суміжних версій на ПК.

[Alexsandr]

Лол, звичайно користуються. ZFS на NASах кругом як в користувацьких, так і професійних сетапах, у Meta вся інфра на btrfs. Але CoW всі дефективні та нестабільні
Колись років 15 тому може так і було, але сьогодні це не так.

Мета может позволить себе вносить изменения в систему оставляя просто имя. ZFS работает, но в тестах (давно было) себя не оправдала. Несколько раз приходилось подымать, не выдержала бедняга то ли отключения питания неожиданного то ли еще чего-то. В общем забросил ZFS пока опять не попадется возможность тестить.

[Scoffer]

Чому?

Тому що VNC не породжує нові сеанси, а захоплює екран і клавомишу.
Найближчий нативний аналог RDP в ніксах це запуск X-клієнта на віддаленому компі і підключення до X-сервера.

Відправлено через 3 хвилини 35 секунд:
По VNC не може 100500 юзверів працювати на одному сервері. По RPD може. По Х теж може, але піднімати їх на віддалених машинах з доступом по мережі це прям для гурманів

[Shpoker]

По VNC не може 100500 юзверів працювати на одному сервері.

100500 - без бубна не может, но вот 100 - вполне (99 виртуальных + 1 на :0 ), оперативки и сети б хватило)), более того, внц сессию можно шарить и прямо вдвоём одновременно двигать мышу и писать код в 4 руки))

[Alligator]

Scoffer Можна запустити по одній ізольованій графічній сесії для кожного користувача поки вистачить ресурсів, але ми обидва вже самі собі відповіли. Нащо воно на лінуксі в якості віддаленої машини для 100500 користувачів коли є вінда?

[SergiusTheBest]

RDP в лінуксі то xRDP, але якщо задача не робити пародію вінди то краще VNC.

xRDP мені не сподобався (якийсь дуже повільний), а от gnome-remote-desktop працює ідеально, але потрібен wayland.

Відправлено через 5 хвилин 28 секунд:

Я сподівався Microsoft нарешті змінять NTFS на ReFS або щось подібне, бо дуже вже стара архітектура в неї, купа сучасних функцій відсутня, а те що є працює дуже так собі.
Наприклад, коли алокувати повний файл на диску і почати запис десь біля кінця, ext4, btrfs та будь-яка сучасна файлова система фізично записує лише той блок під кінець файлу.
А NTFS починає заповнювати нулями файл від початку аж до місця запису, що у випадку файлу в кілька терабайт (з таким працює ПЗ яке я підтримую) виглядає для користувача як залипання всього що торкається того диска на багато годин зі 100% активністю диску. Windows навіть вимкнутись не може в такій ситуації поки запис нулів не завершиться.

ReFS гірша за NTFS з усіх сторін: полвільна, споживає багато пам'яті, має менші можливості. Є сенс використовувати тільки на серверах з дуже великими дисками. Стосовно заповнення файлу нулями - це проблема софта, бо NTFS вміє заповнювати або не заповнювати залежно від того, як софт то попросить.

Відправлено через 2 хвилини 1 секунду:

Создал бы уже кто-то достойного конкурента этой винде.

Linux Mint.

[0kie]

Тему как всегда утопили в демагогии и обычной болтовне. Минусаторы тоже отличились и моё предыдущее сообщение яростно так заминусили.
А между тем "проблему" не могут воспроизвести ни Майкрософт, ни Phison. Они приняли к сведению, что она вполне себе возможна и выпустили официальное заявление, где указали своё стремление докопаться до истины. Которой нет. Она основана исключительно на вбросе забугорного писателя иероглифами. На Реддите тоже напихали любителям разносить фейки по планете, где НИКТО так и не смог воспроизвести проблему.
Ну а вы все продолжайте тут писать всякую чушь - это же так весело! За минусы не забывайте - это же так умно и отважно - поставить дизлайк сообщению! Вместо того, чтобы пройти по первоисточникам, глянуть на официальные заявления и реакцию всех реально заинтересованных корпораций и сделать правильный вывод - это всё очередной вброс. Ну да, для этого вывода надо думать... Было бы чем... Писатели....

[gast_]

Наприклад, коли алокувати повний файл на диску і почати запис десь біля кінця, ext4, btrfs та будь-яка сучасна файлова система фізично записує лише той блок під кінець файлу.

Так і уявляю типового користувача, який "алокує повний файл на диску в починає запис десь біля кінця".

[nazar-pc]

Наприклад, коли алокувати повний файл на диску і почати запис десь біля кінця, ext4, btrfs та будь-яка сучасна файлова система фізично записує лише той блок під кінець файлу.

Так і уявляю типового користувача, який "алокує повний файл на диску в починає запис десь біля кінця".

Типовий користувач запускає софт який я написав, а потім скаржиться що у нього:
* програма зависла і не показує ніякого прогресу вже 6 годин
* хоча диск має 100% утилізацію весь цей час
* провідник зависає при спробі відкрити той диск
* майже закінчиласа оперативна пам'ять
* програму не можливо закрити ніяким способом, навіть вбити через диспетчер задач
* при спробі перезавантаженні Windows теж зависає і допомагає лише витягання кабелю з розетки

Все це тому що нулі пише драйвер і не може зупинитися поки не завершить запис, навіть вимкнення операційної системи йому не указ. І все що торкається цього диска стає в чергу та успішно зависає теж чекаючи завершення запису.
От уявіть собі що у користувача 8Т диск, а запис відбувається на швидкості 100 МБ/с (опуститись до такої швидкості і навіть нижче не рідкість при запису терабайтів на SSD).

От і доводиться виясняти що за дурню Windows чудить і що з цим можна зробити. І конкретно з записом в кінці файлу зробити не можна нічого крім не писати там, що створює проблеми з продуктивністю в іншому місці бо невикористане місце в кінці файлу використовується як тимчасовий кеш для даних що завантажують з Інтернету, і відключення цього кешу сповільнює роботу за радикально збільшує споживання трафіку і залежність від якості Інтернет-з'єднання.

Один з обхідних шляхів це дробити файл на менші для обмеження масштабу цього ідіотського перезапису нулями, але це вимагає зміни архітектури додатку.

Ось вам трошки інсайдів як страждають розробники що пишуть софт з підтримкою Windows, і таких приколів розкидано щедро по різним API цієї чудової операційної системи.
Звичайним користувачам цього не видно і все що працює погано під Windows (але не Linux чи macOS) це вина розробника, і я їх, в принципі, розумію.
Навіть при тому що по факту це безглузді обмеження операційної системи, а в даному випадку стандартної (фактично безальтернативної) файлової системи.

Відправлено через 10 хвилин 31 секунду:

Стосовно заповнення файлу нулями - це проблема софта, бо NTFS вміє заповнювати або не заповнювати залежно від того, як софт то попросить.

Не вміє, в NTFS архітектурно відсутня можливість не заповнювати нулями (не розріджені) файли, вона не вміє інакше, читайте відповідь від інженера Microsoft на моє питання якщо не вірите: https://stackoverflow.com/a/78369148/3806795

[Scoffer]

nazar-pc
Не кожен інженер майкрософту однаково корисний. Права адміністратора звісно що не потрібні, потрібні права SeManageVolumePrivilege, котрі надаються майже одноіменою груповою політикою. Бази даних і бекаперські системи чудово вміють з ними працювати, як приклад. Пересічному користувачу це нафіг не потрібно.
Тим часом fallocate() теж не без проблем. Зненацька, він вимагає ініціалізації кожного блоку при першій взаємодії з ним, і також буде забивати його нулями. Так що прога сумарно витратить рівно той же час що і традиційне створення файлів, просто не одразу, а розмазано. Тому там тобі в відповідях і написали що не знайшли профіту в бізнес-завданнях бо його немає, від перестановки доданків сума не змінюється.
Обхідні шляхи в вигляді FALLOC_FL_NO_HIDE_STALE (здається досі не включений в ядро, хоча активно юзається гуглом, але це не точно) призводять до рівно тих же проблем з безпекою що і надання SeManageVolumePrivilege.
А хто сказав що все буде просто?

Відправлено через 12 хвилин 56 секунд:
Хоча ні, не до тих же, до більших. В лінуксі на даний момент не можна нарізати права так тонко, як в ОС, котрі протягнули ACL через всю систему і увесь софт.

[nazar-pc]

nazar-pc
Не кожен інженер майкрософту однаково корисний. Права адміністратора звісно що не потрібні, потрібні права SeManageVolumePrivilege, котрі надаються майже одноіменою груповою політикою. Бази даних і бекаперські системи чудово вміють з ними працювати, як приклад. Пересічному користувачу це нафіг не потрібно.
Тим часом fallocate() теж не без проблем. Зненацька, він вимагає ініціалізації кожного блоку при першій взаємодії з ним, і також буде забивати його нулями. Так що прога сумарно витратить рівно той же час що і традиційне створення файлів, просто не одразу, а розмазано. Тому там тобі в відповідях і написали що не знайшли профіту в бізнес-завданнях бо його немає, від перестановки доданків сума не змінюється.
Обхідні шляхи в вигляді FALLOC_FL_NO_HIDE_STALE (здається досі не включений в ядро, хоча активно юзається гуглом, але це не точно) призводять до рівно тих же проблем з безпекою що і надання SeManageVolumePrivilege.
А хто сказав що все буде просто?

Я дуже добре знаю специфіку додатку що розробляю і досить непогано розуміюся на тому як влаштовані всередині сучасні SSD та трошки як працюють файлові системи.

Додаток не читає нічого того, що попередньо не записав, і пише дані максимально оптимальним для SSD чином. Тому ніякого запису нулями не відбувається на скільки-небудь суттєвому масштабі.
Він пише дані послідовно блоками в ~1ГБ за раз в файл від початку і до кінця, роблячи величезну кількість обчислень між записами (тому записи відбуваються паралельно з обчисленнями наступної порції даних).
Кінець файлу тимчасово використовується як кеш з куди пишуться ~1 МБ блоки, починаючи запис з кінця і рухаючись в напрямку початку файлу.
Коли кеш і основні дані зустрічаються, результати починають поступово затирати кеш поки файл не складається на 100% з результатів обчислень.

Все організовано так, що write amplifiction на практиці прямує до нуля.

І з fallocate() такої проблеми немає, я знаю що і для чого використовую

Дуже цікаво буде подивитися як користувач буде крутити групові політики щоб скористатися додатком
Тим більше SetFileValidData є фундаментально небезпечним API, що при читанні надає доступ до даних що там зберігалися до цього. Давати додаткам доступ до такого без крайньої необхідності є поганою ідеєю та шкідливою порадою.

P.S. Нагадую що згадування логіну жирним текстом не генерує сповіщення і ніколи його не генерувало на цьому форумі, тому для продовження дискусії краще все-таки використовувати цитування повідомлень.