е знаю правда или нет, но когда появился стандарт сата и первые диски, sun приехал на выставку и анонсировал свои системы хранения данных, построенные на solaris-e и zfs, ну и на дисках сата. Стандарт считался сырым, глючным и ни один нормальный админ не готов был доверять ему диски.
Все были одеты в футболки с надписью - мы любим сата. Я использую зфс с фри 8.0, когда он там только появился. Используются сервера на обычном десктопном железе, их больше десятка, на примерно 25% отсутсвуют упс-ы, установлены могут быть где угодно - ни одного в гермозоне. Проблема была один раз - виновата была мертвая планка памяти. 25 июня 2017 г., 2:29 пользователь Sergey Matveev <[email protected]> написал: > *** artiom <[email protected]> [2017-06-25 00:21]: > >У вас прям по ZFS сплошные плюсы. > > Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов > от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы > консистентность данных была в порядке, то при записи вы обязаны сделать > атомарную запись всех stripe-ов на все диски. А сделать это атомарно на > три (или более) аппаратных диска просто невозможно. Внезапное выключение > питания запросто приведёт к тому что на каком-то диске что-то > недозаписано. И встаёт проблема: кому доверять и как понять на ком > недочёт. Решают аппаратные контроллеры её за счёт использования памяти, > подпитываемой батарейкой (или SSD в контроллере), где хранится > информация о записанных данных. При восстановлении питания, он тогда > сможет понять что надо дозаписать. Но это хорошие дорогие контроллеры. > Программно так не сделать и при внезапном выключении питания вы сильно > рискуете реально потерять данные в stripe массива. С RAIDZ всё что > увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей > или нет. При пропаже питания вы безусловно рискуете потерять то что не > смогло быть чисто физически записано на диск, но никакого нарушения > целостности. То есть фича дорогих аппаратных контроллеров с батарейкой > или SSD на боту -- бесплатно в софте. > > -- > Sergey Matveev (http://www.stargrave.org/) > OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF > >
