T5500 и 9650SE RAID

[Sergey Kubushyn]

В-общем из-под 25-й Федоры сполняет как из ружжа, любо-дорого посмотреть.
RAID настоящий железный, т.е. линух видит RAID как единичный диск, типа
/dev/sda. SMART отдаёт на каждый отдельный диск, только надо правильно
спрашивать :) Умеет много всякого и разного. Кому если вдруг надо чтоб
на сверхзвуке с сумасшедшими SSD, ищите что-то другое -- 9650SE умеет
только SATA 1/2, 3 оно не может. Для ширпотребных дисков этого достаточно
за смешные деньги. Если же сильно надо SATA 3, то это уже на порядок
дороже.

Мелкий хинт про батарейку -- она по умолчанию отключена принудительно,
т.е. никакие манипуляции с контроллером её не включат. Из его BIOS ту
батарейку (BBU, Batery Backup Unit) включить нельзя (при этом включить
Write Caching можно :)).

Для того чтоб, надо установить её утилиты, для линуха последняя версия
3DM2_CLI-linux_10-2-2-1_9-5-5-1.zip. Оно несколько braindead (zip, в зипе
tgz и install.sh, при этом тот install.sh для федоры надо немного пилить
руками потому как оно ищет версию дебиана и кое что ещё), но будучи
водружённым сполняет вполне нормально и даже знает про systemd и ставится
в разумное место.

Утилиты есть и под виндюк, так что если кто вдруг то таки тоже да. Чтобы
включить батарейку надо из командной строки её утилиты twl_cli сказать
"/cX/bbu enable" где X это номер контроллера, который можно узнать из
той же утилиты. После этого батарейка включается и всё начинает работать.

Дата включения считается датой установки батарейки (записывается где-то
в потроха того контроллера) и батарейка считается совсем пустой (Estimated
Backup Capacity равно нулю). Для того, чтоб всё было путём, надо сполнить
той батарейке тест чтобы контроллер оценил на что она способна. Тест можно
пустить и из twl_cli из работающей системы, и из уебинтерфейса, и прямо из
BIOS. Сполняется он всего ничего -- 24 часа :) После того контроллер знает
сколько он может продержаться на той батарейке.

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

Очень хорошая штука за десятку баксов, просто так не бывает...

---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************

[Roman N]

Sergey Kubushyn wrote on 28/12/2016 24:45:

> Включение батарейки приводит к задержке во вскипании контроллера -- он с
> батарейкой замирает секунд на 30-40 в состоянии "Initializing...",
> проверяет не осталось ли чего в кэше прежде чем побежать.
>
> Очень хорошая штука за десятку баксов, просто так не бывает...

А зачем это все когда есть zfs?

[Slawa Olhovchenkov]

Roman N <datai...@gmail.com> wrote:

RN> А зачем это все когда есть zfs?

на линуксе с zfs всё непросто

--
Slawa Olhovchenkov

[Sergey Kubushyn]

И бздя.

К нам сегодня приходил
некропедозоофил...

Намёк: кроме сисадминов и датацентров бывают и другие.

=== Cut ===
[ksi@maverick ~]$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11
processor : 12
processor : 13
processor : 14
processor : 15
processor : 16
processor : 17
processor : 18
processor : 19
processor : 20
processor : 21
processor : 22
processor : 23
[ksi@maverick ~]$
=== Cut ===

И 352 куды с 320-битным интерфейсом к памяти если кому вдруг посчитать
чего всерьёз :) Quadro 5000.

[Chapai]

"Sergey Kubushyn" <k...@koi8.net> wrote in message
news:o3vu46$1n1q$1...@ddt.demos.su...

> Мелкий хинт про батарейку -- она по умолчанию отключена принудительно,
> т.е. никакие манипуляции с контроллером её не включат. Из его BIOS ту
> батарейку (BBU, Batery Backup Unit) включить нельзя (при этом включить
> Write Caching можно :)).

зачем они это сделали? я тоже протрахался.

> Очень хорошая штука за десятку баксов, просто так не бывает...

Я сравнил с Perc 6/i. Был он у меня.

у 3ware быстродействие чотко 2.5gb/s, у perc 1.10 среднее 1.5 в пике.
Причем perc был с SSD у которых 6 гигабит.
И у перка оно как размашистая пила, на чтение. У 3ware поровнее.

Перк отправится на ибей вместе со всеми шлангами.
SSD на мамин рейд в зеркало, от интеля, коий эта мамка поддерживает, если
включить SATA Raid on в BIOS.
Заодно узнал как сделать чтоб винды не сжирали сто мег при установке,
впустую. Сто гиг при такой памяти - это впритык.

c 3ware дело оказалось в проводах - они были не той системы.
Новые китайские голубые в оплетке - более чем превосходны и очень аккуратны
и тонки. 50 сантиметровых (19") хватает с запасом.

А я наверно заряжу все же RAID6 - выну BDRW и поставлю на внешний USB3
(карточек есть на ибее за копейки -наконец я нашел зачем он и нужны). А
eSata на бэкап с оригинальным двухтерабайтником от хитачи.

Внутрь еше два диска в довесок 4 HDD. Кажется нашел подходящий mount bracket
подешевле, а вентилятор заменю на делловый HDD fan.
На ибее есть странная штука caddy с ним. Неясен лишь габарит - документации
не могуй найти.
Если суметь понять какого он размера - и на нем и смонтирую bracket.
Хотя его и самому было бы дешевле сделать из железного листа.

Кстати диски WD RE4 замечательные - умеют крутиться с разной скоростью и
очень тихо. и по 64 мега кэша на тушке и кажется 3ware его не тушит.

Надо еще поглядеть как работает кнопка питания и можно ли ее вывести наружу
на веревочке- задействовав тот же микрофонный разъем.
тогда все под стол и забыть на века.

[Roman N]

Sergey Kubushyn wrote on 28/12/2016 23:50:
> Roman N <datai...@gmail.com> wrote:
>> Sergey Kubushyn wrote on 28/12/2016 24:45:
>>
>>> Включение батарейки приводит к задержке во вскипании контроллера -- он с
>>> батарейкой замирает секунд на 30-40 в состоянии "Initializing...",
>>> проверяет не осталось ли чего в кэше прежде чем побежать.
>>>
>>> Очень хорошая штука за десятку баксов, просто так не бывает...
>>
>> А зачем это все когда есть zfs?
>
> И бздя.
>
> К нам сегодня приходил
> некропедозоофил...

Вот именно эти "контроллеры" со свалки...

[Dmitry Krivitsky]

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

[Chapai]

"Dmitry Krivitsky" <kr...@fido.fw.nu> wrote in message
news:o47538$tt3$1...@dont-email.me...

Прелесть старых игрушек - что они сделаны были для заводов и пароходов,
стоили бешеные тыщщи и были отлично изготовлены.
А теперь,в силу странностей прогресса и американской тяги к обновлению,
доступны за гроши, и кроют личные потребности как бык овцу. Предоставляя
невиданные возможности.
А в сисадмины нам не надо - эвон я передачу смотрел, как в жаркой стране
фермеры выращивают какао. Растят, собирают, обрабатывают и отправляют куда
то. А вкуса шоколада не знают. Им впервые оператор дал попробовать по
кусочку - что выходит из их какао-бобов.


Кстати, давно хотел спросить - у тебя какое хобби?

[Dmitry Krivitsky]

On 12/30/2016 9:43 PM, Chapai wrote:
>
> "Dmitry Krivitsky" <kr...@fido.fw.nu> wrote in message
> news:o47538$tt3$1...@dont-email.me...
>> On 12/30/2016 2:37 PM, Roman N wrote:
>>> Sergey Kubushyn wrote on 28/12/2016 23:50:
>>>> Roman N <datai...@gmail.com> wrote:
>>>>> Sergey Kubushyn wrote on 28/12/2016 24:45:
>>>>>
>>>>>> Включение батарейки приводит к задержке во вскипании контроллера
>>>>>> -- он с
>>>>>> батарейкой замирает секунд на 30-40 в состоянии "Initializing...",
>>>>>> проверяет не осталось ли чего в кэше прежде чем побежать.
>>>>>>
>>>>>> Очень хорошая штука за десятку баксов, просто так не бывает...
>>>>>
>>>>> А зачем это все когда есть zfs?
>>>>
>>>> И бздя.
>>>>
>>>> К нам сегодня приходил
>>>> некропедозоофил...
>>>
>>> Вот именно эти "контроллеры" со свалки...
>>
>> Просто им всем надо переквалифицироваться в сисадмины. Тогда у них
>> будет достаточно (новых) игрушек на работе, и не будет потребности
>> покупать (старые) игрушки домой.
>
> Прелесть старых игрушек - что они сделаны были для заводов и пароходов,
> стоили бешеные тыщщи и были отлично изготовлены.

Новые игрушки - тоже сделаны для заводов и параходов и стоят бешеные тыщи.
Отлично изготовлены - ну, это уж как повезет, но отличий между новыми и
старыми в этом смысле нет.

> А теперь,в силу странностей прогресса и американской тяги к обновлению,
> доступны за гроши, и кроют личные потребности как бык овцу. Предоставляя
> невиданные возможности.
> А в сисадмины нам не надо - эвон я передачу смотрел, как в жаркой стране
> фермеры выращивают какао. Растят, собирают, обрабатывают и отправляют
> куда то. А вкуса шоколада не знают. Им впервые оператор дал попробовать
> по кусочку - что выходит из их какао-бобов.

А к сисадминам это какое отношение имеет?

> Кстати, давно хотел спросить - у тебя какое хобби?

В z1 писать. :-)

[Sergey Kubushyn]

... а лох платит всегда (с) народ.

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

Мы, старпёры, знаем что мухи должны быть отдельно от котлет. Перемешать
их никогда не поздно и намного легче чем выковыривать одних из других.

Я не хочу даже начинать совершенно глупого спора с теми, кто ничего
слаще морковки не видел и ничего, кроме прикручивания одной гайки на
конвейере, не делал и не умеет. Совершенно забесплатно, может дойдёт:
блочное устройство и файловая система вещи _абсолютно_ ортогональные.
Нормальные файловые системы могут жить на любых блочных устройствах и,
соответственно, любые блочные устройства могут нести на себе любую
файловую систему. Чтоб два раза не вставать, речь именно о _блочных_
устройствах и потому, например, лысый NAND требующий совершенно
специфической FS, которая, в свою очередь, не будет работать ни на чём
другом (YAFFS, UBIFS и иже) вспоминать не надо вообще потому что он _НЕ_
блочное устройство. И чудесная ZFS на нём тоже не побежит.

Твоя же чудесная ZFS пытается скрестить ежа и ужа из чего не получается
ничего кроме двух метров колючей проволоки.

Попробуй научить нас сирых как прикрутить к тому ZFS, например, седьмой
виндюк. Который прекрасно живёт на железном RAID'е со своим NTFS даже
и не подозревая о том.

Или как поставить на ZFS'ный RAIDZ коробочную федору. Если таки вдруг
удастся, попробуй рассказать как её забутить с того RAIDZ'а на ZFS. На
всякий случай вводная -- она прекрасно бутится с железного RAID'а со
свалки. Более того, она даже и не подозревает что она бутится с RAID'а.
Так же как и, например, виндюк. Расскажи, pls, как объяснить тому же
GRUB'у что оно более прогрессивное и с него таки надо бутиться.

Расскажи как создать образ системы на ZFS в файле чтобы тот файл можно
было потом тупо скопировать на сырое блочное устройство и получить
работающую OS. Как тот файл смонтировать как FS чтоб в него можно было
писать на предмет установки OS.

Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
исполняется по крону совершенно автоматически еженедельно (и с другими
уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
одной командой восстановить всю систему?

Как прочитать чего из той чудесной ZFS или записать туда чего из-под
U-Boot?

Я даже и не буду говорить про необходимую для него раму, необходимость
молотить всё тем же процессором, которым сполняется всё остальное (т.е.
RAID получается софтверный aka host-based) и многое-многое другое.
Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
процессором и с ограниченной рамой, причём одновременно.

Контроллеры же (без кавычек) "со свалки" прекрасно работают и сегодня. И
стоят копейки. И будут работать ещё очень долго. За те же копейки. И
с любой FS потому как железному контроллеру абсолютно монопенисуально
какая именно на него напялена FS. То есть совсем. Как и той FS абсолютно
фиолетово сполняет ли она на лысом диске или на железном RAID'е. Молоток,
правильно сделанный 100 лет назад, прекрасно исполняет свою функцию и
сегодня. А лох платит всегда...

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

[Slawa Olhovchenkov]

Sergey Kubushyn <k...@koi8.net> wrote:

SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
SK> исполняется по крону совершенно автоматически еженедельно (и с другими
SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
SK> одной командой восстановить всю систему?

ssh zfs send -r > host.dump

SK> Я даже и не буду говорить про необходимую для него раму, необходимость
SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
SK> RAID получается софтверный aka host-based) и многое-многое другое.
SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
SK> процессором и с ограниченной рамой, причём одновременно.

рамы и проца zfs нужно не больше чем другим fs

--
Slawa Olhovchenkov

[Sergey Kubushyn]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Sergey Kubushyn <k...@koi8.net> wrote:
>
> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
> SK> одной командой восстановить всю систему?
>
> ssh zfs send -r > host.dump

И восстановить на лысый диск тоже одной командой? А на диск другого размера?
А под виндюком?

А в файле образ создать с нуля? А смонтировать его и установить туда ОС
после чего его отмонтировать и тупо скопировать на блочное устройство чтоб
та ОС там взлетела? И так NNNN раз чтоб на конвейере могли pre-program
устройство чтоб оно будучи возбуждённым капой "Вкл." прямо само взлетало.
И чтоб без сисадминов, обычный штуцер на конвейере чтоб смог.

> SK> Я даже и не буду говорить про необходимую для него раму, необходимость
> SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
> SK> RAID получается софтверный aka host-based) и многое-многое другое.
> SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
> SK> процессором и с ограниченной рамой, причём одновременно.
>
> рамы и проца zfs нужно не больше чем другим fs

Йа-йа... А RAIDZ с его контрольными суммами, ECC и прочими чудесами
сполняет Пушкин Антон Семёныч. Сбоку и совершенно забесплатно. Без рамы
и не напрягая проца.

Авторы вон рекомендуют аж отдельный скоростной SSD под ейный кэш специально.

[Slawa Olhovchenkov]

Sergey Kubushyn <k...@koi8.net> wrote:

SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Sergey Kubushyn <k...@koi8.net> wrote:
>>
>> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
>> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
>> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
>> SK> одной командой восстановить всю систему?
>>
>> ssh zfs send -r > host.dump

SK> И восстановить на лысый диск тоже одной командой?

ну restore у тебя на лысый диск вообще работать не будет. ты ему сначала newfs сделай.
а так да -- одной коммандой.

SK> А на диск другого размера?

разумеется

SK> А под виндюком?

шо, под винюком у тебя dump/restore завелся?
или у тебя лялих с ntfs грузиться начал?

SK> А в файле образ создать с нуля? А смонтировать его и установить туда ОС
SK> после чего его отмонтировать и тупо скопировать на блочное устройство чтоб
SK> та ОС там взлетела? И так NNNN раз чтоб на конвейере могли pre-program
SK> устройство чтоб оно будучи возбуждённым капой "Вкл." прямо само взлетало.
SK> И чтоб без сисадминов, обычный штуцер на конвейере чтоб смог.

штуцер что угодно сломает, а если в скрипт завернуть -- то и разницы нет.

>> SK> Я даже и не буду говорить про необходимую для него раму, необходимость
>> SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
>> SK> RAID получается софтверный aka host-based) и многое-многое другое.
>> SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
>> SK> процессором и с ограниченной рамой, причём одновременно.
>>
>> рамы и проца zfs нужно не больше чем другим fs

SK> Йа-йа... А RAIDZ с его контрольными суммами, ECC и прочими чудесами
SK> сполняет Пушкин Антон Семёныч. Сбоку и совершенно забесплатно. Без рамы
SK> и не напрягая проца.

да. ты можешь теоретезировать, а я на реальных системах замеры производил и могу еще произвести.
при трансфере порядка 5ГБ/с с такой fs проца на нее тратится порядка пары процентов.

SK> Авторы вон рекомендуют аж отдельный скоростной SSD под ейный кэш специально.

а все остальный прикручивают соплями flashcache/blockcache/что-то еще и смотрят как бы добиться
хотя бы половины эффективности кеширования zfs

--
Slawa Olhovchenkov

[Chapai]

"Dmitry Krivitsky" <kr...@fido.fw.nu> wrote in message

news:o479c3$f7f$1...@dont-email.me...

Этот момент ключевой. Доступность.
Кстати в этой части для тебя лично доступности у новых нет.
Так то о чем ты пытаешься сказать , называется "станки, станки, станки.." а
я - об игрушках.

>> А в сисадмины нам не надо - эвон я передачу смотрел, как в жаркой стране
>> фермеры выращивают какао. Растят, собирают, обрабатывают и отправляют
>> куда то. А вкуса шоколада не знают. Им впервые оператор дал попробовать
>> по кусочку - что выходит из их какао-бобов.
>
> А к сисадминам это какое отношение имеет?

Ты как слесарь на заводе. а куда и зачем это мимо тебя.

>
>> Кстати, давно хотел спросить - у тебя какое хобби?
>
> В z1 писать. :-)

Не так чтоб много и пишешь - небось в стол, потомкам.
Но кроме того - неужели там крестиком не вышиваешь, или коктейли искусно
смешиваешь.
Чо дома то делать, если детей нет и неженат - телевизор зырить?

>

[Sergey Kubushyn]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Sergey Kubushyn <k...@koi8.net> wrote:
> SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>
>>> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
>>> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
>>> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
>>> SK> одной командой восстановить всю систему?
>>>
>>> ssh zfs send -r > host.dump
>
> SK> И восстановить на лысый диск тоже одной командой?
>
> ну restore у тебя на лысый диск вообще работать не будет. ты ему сначала newfs сделай.
> а так да -- одной коммандой.

Ну это да, если dump/restore. А если из образа то таки одной командой.

> SK> А на диск другого размера?
>
> разумеется
>
> SK> А под виндюком?
>
> шо, под винюком у тебя dump/restore завелся?

А почему бы ему и не завестись?

> или у тебя лялих с ntfs грузиться начал?

А это ещё зачем? Я говорил о копировании файловой системы.

> SK> А в файле образ создать с нуля? А смонтировать его и установить туда ОС
> SK> после чего его отмонтировать и тупо скопировать на блочное устройство чтоб
> SK> та ОС там взлетела? И так NNNN раз чтоб на конвейере могли pre-program
> SK> устройство чтоб оно будучи возбуждённым капой "Вкл." прямо само взлетало.
> SK> И чтоб без сисадминов, обычный штуцер на конвейере чтоб смог.
>
> штуцер что угодно сломает, а если в скрипт завернуть -- то и разницы нет.

Образ системы в файле оно умеет создать? Конвейер от датацентра с сисадминами
отличается очень сильно. А при массовом производстве сами накопители, будь то
диски или микросхемы вообще программируются их производителем ещё до установки
в систему. И никаких скриптов там нету, просто тупое копирование бинарного
файла на устройство.

>>> SK> Я даже и не буду говорить про необходимую для него раму, необходимость
>>> SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
>>> SK> RAID получается софтверный aka host-based) и многое-многое другое.
>>> SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
>>> SK> процессором и с ограниченной рамой, причём одновременно.
>>>
>>> рамы и проца zfs нужно не больше чем другим fs
>
> SK> Йа-йа... А RAIDZ с его контрольными суммами, ECC и прочими чудесами
> SK> сполняет Пушкин Антон Семёныч. Сбоку и совершенно забесплатно. Без рамы
> SK> и не напрягая проца.
>
> да. ты можешь теоретезировать, а я на реальных системах замеры производил и могу еще произвести.
> при трансфере порядка 5ГБ/с с такой fs проца на нее тратится порядка пары процентов.

Когда у тебя _один_ процессор с ограниченной рамой только на переключение
контекста уйдут далеко не единицы процента. Не говоря уже про ECC, сборку
из лоскутов и прочая. Естественно, оно не сильно проблема когда процессору
кроме перегрузки мануры из ФС в 100гигабитную сеть и наоборот больше и
заняться-то нечем. Но ты не поверишь, бывают и такие применения, где и ФС
и сеть просто иногда используемые элементы инфраструктуры и пропускная
способность сортира никого не волнует вообще -- туда если и ходят, то
только изредка и очень на недолго.

> SK> Авторы вон рекомендуют аж отдельный скоростной SSD под ейный кэш специально.
>
> а все остальный прикручивают соплями flashcache/blockcache/что-то еще и смотрят как бы добиться
> хотя бы половины эффективности кеширования zfs

А оно не нужно. Просто совсем. Кроме как в датацентрах. В инженерных
рабочих станциях большие объёмы и высокая скорость практически никогда
не требуются одновременно. Надёжность _хранения_ информации сильно
желательна, но для этого не нужно мешать мух с котлетами -- _любая_ ФС
на тривиальном RAID1 вполне надёжна. Повторю: _ЛЮБАЯ_ , в том числе и
NTFS, и HFS, и FAT32, и ext2/3/4, и что угодно ещё. Что позволяет
использовать любую привычную ОС. Выбор которой диктуется не тем есть ли
там чудодейственная ZFS, а бежат ли на ней нужные инженерные тулзы.

Если же нужна скорострельность, то обычно это скорострельность процессоров
а не файловой системы. А данные для тех процессоров находятся в раме,
которая по скорости доступа вставит _АБСОЛЮТНО_ любую ФС, даже самую
чудотворную, как бегемот лягушку. Потому как даже самая чудодейственная
ФС сначала должна доставить данные в память что есть 100% ненужные
расходы если данные исходно в памяти.

Я не спорю с тем, что ZFS с бздёй наверняка быстрее в датацентрах с
многоКАтерабайтами данных которые надо куда-то быстро-быстро отправлять
через 100гигабитные сетевые карты серверами с десятками процессоров и
многими гигабатайми рамы, которые сервера не заняты ничем другим кроме
отправки тех петабайтов через 100гигабайтные сетевые карты. Для такого
и бздя хороша.

Но это очень узкое применение, не имеющее никакого отношения к тому для
чего используют компьютеры инженеры. Как на работе на дядю, так и дома
для всяческих шабашек/хоббей/whatever. _НИКТО_ не строит дома датацентров
ни для каких целей, это лишено смысла. Всяких же CAD'ов и иже просто
навалом и это именно ими инженер зарабатывает на хлеб с маслом. И для
этого инструменты живут не под одной платформой -- вон у меня, например,
рядом стоит машина с седьмым виндюком. Такая же как и с линухом, T5500 с
12 ядрами и 72 гигами рамы :) Потому как требуемый заказчиками, например,
OrCAD/Altium/Eagle/AutoCAD/Solidworks/etc. под линухом не бежит потому
приходится его под виндюком поджигать. Если же вдруг какой-нинаебуть
Quartus/Diamond/CodeComposer, то его, естественно, под линухом. Хотя
последний приходится и под виндюком иногда пущать из-за старого PCIного
XDS560, который под линухом не поддерживают и который единственный кто
умеет делать Core Trace -- ни один из более новых, даже самых-самых
распальцованых, этого не умеет.

А под бздёй _ВООБЩЕ НИЧЕГО_ из того не бежит, потому она для инженерных
(и любых других практических за исключением датацентров) целей непригодна
вообще. То есть совсем. Вместе с чудотворной ZFS, которой только в тех
датацентрах и место.

[Slawa Olhovchenkov]

Sergey Kubushyn <k...@koi8.net> wrote:
SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Sergey Kubushyn <k...@koi8.net> wrote:
>> SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>>
>>>> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
>>>> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
>>>> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
>>>> SK> одной командой восстановить всю систему?
>>>>
>>>> ssh zfs send -r > host.dump
>>
>> SK> И восстановить на лысый диск тоже одной командой?
>>
>> ну restore у тебя на лысый диск вообще работать не будет. ты ему сначала newfs сделай.
>> а так да -- одной коммандой.

SK> Ну это да, если dump/restore. А если из образа то таки одной командой.

из образа в другой размер одной коммандой?
ты уж определись

>> SK> А на диск другого размера?
>>
>> разумеется
>>
>> SK> А под виндюком?
>>
>> шо, под винюком у тебя dump/restore завелся?

SK> А почему бы ему и не завестись?

да вот проблемки, особенно с dump

>> или у тебя лялих с ntfs грузиться начал?

SK> А это ещё зачем? Я говорил о копировании файловой системы.

эм. как бы файловая система она для того, что бы на ней работать.
в том числе и грузиться с неё
не, если у тебя работа в том, что бы копировать файловую систему...

>> SK> А в файле образ создать с нуля? А смонтировать его и установить туда ОС
>> SK> после чего его отмонтировать и тупо скопировать на блочное устройство чтоб
>> SK> та ОС там взлетела? И так NNNN раз чтоб на конвейере могли pre-program
>> SK> устройство чтоб оно будучи возбуждённым капой "Вкл." прямо само взлетало.
>> SK> И чтоб без сисадминов, обычный штуцер на конвейере чтоб смог.
>>
>> штуцер что угодно сломает, а если в скрипт завернуть -- то и разницы нет.

SK> Образ системы в файле оно умеет создать?

блять, какая нахуй разница если ты на лупбэк монтируешь?

SK> Конвейер от датацентра с сисадминами
SK> отличается очень сильно. А при массовом производстве сами накопители, будь то
SK> диски или микросхемы вообще программируются их производителем ещё до установки
SK> в систему. И никаких скриптов там нету, просто тупое копирование бинарного
SK> файла на устройство.

ага, руками, ни в коем случае не автоматизированно, да еще и с капчей, шоб робота не подсунули

>>>> SK> Я даже и не буду говорить про необходимую для него раму, необходимость
>>>> SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
>>>> SK> RAID получается софтверный aka host-based) и многое-многое другое.
>>>> SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
>>>> SK> процессором и с ограниченной рамой, причём одновременно.
>>>>
>>>> рамы и проца zfs нужно не больше чем другим fs
>>
>> SK> Йа-йа... А RAIDZ с его контрольными суммами, ECC и прочими чудесами
>> SK> сполняет Пушкин Антон Семёныч. Сбоку и совершенно забесплатно. Без рамы
>> SK> и не напрягая проца.
>>
>> да. ты можешь теоретезировать, а я на реальных системах замеры производил и могу еще произвести.
>> при трансфере порядка 5ГБ/с с такой fs проца на нее тратится порядка пары процентов.

SK> Когда у тебя _один_ процессор с ограниченной рамой только на переключение
SK> контекста уйдут далеко не единицы процента. Не говоря уже про ECC, сборку
SK> из лоскутов и прочая. Естественно, оно не сильно проблема когда процессору
SK> кроме перегрузки мануры из ФС в 100гигабитную сеть и наоборот больше и
SK> заняться-то нечем. Но ты не поверишь, бывают и такие применения, где и ФС
SK> и сеть просто иногда используемые элементы инфраструктуры и пропускная
SK> способность сортира никого не волнует вообще -- туда если и ходят, то
SK> только изредка и очень на недолго.

у нас что, память стала экономить проценты при переключении контекста?
или если двадцать процов контексты переключили -- это будет дешевле?
ты что возразить-то хотел?

>> SK> Авторы вон рекомендуют аж отдельный скоростной SSD под ейный кэш специально.
>>
>> а все остальный прикручивают соплями flashcache/blockcache/что-то еще и смотрят как бы добиться
>> хотя бы половины эффективности кеширования zfs

SK> А оно не нужно. Просто совсем. Кроме как в датацентрах. В инженерных
SK> рабочих станциях большие объёмы и высокая скорость практически никогда
SK> не требуются одновременно. Надёжность _хранения_ информации сильно

ну так и не ставь, никто не заставляет. это необязательная опция для тех, кому хочется.

SK> Я не спорю с тем, что ZFS с бздёй наверняка быстрее в датацентрах с
SK> многоКАтерабайтами данных которые надо куда-то быстро-быстро отправлять
SK> через 100гигабитные сетевые карты серверами с десятками процессоров и
SK> многими гигабатайми рамы, которые сервера не заняты ничем другим кроме
SK> отправки тех петабайтов через 100гигабайтные сетевые карты. Для такого
SK> и бздя хороша.

ZFS просто хороша. она позволяет более гибко раскидывать место и играться
снапшотами. не, в мыльницы я ее ставить не предлагаю, но на рабочих станциях
у других fs я преимуществ перед ней не вижу.

SK> Но это очень узкое применение, не имеющее никакого отношения к тому для
SK> чего используют компьютеры инженеры. Как на работе на дядю, так и дома
SK> для всяческих шабашек/хоббей/whatever. _НИКТО_ не строит дома датацентров
SK> ни для каких целей, это лишено смысла. Всяких же CAD'ов и иже просто
SK> навалом и это именно ими инженер зарабатывает на хлеб с маслом. И для
SK> этого инструменты живут не под одной платформой -- вон у меня, например,
SK> рядом стоит машина с седьмым виндюком. Такая же как и с линухом, T5500 с
SK> 12 ядрами и 72 гигами рамы :) Потому как требуемый заказчиками, например,
SK> OrCAD/Altium/Eagle/AutoCAD/Solidworks/etc. под линухом не бежит потому
SK> приходится его под виндюком поджигать. Если же вдруг какой-нинаебуть
SK> Quartus/Diamond/CodeComposer, то его, естественно, под линухом. Хотя
SK> последний приходится и под виндюком иногда пущать из-за старого PCIного
SK> XDS560, который под линухом не поддерживают и который единственный кто
SK> умеет делать Core Trace -- ни один из более новых, даже самых-самых
SK> распальцованых, этого не умеет.

ну так ты страдаешь винюком, а это совсем другая пестня.

--
Slawa Olhovchenkov

[Dmitry Krivitsky]

На работе - есть, разумеется.

> Так то о чем ты пытаешься сказать , называется "станки, станки,
> станки.." а я - об игрушках.
>
>>> А в сисадмины нам не надо - эвон я передачу смотрел, как в жаркой стране
>>> фермеры выращивают какао. Растят, собирают, обрабатывают и отправляют
>>> куда то. А вкуса шоколада не знают. Им впервые оператор дал попробовать
>>> по кусочку - что выходит из их какао-бобов.
>>
>> А к сисадминам это какое отношение имеет?
>
> Ты как слесарь на заводе. а куда и зачем это мимо тебя.

Куда и зачем - это ко мне, а не мимо.

[Chapai]

"Dmitry Krivitsky" <kr...@fido.fw.nu> wrote in message

news:o48b7b$u4e$1...@dont-email.me...

на работе оно чужое - как шофером работать, водя bmw.

>
>> Так то о чем ты пытаешься сказать , называется "станки, станки,
>> станки.." а я - об игрушках.
>>
>>>> А в сисадмины нам не надо - эвон я передачу смотрел, как в жаркой
>>>> стране
>>>> фермеры выращивают какао. Растят, собирают, обрабатывают и отправляют
>>>> куда то. А вкуса шоколада не знают. Им впервые оператор дал попробовать
>>>> по кусочку - что выходит из их какао-бобов.
>>>
>>> А к сисадминам это какое отношение имеет?
>>
>> Ты как слесарь на заводе. а куда и зачем это мимо тебя.
>
> Куда и зачем - это ко мне, а не мимо.
>

ну расскажи, как ты можешь лично насладиться своим рабочим рейдом.

[Roman N]

Хранение данных на рабочей станции - по определению не надежно. А уж
если со всякими рейдами играться, то еще и запредельно дорого - ну если
конечно своего времени не жаль.

[Sergey Kubushyn]

Играться со всякими рейдами стоит 10 баксов за карточку плюс столько же
за шнурки. Естественно, если покупать самое последнее, блестящее и
переливающееся, что лохам впаривают маркетологи, то дорого. Хранение
данных надёжно при условии периодического бэкапа с уносом в другое место
на предмет защиты от пожара/наводнения/инопланетян. Если исключить такой
мажорный форс, то оно надёжно и само по себе.

Помни, что лох платит всегда...

[Sergey Kubushyn]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Sergey Kubushyn <k...@koi8.net> wrote:
> SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>> SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>>>
>>>>> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
>>>>> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
>>>>> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
>>>>> SK> одной командой восстановить всю систему?
>>>>>
>>>>> ssh zfs send -r > host.dump
>>>
>>> SK> И восстановить на лысый диск тоже одной командой?
>>>
>>> ну restore у тебя на лысый диск вообще работать не будет. ты ему сначала newfs сделай.
>>> а так да -- одной коммандой.
>
> SK> Ну это да, если dump/restore. А если из образа то таки одной командой.
>
> из образа в другой размер одной коммандой?
> ты уж определись

Это в следующем предложении.

>>> SK> А на диск другого размера?
>>>
>>> разумеется
>>>
>>> SK> А под виндюком?
>>>
>>> шо, под винюком у тебя dump/restore завелся?
>
> SK> А почему бы ему и не завестись?
>
> да вот проблемки, особенно с dump

Никаких проблемок. Естественно, оно не работает на NTFS, но оно и не
supposed to.

>>> или у тебя лялих с ntfs грузиться начал?
>
> SK> А это ещё зачем? Я говорил о копировании файловой системы.
>
> эм. как бы файловая система она для того, что бы на ней работать.
> в том числе и грузиться с неё

> не, если у тебя работа в том, что бы копировать файловую систему...

Продукт инженера, девелопящего нечто под embedded, это как раз образ
файловой системы. Которая может быть (и практически всегда есть) под
совершенно другой процессор, не могущая бежать на рабочей станции.

Ты же опять скатываешься к сисадминству.

И эта, так уж исторически сложилось, что в большинстве контор инженерные
рабочие станции не под бздёй. И даже не под линухом. И как бы извращённо
это не выглядело, но обобщённые кумарпателы девелопят под виндюком всё,
включая всякие линухи и андроиды.

>>> SK> А в файле образ создать с нуля? А смонтировать его и установить туда ОС
>>> SK> после чего его отмонтировать и тупо скопировать на блочное устройство чтоб
>>> SK> та ОС там взлетела? И так NNNN раз чтоб на конвейере могли pre-program
>>> SK> устройство чтоб оно будучи возбуждённым капой "Вкл." прямо само взлетало.
>>> SK> И чтоб без сисадминов, обычный штуцер на конвейере чтоб смог.
>>>
>>> штуцер что угодно сломает, а если в скрипт завернуть -- то и разницы нет.
>
> SK> Образ системы в файле оно умеет создать?
>
> блять, какая нахуй разница если ты на лупбэк монтируешь?

А что именно ты монтируешь на лупбэк и откуда оно взялось?

Для той же ext4 под линухом я могу сделать что-то типа

dd if=/dev/zero of=image_file bs=512 count=сколько_надо
mkfs.ext4 image_file

и потом уже монтировать этот файл с пустой ФС на лупбэк и копировать в
него что мне надо любым способом (например, тем же restore). Так как я
начинаю с пустой ФС, то неиспользованная часть будет прекрасно жаться
любым компрессором в отличие от какой-нинаебуть копии рабочей ФС в
которой уже на@срано во всех углах.

Что ты монтируешь на лупбэк в случае чудотворной ZFS?

> SK> Конвейер от датацентра с сисадминами
> SK> отличается очень сильно. А при массовом производстве сами накопители, будь то
> SK> диски или микросхемы вообще программируются их производителем ещё до установки
> SK> в систему. И никаких скриптов там нету, просто тупое копирование бинарного
> SK> файла на устройство.
>
> ага, руками, ни в коем случае не автоматизированно, да еще и с капчей, шоб робота не подсунули

Ногами. Как ты думаешь, как устанавливают ОС на миллионы всяких, прости
г-ди, смартфонов?

>>>>> SK> Я даже и не буду говорить про необходимую для него раму, необходимость
>>>>> SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
>>>>> SK> RAID получается софтверный aka host-based) и многое-многое другое.
>>>>> SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
>>>>> SK> процессором и с ограниченной рамой, причём одновременно.
>>>>>
>>>>> рамы и проца zfs нужно не больше чем другим fs
>>>
>>> SK> Йа-йа... А RAIDZ с его контрольными суммами, ECC и прочими чудесами
>>> SK> сполняет Пушкин Антон Семёныч. Сбоку и совершенно забесплатно. Без рамы
>>> SK> и не напрягая проца.
>>>
>>> да. ты можешь теоретезировать, а я на реальных системах замеры производил и могу еще произвести.
>>> при трансфере порядка 5ГБ/с с такой fs проца на нее тратится порядка пары процентов.
>
> SK> Когда у тебя _один_ процессор с ограниченной рамой только на переключение
> SK> контекста уйдут далеко не единицы процента. Не говоря уже про ECC, сборку
> SK> из лоскутов и прочая. Естественно, оно не сильно проблема когда процессору
> SK> кроме перегрузки мануры из ФС в 100гигабитную сеть и наоборот больше и
> SK> заняться-то нечем. Но ты не поверишь, бывают и такие применения, где и ФС
> SK> и сеть просто иногда используемые элементы инфраструктуры и пропускная
> SK> способность сортира никого не волнует вообще -- туда если и ходят, то
> SK> только изредка и очень на недолго.
>
> у нас что, память стала экономить проценты при переключении контекста?
> или если двадцать процов контексты переключили -- это будет дешевле?
> ты что возразить-то хотел?

Память нужна для кэша. Равно как и для ECC, сборки из лоскутов и иже.
Процессор может быть и единственным причём занятым чем-то кроме обслуживания
ФС. Память с числом процессоров ортогональна, но обычно её объём довольно
сильно коррелирует с числом процессоров так что на мелкой системе та
чудодейственная ФС (которая не более чем средство хранения данных, т.е.
сугубо вспомогательная хрень) отъедает существенную долю и того и другого
от основной задачи.

>>> SK> Авторы вон рекомендуют аж отдельный скоростной SSD под ейный кэш специально.
>>>
>>> а все остальный прикручивают соплями flashcache/blockcache/что-то еще и смотрят как бы добиться
>>> хотя бы половины эффективности кеширования zfs
>
> SK> А оно не нужно. Просто совсем. Кроме как в датацентрах. В инженерных
> SK> рабочих станциях большие объёмы и высокая скорость практически никогда
> SK> не требуются одновременно. Надёжность _хранения_ информации сильно
>
> ну так и не ставь, никто не заставляет. это необязательная опция для тех, кому хочется.
>
> SK> Я не спорю с тем, что ZFS с бздёй наверняка быстрее в датацентрах с
> SK> многоКАтерабайтами данных которые надо куда-то быстро-быстро отправлять
> SK> через 100гигабитные сетевые карты серверами с десятками процессоров и
> SK> многими гигабатайми рамы, которые сервера не заняты ничем другим кроме
> SK> отправки тех петабайтов через 100гигабайтные сетевые карты. Для такого
> SK> и бздя хороша.
>
> ZFS просто хороша. она позволяет более гибко раскидывать место и играться
> снапшотами. не, в мыльницы я ее ставить не предлагаю, но на рабочих станциях
> у других fs я преимуществ перед ней не вижу.

Все те "преимущества" ZFS -- это не фича, а бага для рабочей станции.
Рабочая станция обычно предназначена для того чтобы на ней бежали какие-то
инструменты. И чем меньше для собственно ОС и её потрохов (в том числе ФС)
надо сисадминства, тем лучше. Никакого гибкого раскидывания места и игры
снапшотами на рабочей станции не нужно. То есть вообще совсем. Идеальная ОС
для рабочей станции должна иметь две капы -- "Бежать" и "Стоять" -- и ничего
больше.

> SK> Но это очень узкое применение, не имеющее никакого отношения к тому для
> SK> чего используют компьютеры инженеры. Как на работе на дядю, так и дома
> SK> для всяческих шабашек/хоббей/whatever. _НИКТО_ не строит дома датацентров
> SK> ни для каких целей, это лишено смысла. Всяких же CAD'ов и иже просто
> SK> навалом и это именно ими инженер зарабатывает на хлеб с маслом. И для
> SK> этого инструменты живут не под одной платформой -- вон у меня, например,
> SK> рядом стоит машина с седьмым виндюком. Такая же как и с линухом, T5500 с
> SK> 12 ядрами и 72 гигами рамы :) Потому как требуемый заказчиками, например,
> SK> OrCAD/Altium/Eagle/AutoCAD/Solidworks/etc. под линухом не бежит потому
> SK> приходится его под виндюком поджигать. Если же вдруг какой-нинаебуть
> SK> Quartus/Diamond/CodeComposer, то его, естественно, под линухом. Хотя
> SK> последний приходится и под виндюком иногда пущать из-за старого PCIного
> SK> XDS560, который под линухом не поддерживают и который единственный кто
> SK> умеет делать Core Trace -- ни один из более новых, даже самых-самых
> SK> распальцованых, этого не умеет.
>
> ну так ты страдаешь винюком, а это совсем другая пестня.

Я не страдаю "винюком". И линухом не страдаю. И чем-либо другим. Я просто
пользую разные инструменты, которые требуют разных ОС для своего запуска.

Виндюк -- это такая запускалка для, например, алтиума. Или solidworks. И
не более того. И когда я работаю тем инструментом мне та запускалка глубоко
до фени так что хоть меня и тошнит с виндюка и я только в дурном сне могу
представить его в качестве моей основной рабочей платформы, тот виндюк
где-то очень далеко и я его за инструментом не вижу. Это примерно как
всякий электрический инструмент против пневматического. Некоторые тулзы
лучше электрические, некоторые пневматические. Есть и такие, которые бывают
_только_ электрические или только пневматические. Я пользую те, которые
либо удобнее либо доступны или вообще существуют. При этом работаю я именно
_инструментом_ а вся электрика/пневматика сводится для меня к розетке или
штуцеру куда я включаю свой инструмент. И чем меньше мне надо заботиться
о том, что дальше тех розетки/штуцера, тем лучше.

Твоя же бздя это, типа, гидравлика. Которая, может быть, и хороша, даже
круче электрики и пневматики, но требует постоянного подкручивания и
всякого обслуживания гидравлического насоса и всей связанной с ним
инфраструктуры и, что самое главное, _НИ ОДИН_ из моих (и любых инженерных)
инструментов от гидравлики не работает. Которая гидравлика хороша для
привода экскаваторного ковша или чего-то вроде где она вставляет и
электрику, и пневматику как бык овцу, но требует квалифицированного
механика для своего обслуживания и экскаваторщика для собственно работы.

[Slawa Olhovchenkov]

Sergey Kubushyn <k...@koi8.net> wrote:

>>>> SK> А на диск другого размера?
>>>>
>>>> разумеется
>>>>
>>>> SK> А под виндюком?
>>>>
>>>> шо, под винюком у тебя dump/restore завелся?
>>
>> SK> А почему бы ему и не завестись?
>>
>> да вот проблемки, особенно с dump

SK> Никаких проблемок. Естественно, оно не работает на NTFS, но оно и не
SK> supposed to.

ну так под виндой другого считай и нет.
т.е. не работает

>>>> или у тебя лялих с ntfs грузиться начал?
>>
>> SK> А это ещё зачем? Я говорил о копировании файловой системы.
>>
>> эм. как бы файловая система она для того, что бы на ней работать.
>> в том числе и грузиться с неё

>> не, если у тебя работа в том, что бы копировать файловую систему...

SK> Продукт инженера, девелопящего нечто под embedded, это как раз образ
SK> файловой системы. Которая может быть (и практически всегда есть) под
SK> совершенно другой процессор, не могущая бежать на рабочей станции.

raid в embeded?
я правильно тебя понял

SK> Ты же опять скатываешься к сисадминству.

не, это ты определиться не можешь

SK> И эта, так уж исторически сложилось, что в большинстве контор инженерные
SK> рабочие станции не под бздёй. И даже не под линухом. И как бы извращённо
SK> это не выглядело, но обобщённые кумарпателы девелопят под виндюком всё,
SK> включая всякие линухи и андроиды.

винда -- это отдельная болезнь, ей мало что поможет.

>>>> SK> А в файле образ создать с нуля? А смонтировать его и установить туда ОС
>>>> SK> после чего его отмонтировать и тупо скопировать на блочное устройство чтоб
>>>> SK> та ОС там взлетела? И так NNNN раз чтоб на конвейере могли pre-program
>>>> SK> устройство чтоб оно будучи возбуждённым капой "Вкл." прямо само взлетало.
>>>> SK> И чтоб без сисадминов, обычный штуцер на конвейере чтоб смог.
>>>>
>>>> штуцер что угодно сломает, а если в скрипт завернуть -- то и разницы нет.
>>
>> SK> Образ системы в файле оно умеет создать?
>>
>> блять, какая нахуй разница если ты на лупбэк монтируешь?

SK> А что именно ты монтируешь на лупбэк и откуда оно взялось?

touch -s 10G file.img
mdconfig -a -t vnode file.img
zpool create tank md0

ну вот вторая команда под линухом другая будет
losetup /dev/loop0 file.img

SK> Для той же ext4 под линухом я могу сделать что-то типа

SK> dd if=/dev/zero of=image_file bs=512 count=сколько_надо
SK> mkfs.ext4 image_file

SK> и потом уже монтировать этот файл с пустой ФС на лупбэк и копировать в
SK> него что мне надо любым способом (например, тем же restore). Так как я
SK> начинаю с пустой ФС, то неиспользованная часть будет прекрасно жаться
SK> любым компрессором в отличие от какой-нинаебуть копии рабочей ФС в
SK> которой уже на@срано во всех углах.

SK> Что ты монтируешь на лупбэк в случае чудотворной ZFS?

файл.

>> SK> Конвейер от датацентра с сисадминами
>> SK> отличается очень сильно. А при массовом производстве сами накопители, будь то
>> SK> диски или микросхемы вообще программируются их производителем ещё до установки
>> SK> в систему. И никаких скриптов там нету, просто тупое копирование бинарного
>> SK> файла на устройство.
>>
>> ага, руками, ни в коем случае не автоматизированно, да еще и с капчей, шоб робота не подсунули

SK> Ногами. Как ты думаешь, как устанавливают ОС на миллионы всяких, прости
SK> г-ди, смартфонов?

ну уж не штуцером.

>>>>>> SK> Я даже и не буду говорить про необходимую для него раму, необходимость
>>>>>> SK> молотить всё тем же процессором, которым сполняется всё остальное (т.е.
>>>>>> SK> RAID получается софтверный aka host-based) и многое-многое другое.
>>>>>> SK> Сисадминам не понять. Чтоб два раза не вставать, машины бывают и с одним
>>>>>> SK> процессором и с ограниченной рамой, причём одновременно.
>>>>>>
>>>>>> рамы и проца zfs нужно не больше чем другим fs
>>>>
>>>> SK> Йа-йа... А RAIDZ с его контрольными суммами, ECC и прочими чудесами
>>>> SK> сполняет Пушкин Антон Семёныч. Сбоку и совершенно забесплатно. Без рамы
>>>> SK> и не напрягая проца.
>>>>
>>>> да. ты можешь теоретезировать, а я на реальных системах замеры производил и могу еще произвести.
>>>> при трансфере порядка 5ГБ/с с такой fs проца на нее тратится порядка пары процентов.
>>
>> SK> Когда у тебя _один_ процессор с ограниченной рамой только на переключение
>> SK> контекста уйдут далеко не единицы процента. Не говоря уже про ECC, сборку
>> SK> из лоскутов и прочая. Естественно, оно не сильно проблема когда процессору
>> SK> кроме перегрузки мануры из ФС в 100гигабитную сеть и наоборот больше и
>> SK> заняться-то нечем. Но ты не поверишь, бывают и такие применения, где и ФС
>> SK> и сеть просто иногда используемые элементы инфраструктуры и пропускная
>> SK> способность сортира никого не волнует вообще -- туда если и ходят, то
>> SK> только изредка и очень на недолго.
>>
>> у нас что, память стала экономить проценты при переключении контекста?
>> или если двадцать процов контексты переключили -- это будет дешевле?
>> ты что возразить-то хотел?

SK> Память нужна для кэша. Равно как и для ECC, сборки из лоскутов и иже.

и что? причем тут переключения контекстов?

SK> Процессор может быть и единственным причём занятым чем-то кроме обслуживания
SK> ФС.

хорошо. и что? это ни на что не влияет и ничему не мешает.

SK> Память с числом процессоров ортогональна, но обычно её объём довольно
SK> сильно коррелирует с числом процессоров так что на мелкой системе та
SK> чудодейственная ФС (которая не более чем средство хранения данных, т.е.
SK> сугубо вспомогательная хрень) отъедает существенную долю и того и другого
SK> от основной задачи.

нет. отъедает она примерно столько же.
ну разве что у тебя весь диск метров 100.
только ты таких мелких дисков не найдешь, что бы в своей раид воткнуть.

>>>> SK> Авторы вон рекомендуют аж отдельный скоростной SSD под ейный кэш специально.
>>>>
>>>> а все остальный прикручивают соплями flashcache/blockcache/что-то еще и смотрят как бы добиться
>>>> хотя бы половины эффективности кеширования zfs
>>
>> SK> А оно не нужно. Просто совсем. Кроме как в датацентрах. В инженерных
>> SK> рабочих станциях большие объёмы и высокая скорость практически никогда
>> SK> не требуются одновременно. Надёжность _хранения_ информации сильно
>>
>> ну так и не ставь, никто не заставляет. это необязательная опция для тех, кому хочется.
>>
>> SK> Я не спорю с тем, что ZFS с бздёй наверняка быстрее в датацентрах с
>> SK> многоКАтерабайтами данных которые надо куда-то быстро-быстро отправлять
>> SK> через 100гигабитные сетевые карты серверами с десятками процессоров и
>> SK> многими гигабатайми рамы, которые сервера не заняты ничем другим кроме
>> SK> отправки тех петабайтов через 100гигабайтные сетевые карты. Для такого
>> SK> и бздя хороша.
>>
>> ZFS просто хороша. она позволяет более гибко раскидывать место и играться
>> снапшотами. не, в мыльницы я ее ставить не предлагаю, но на рабочих станциях
>> у других fs я преимуществ перед ней не вижу.

SK> Все те "преимущества" ZFS -- это не фича, а бага для рабочей станции.
SK> Рабочая станция обычно предназначена для того чтобы на ней бежали какие-то
SK> инструменты. И чем меньше для собственно ОС и её потрохов (в том числе ФС)
SK> надо сисадминства, тем лучше. Никакого гибкого раскидывания места и игры
SK> снапшотами на рабочей станции не нужно. То есть вообще совсем. Идеальная ОС
SK> для рабочей станции должна иметь две капы -- "Бежать" и "Стоять" -- и ничего
SK> больше.

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

--
Slawa Olhovchenkov

[Const]

Chapai <race...@gmail.com> wrote:
> Кстати, давно хотел спросить - у тебя какое хобби?

Предаваться пятичасовкам ненависти и самозабвенно врать ?

---
Const

[Roman N]

Sergey Kubushyn wrote on 31/12/2016 14:55:
> Roman N <datai...@gmail.com> wrote:
>> Sergey Kubushyn wrote on 30/12/2016 23:42:
>>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>> SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>>>>
>>>>>> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
>>>>>> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
>>>>>> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
>>>>>> SK> одной командой восстановить всю систему?
>>>>>>
>>>>>> ssh zfs send -r > host.dump

>> Хранение данных на рабочей станции - по определению не надежно. А уж
>> если со всякими рейдами играться, то еще и запредельно дорого - ну если
>> конечно своего времени не жаль.
>
> Играться со всякими рейдами стоит 10 баксов за карточку плюс столько же
> за шнурки. Естественно, если покупать самое последнее, блестящее и
> переливающееся, что лохам впаривают маркетологи, то дорого. Хранение
> данных надёжно при условии периодического бэкапа с уносом в другое место
> на предмет защиты от пожара/наводнения/инопланетян. Если исключить такой
> мажорный форс, то оно надёжно и само по себе.
>
> Помни, что лох платит всегда...

Ну линуксовый mdadm - это кромешный пиздец, а уж эти "железные" рейды.

Что будет когда та карточка наебнется? Заказывать еще одну с ибея?
А потом заставлять ее распознать диски которые предыдущая пометила
специальной разметкой? Да, и как оно сообщит что диск наебнулся, что бы
заменить вовремя?

Сисадминство на ровном месте.

[Sergey Kubushyn]

Roman N <datai...@gmail.com> wrote:
> Sergey Kubushyn wrote on 31/12/2016 14:55:
>> Roman N <datai...@gmail.com> wrote:
>>> Sergey Kubushyn wrote on 30/12/2016 23:42:
>>>> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>>> SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>>>>>>> Sergey Kubushyn <k...@koi8.net> wrote:
>>>>>>>
>>>>>>> SK> Чем заменить тривиальное "ssh root@host dump 0f - / > host.dump", которое
>>>>>>> SK> исполняется по крону совершенно автоматически еженедельно (и с другими
>>>>>>> SK> уровнями в остальные дни недели) и как потом, если вдруг, из того дампа
>>>>>>> SK> одной командой восстановить всю систему?
>>>>>>>
>>>>>>> ssh zfs send -r > host.dump
>>> Хранение данных на рабочей станции - по определению не надежно. А уж
>>> если со всякими рейдами играться, то еще и запредельно дорого - ну если
>>> конечно своего времени не жаль.
>>
>> Играться со всякими рейдами стоит 10 баксов за карточку плюс столько же
>> за шнурки. Естественно, если покупать самое последнее, блестящее и
>> переливающееся, что лохам впаривают маркетологи, то дорого. Хранение
>> данных надёжно при условии периодического бэкапа с уносом в другое место
>> на предмет защиты от пожара/наводнения/инопланетян. Если исключить такой
>> мажорный форс, то оно надёжно и само по себе.
>>
>> Помни, что лох платит всегда...
>
> Ну линуксовый mdadm - это кромешный пиздец, а уж эти "железные" рейды.

Не вижу ничего кромешного в mdadm. Работает как из ружжа, всё от него
требуемое сполняет. Не говоря уже про железные RAID'ы которые для линуха
(или чего угодно вообще) выглядят как самый обычный стандартный диск.

> Что будет когда та карточка наебнется? Заказывать еще одну с ибея?

Ты не поверишь -- заменю на точно такую же другую. Или ты думаешь что у
меня жаба _ТАКОГО_ размера что я не купил несколько штук в запас, на
всякий случай, по сумасшедшей цене десять баксов за?

> А потом заставлять ее распознать диски которые предыдущая пометила
> специальной разметкой? Да, и как оно сообщит что диск наебнулся, что бы
> заменить вовремя?

На то есть специальный демон, который мне email пришлёт как только оно
случится. А пока я на тот email отреагирую оно само подключит Hot Spare.
И само же ту Hot Spare из массива вытащит и переведёт взад в Hot Spare
когда я заменю скацапузившийся диск.

> Сисадминство на ровном месте.

Йа-йа, бином Ньютона, мля... Надо срочно на бздю переходить, да?

Твоя бздя, братан, годится только для сисадмина и в сервера в датацентр.

Когда же котлеты отдельно, мухи отдельно, оно работает вообще где угодно
без какого-либо сисадминства. В отличие от твоей чудотворной ZFS. Которая
не только извращение сама по себе, требующее сисадминов и постоянных
приседаний, но и работает только на специфических системах. Попробуй
рассказать как её прикрутить, например, к седьмому виндюку. Или, чтоб
попроще, к стандартной федоре искаропки. Как убедить GRUB с той ZFS
бутиться. Что в случае железного RAID'а совершенно прозрачно и не требует
никаких усилий вообще (ну, разве что для виндюка при установке надо
подсунуть дискету с драйвером один раз что не ахти какое сложное дело,
к тому же исполняемое ровно _ОДИН_ раз).

[Vladimir Naboka]

31.12.2016 7:21, Sergey Kubushyn пишет:

> Ты в этом году уже купил новый телевизор? А то ведь можно и не успеть и
> будешь, как дурак, с прошлогодним...

Да сам-то тиливизер ладно, но ведь оне покупают всё ещё и потому,
что оно "теперь в новой упаковке !!"
Бляааа...

[Sergey Kubushyn]

Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> Sergey Kubushyn <k...@koi8.net> wrote:
>
>>>>> SK> А на диск другого размера?
>>>>>
>>>>> разумеется
>>>>>
>>>>> SK> А под виндюком?
>>>>>
>>>>> шо, под винюком у тебя dump/restore завелся?
>>>
>>> SK> А почему бы ему и не завестись?
>>>
>>> да вот проблемки, особенно с dump
>
> SK> Никаких проблемок. Естественно, оно не работает на NTFS, но оно и не
> SK> supposed to.
>
> ну так под виндой другого считай и нет.
> т.е. не работает

Ты эта, попробуй сисадмина выключить... Виндюк (как и что угодно другое)
может быть всего лишь инструментом, используемым для разработки чего-то
другого, не имеющего к собственно виндюку никакого отношения. Про кросс
не слышал никогда?

>>>>> или у тебя лялих с ntfs грузиться начал?
>>>
>>> SK> А это ещё зачем? Я говорил о копировании файловой системы.
>>>
>>> эм. как бы файловая система она для того, что бы на ней работать.
>>> в том числе и грузиться с неё
>
>>> не, если у тебя работа в том, что бы копировать файловую систему...
>
> SK> Продукт инженера, девелопящего нечто под embedded, это как раз образ
> SK> файловой системы. Которая может быть (и практически всегда есть) под
> SK> совершенно другой процессор, не могущая бежать на рабочей станции.
>
> raid в embeded?
> я правильно тебя понял

В самую пупочку, только с точностью до наоборот. Когда котлеты и мухи
отдельно, raid домешивается по необходимости. Абсолютно не влияя на
собственно ФС, которая может быть какой угодно и на какой угодно ОС и
аппаратной платформе. И тот raid можно добавить/убрать в любой момент.

Не надо пытаться кривицкого дать. Оно у тебя особо и не получается...

> SK> Ты же опять скатываешься к сисадминству.
>
> не, это ты определиться не можешь

Я давно определился. Как и все те, кто не сисадмины. Котлеты отдельно,
мухи отдельно.

> SK> И эта, так уж исторически сложилось, что в большинстве контор инженерные
> SK> рабочие станции не под бздёй. И даже не под линухом. И как бы извращённо
> SK> это не выглядело, но обобщённые кумарпателы девелопят под виндюком всё,
> SK> включая всякие линухи и андроиды.
>
> винда -- это отдельная болезнь, ей мало что поможет.

Это такой инструмент, запускалка для [часто очень дорогих] инженерных
инструментов, которые ни на чём другом не работают. Примерно как двигатель
в машине, работающий на бензине -- может мне не нравится запах бензина и
вообще бензин суксь, но, увы, на пятом номере шанели оно не работает и тот
бензин приходится таки терпеть. Никто не заставляет тебя любить бензин или
пользовать его вместо пива, но чтобы твоя машина ехала в бензобак надо лить
именно его. На пиве не поедет...

И те, кто платят денег за некий продукт инженерного труда, в большинстве
своём требуют чтоб оно было выпилено строго определённым инструментом,
который они пользуют внутри себя. И тот инструмент практически всегда под
виндюком.

Более того, некоторые инструменты _НАСТОЛЬКО_ дороги, что кондовый шабашник
просто не может себе позволить такой купить для эпизодической шабашки ибо
не окупится никогда. И даже более того, большинство таких инструментов нонче
вообще не продаётся, а даётся на попользовать за смешную плату в несколько
десятков килобаксов в год. Потому заказчик даёт шабашнику временную лицензию
на период контракта и угадай с трёх раз работает ли оно под бздёй...

Автоматом. Который не исполняет сложные скрипты, а тупо накатывает образ
на устройство. Которое устройство в большинстве случаев ИС памяти и которое
в 99.9999% случаев программируется его изготовителем/поставщиком согласно
выданной заказчиком спецификации ещё _ДО_ того как его установят на плату
конечного продукта и засунут ту плату в печку.

Это влияет на то, что и память, и процессорное время являются критическими
ресурсами для устройства и расходовать заметную их часть на обслуживание ФС
просто глупо и, в большинстве случаев, чревато боком из-за дополнительных
затрат потому как выбранных впритык ресурсов уже не хватает и приходится
брать что-то подороже. Потому как " Any fool can build a bridge that will
stand up. It takes an engineer to build a bridge that will _just_ stand up."

Это, опять-таки, сисадминство, сервера, датацентры...

Ладно, хватит порожняк гонять, надо дело делать...

[Slawa Olhovchenkov]

Sergey Kubushyn <k...@koi8.net> wrote:

SK> Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> Sergey Kubushyn <k...@koi8.net> wrote:
>>
>>>>>> SK> А на диск другого размера?
>>>>>>
>>>>>> разумеется
>>>>>>
>>>>>> SK> А под виндюком?
>>>>>>
>>>>>> шо, под винюком у тебя dump/restore завелся?
>>>>
>>>> SK> А почему бы ему и не завестись?
>>>>
>>>> да вот проблемки, особенно с dump
>>
>> SK> Никаких проблемок. Естественно, оно не работает на NTFS, но оно и не
>> SK> supposed to.
>>
>> ну так под виндой другого считай и нет.
>> т.е. не работает

SK> Ты эта, попробуй сисадмина выключить... Виндюк (как и что угодно другое)
SK> может быть всего лишь инструментом, используемым для разработки чего-то
SK> другого, не имеющего к собственно виндюку никакого отношения. Про кросс
SK> не слышал никогда?

и что? как это на dump/restore влияет?

>>>>>> или у тебя лялих с ntfs грузиться начал?
>>>>
>>>> SK> А это ещё зачем? Я говорил о копировании файловой системы.
>>>>
>>>> эм. как бы файловая система она для того, что бы на ней работать.
>>>> в том числе и грузиться с неё
>>
>>>> не, если у тебя работа в том, что бы копировать файловую систему...
>>
>> SK> Продукт инженера, девелопящего нечто под embedded, это как раз образ
>> SK> файловой системы. Которая может быть (и практически всегда есть) под
>> SK> совершенно другой процессор, не могущая бежать на рабочей станции.
>>
>> raid в embeded?
>> я правильно тебя понял

SK> В самую пупочку, только с точностью до наоборот. Когда котлеты и мухи
SK> отдельно, raid домешивается по необходимости. Абсолютно не влияя на
SK> собственно ФС, которая может быть какой угодно и на какой угодно ОС и
SK> аппаратной платформе. И тот raid можно добавить/убрать в любой момент.

я тебя не понимаю, ты тащишь или нет raid в ембедед?
или ты общую шину изобретаешь?

>> SK> Ногами. Как ты думаешь, как устанавливают ОС на миллионы всяких, прости
>> SK> г-ди, смартфонов?
>>
>> ну уж не штуцером.

SK> Автоматом. Который не исполняет сложные скрипты, а тупо накатывает образ
SK> на устройство. Которое устройство в большинстве случаев ИС памяти и которое
SK> в 99.9999% случаев программируется его изготовителем/поставщиком согласно
SK> выданной заказчиком спецификации ещё _ДО_ того как его установят на плату
SK> конечного продукта и засунут ту плату в печку.

да и похрен.

SK> Это влияет на то, что и память, и процессорное время являются критическими
SK> ресурсами для устройства и расходовать заметную их часть на обслуживание ФС

я в очередной раз повторяю, что это исключительно твои фантазии про "заметную часть".
что относительно проца, что относительно памяти.

--
Slawa Olhovchenkov

[Yury Mukharsky]

А вот, кстати. Мой бывший делл умел рейд. А новый, почти такой же, как бы
не умеет. Но диски, собранные старым в массив, им разпозанются, как рейд и
все работает. Это нечто универсальное или чисто делловское?

Юра

[Roman N]

Ну и нафига все это на рабочем компьютере?

>> Сисадминство на ровном месте.
>
> Йа-йа, бином Ньютона, мля... Надо срочно на бздю переходить, да?
>
> Твоя бздя, братан, годится только для сисадмина и в сервера в датацентр.

Да ладно гнать-то, freenas с USB устанавливается за 15 минут.

> Когда же котлеты отдельно, мухи отдельно, оно работает вообще где угодно
> без какого-либо сисадминства. В отличие от твоей чудотворной ZFS. Которая
> не только извращение сама по себе, требующее сисадминов и постоянных
> приседаний, но и работает только на специфических системах. Попробуй
> рассказать как её прикрутить, например, к седьмому виндюку.

Ее не надо никуда крутить, c сервера можно расшарить по чему угодно для
кого угодно

iSCSI, CIFS или даже nfs (если время девать некуда)

> Или, чтоб
> попроще, к стандартной федоре искаропки. Как убедить GRUB с той ZFS
> бутиться. Что в случае железного RAID'а совершенно прозрачно и не требует
> никаких усилий вообще (ну, разве что для виндюка при установке надо
> подсунуть дискету с драйвером один раз что не ахти какое сложное дело,
> к тому же исполняемое ровно _ОДИН_ раз).

Я по вендам не спец, последний раз видел их живьем года три назад.

Freenas, openfiler и прочие synology позволяют решать проблему надежного
хренения данных вместе с удобством доступа. Че решают железные рейды на
рабочих станциях не очень понятно.

Карточки с железными рейдами только усложняют систему. Если за
компьютером работает человек - там должен быть ssd воткнут и все. Со
вмеми остальными данными через сеть с файлера.

На котором обычно всякие zfs и крутятся.