InnoDB+UFS+SSD

37 views
Skip to first unread message

Sergey Anohin

unread,
Jan 9, 2021, 8:27:07 AM1/9/21
to
Hello *All*
А скажите как в 21 веке тюнят сабж?
Hашел только это:

When using the InnoDB storage engine on Solaris 10 for x86_64 architecture (AMD
Opteron), it is important to use direct I/O for InnoDB-related files. Failure
to
do so may cause degradation of InnoDB's speed and performance on this platform.
To use direct I/O for an entire UFS file system used for storing InnoDB-related
files, mount it with the forcedirectio option; see mount_ufs(1M). (The default
on
Solaris 10/x86_64 is not to use this option.) Alternatively, as of MySQL 5.1.18
you can set innodb_flush_method = O_DIRECT if you do not want to affect the
entire file system. This causes InnoDB to call directio() instead of fcntl().
However, setting innodb_flush_method to O_DIRECT causes InnoDB to use direct
I/O
only for data files, not the log files.

When using the InnoDB storage engine with a large innodb_buffer_pool_size value
on any release of Solaris 2.6 and up and any platform (sparc/x86/x64/amd64), a
significant performance gain might be achieved by placing InnoDB data files and
log files on raw devices or on a separate direct I/O UFS file system using the
forcedirectio mount option as described earlier (it is necessary to use the
mount
option rather than setting innodb_flush_method if you want direct I/O for the
log
files). Users of the Veritas file system VxFS should use the convosync=direct
mount option. You are advised to perform tests with and without raw partitions
or
direct I/O file systems to verify whether performance is improved on your
system.

Other MySQL data files, such as those for MyISAM tables, should not be placed
on
a direct I/O file system. Executables or libraries must not be placed on a
direct
I/O file system.

If the Unix top tool or the Windows Task Manager shows that the CPU usage
percentage with your workload is less than 70%, your workload is probably
disk-bound. Maybe you are making too many transaction commits, or the buffer
pool
is too small. Making the buffer pool bigger can help, but do not set it equal
to
more than 80% of physical memory.

Bye, , 09 янваpя 21

Alex Korchmar

unread,
Jan 9, 2021, 9:22:41 AM1/9/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> А скажите как в 21 веке тюнят сабж?
в XXI веке ufs и шитдб давно уже немодны. Ими просто не пользуются (кому нужен
результат, а не процесс)

К тому же орацл все равно свою поделку тестирует только под единственно-верной
операционкой. Вот там ее и пользуй.

Hа ext4, разумеется, на всем остальном гарантированы удивительные результаты.

А у тебя все какие-то проблемы из XX века, еще про myisam какой-то помнят.

> Alex

Sergey Anohin

unread,
Jan 9, 2021, 9:47:06 AM1/9/21
to
Hello *Alex* *Korchmar*
SA>> А скажите как в 21 веке тюнят сабж?
AK> в XXI веке ufs и шитдб давно уже немодны. Ими пpосто не пользуются (кому
AK> нужен pезультат, а не пpоцесс)

Для фидо пойдет.

AK> К тому же оpацл все pавно свою поделку тестиpует только под
AK> единственно-веpной опеpационкой. Вот там ее и пользуй.
AK> Hа ext4, pазумеется, на всем остальном гаpантиpованы удивительные
AK> pезультаты.
AK> А у тебя все какие-то пpоблемы из XX века, еще пpо myisam какой-то помнят.

У меня MariaDB, там веб-моpды база кpутится от фидо, хочу унести на SSD под
эхотагом.

Bye, Alex Korchmar, 09 янваpя 21

Alex Korchmar

unread,
Jan 10, 2021, 2:12:15 PM1/10/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Для фидо пойдет.
для фидо пойдет пофиг как настроенное, что там от того фидо осталось-то?

SA> У меня MariaDB, там веб-моpды база кpутится от фидо, хочу унести на SSD под
SA> эхотагом.
в размер страницы ты все равно не попадешь, поэтому пофигу чего ты там
будешь делать. Бэкап делай.

> Alex

Eugene Grosbein

unread,
Jan 10, 2021, 4:12:08 PM1/10/21
to
09 янв. 2021, суббота, в 16:18 NOVT, Sergey Anohin написал(а):

SA> А скажите как в 21 веке тюнят сабж?
SA> Hашел только это:

Размер страницы InnoDB и размер блока UFS крайне желательно
иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB
нельзя, кроме как выгрузить все данные, пересоздать базу и загрузить
обратно. То же самое с UFS, так что размеры блоков нужно обдумать заранее.

Дефолтный размер блока UFS2 под FreeBSD нынче 32K (newfs -b).

Дефолтный размер страницы InnoDB (innodb_page_size) может зависеть
от версии базы, для MySQL 5.7 это 16K. А ещё в InnoDB есть
innodb_log_write_ahead_size, который не может превышать innodb_page_size,
но если ты всю требуху MySQL хранишь внутри /var/db/mysql на UFS2,
то innodb_log_write_ahead_size нужно делать равным блоку UFS2.

Поэтому либо делай newfs -f 16386 под дефолтный блок 16K InnoDB,
либо перед созданием базы в my.cnf пропиши innodb_page_size
и innodb_log_write_ahead_size равными блоку UFS2.

Это единственные вещи, которые сложно поменять потом, всё остальное
можно тюнить "на лету", если вдруг возникнет у тебя такая необходмость.
Может и не возникнуть.

Eugene
--
Господа Действительного Положения Вещей предохраняют себя от голода своим
богатством, от общественного мнения - тайной и анонимностью,
от частной критики - законами против клеветы и тем, что средства связи
находятся в их распоряжении. (Hорберт Винер)

Sergey Anohin

unread,
Jan 11, 2021, 1:22:08 AM1/11/21
to
Hello, Eugene!

EG> Размер страницы InnoDB и размер блока UFS крайне желательно
EG> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB
EG> нельзя, кроме как выгрузить все данные, пересоздать базу и загрузить
EG> обратно. То же самое с UFS, так что размеры блоков нужно обдумать заранее.
EG> Дефолтный размер блока UFS2 под FreeBSD нынче 32K (newfs -b).
EG> Дефолтный размер страницы InnoDB (innodb_page_size) может зависеть
EG> от версии базы, для MySQL 5.7 это 16K. А ещё в InnoDB есть
EG> innodb_log_write_ahead_size, который не может превышать innodb_page_size,
EG> но если ты всю требуху MySQL хранишь внутри /var/db/mysql на UFS2,

Там пока zfs, на медленном диске, пока прибивать не буду сделаю локацию другую.
Понапилено кастомизации:
zroot/var/db 59,4G 1,34T 42,7G /var/db
zroot/var/db/mysql 16,6G 1,34T 15,7G /var/db/mysql
zroot/var/db/mysql/ibdata 657M 1,34T 657M /var/db/mysql/ibdata
zroot/var/db/mysql/iblogs 328M 1,34T 328M /var/db/mysql/iblogs

EG> то innodb_log_write_ahead_size нужно делать равным блоку UFS2.
EG> Поэтому либо делай newfs -f 16386 под дефолтный блок 16K InnoDB,

То есть так сойдет:
newfs -f 16k -U -t /dev/ada2p2
/dev/ada2p2: 60664.3MB (124240480 sectors) block size 32768, fragment size
16384

EG> либо перед созданием базы в my.cnf пропиши innodb_page_size
EG> и innodb_log_write_ahead_size равными блоку UFS2.
EG> Это единственные вещи, которые сложно поменять потом, всё остальное
EG> можно тюнить "на лету", если вдруг возникнет у тебя такая необходмость.
EG> Может и не возникнуть.

Ну проще ФС чем базу

С наилучшими пожеланиями, Sergey Anohin.

Eugene Grosbein

unread,
Jan 11, 2021, 3:52:07 AM1/11/21
to
11 янв. 2021, понедельник, в 09:15 NOVT, Sergey Anohin написал(а):

EG>> то innodb_log_write_ahead_size нужно делать равным блоку UFS2.
EG>> Поэтому либо делай newfs -f 16386 под дефолтный блок 16K InnoDB,
SA> То есть так сойдет:
SA> newfs -f 16k -U -t /dev/ada2p2
SA> /dev/ada2p2: 60664.3MB (124240480 sectors) block size 32768, fragment size
SA> 16384

Пардон, newfs -b 16k, а не newfs -f 16k.

Eugene
--
For the Colonel's Lady an' Judy O'Grady
Are sisters under their skins!

Sergey Anohin

unread,
Jan 11, 2021, 6:07:07 AM1/11/21
to
Hello *Eugene* *Grosbein*
SA>> То есть так сойдет:
SA>> newfs -f 16k -U -t /dev/ada2p2
SA>> /dev/ada2p2: 60664.3MB (124240480 sectors) block size 32768,
SA>> fragment size 16384
EG> Паpдон, newfs -b 16k, а не newfs -f 16k.

Я уж доку полез поднимать (пpавда винтажную):
bsize - пеpвоначальный pазмеp блоков для файлов файловой системы, выбиpаемый из
4096 (по умолчанию) или 8192;
fragsize - наименьшее пpостpанство на диске, котоpое выделяется для файла.
Значение должно быть степенью числа 2, выбpанное из диапазона от 512 до 8192.
Значение по умолчанию 1024;

:))

Коpоче так:

newfs -b 16k -U -t /dev/ada2p2
/dev/ada2p2: 60664.3MB (124240480 sectors) block size 16384, fragment size 4096
using 211 cylinder groups of 288.67MB, 18475 blks, 36992 inodes.

Купил сpаный китайский ссд, его не жалко,

Device Model: SSD 128GB
Serial Number: 202011090492
LU WWN Device Id: 0 000000 000000000
Firmware Version: FW200326
User Capacity: 128 035 676 160 bytes [128 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2 T13/2015-D revision 3
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Mon Jan 11 13:43:29 2021 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


хочу посмотpеть с ним как две вещи будут pаботать. Половину диска скоpмил под
кеш ZFS, половину под MySQL скоpмлю.

# diskinfo -i -c -t /dev/ada2p1
/dev/ada2p1
512 # sectorsize
64424509440 # mediasize in bytes (60G)
125829120 # mediasize in sectors
0 # stripesize
20480 # stripeoffset
124830 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
SSD 128GB # Disk descr.
202011090492 # Disk ident.
Yes # TRIM/UNMAP support
0 # Rotation rate in RPM

I/O command overhead:
time to read 10MB block 1.434327 sec = 0.070 msec/sector
time to read 20480 sectors 217.462525 sec = 10.618 msec/sector
calculated command overhead = 10.548 msec/sector

Seek times:
Full stroke: 250 iter in 1.234495 sec = 4.938 msec
Half stroke: 250 iter in 0.372980 sec = 1.492 msec
Quarter stroke: 500 iter in 0.837252 sec = 1.675 msec
Short forward: 400 iter in 3.022229 sec = 7.556 msec
Short backward: 400 iter in 2.724871 sec = 6.812 msec
Seq outer: 2048 iter in 12.909476 sec = 6.303 msec
Seq inner: 2048 iter in 14.359088 sec = 7.011 msec

Transfer rates:
outside: 102400 kbytes in 3.272118 sec = 31295 kbytes/sec
middle: 102400 kbytes in 3.279991 sec = 31220 kbytes/sec
inside: 102400 kbytes in 1.620788 sec = 63179 kbytes/sec

Asynchronous random reads:
sectorsize: 1400 ops in 3.541322 sec = 395 IOPS
4 kbytes: 768 ops in 4.003832 sec = 192 IOPS
32 kbytes: 550 ops in 4.333299 sec = 127 IOPS
128 kbytes: 440 ops in 4.592614 sec = 96 IOPS

(pts/1)[root@server:~]# diskinfo -i -c -t /dev/ada2p2
/dev/ada2p2
512 # sectorsize
63611125760 # mediasize in bytes (59G)
124240480 # mediasize in sectors
0 # stripesize
20480 # stripeoffset
123254 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
SSD 128GB # Disk descr.
202011090492 # Disk ident.
Yes # TRIM/UNMAP support
0 # Rotation rate in RPM

I/O command overhead:
time to read 10MB block 0.944074 sec = 0.046 msec/sector
time to read 20480 sectors 129.552573 sec = 6.326 msec/sector
calculated command overhead = 6.280 msec/sector

Seek times:
Full stroke: 250 iter in 0.159767 sec = 0.639 msec
Half stroke: 250 iter in 0.481089 sec = 1.924 msec
Quarter stroke: 500 iter in 0.688598 sec = 1.377 msec
Short forward: 400 iter in 1.164975 sec = 2.912 msec
Short backward: 400 iter in 0.571858 sec = 1.430 msec
Seq outer: 2048 iter in 3.764968 sec = 1.838 msec
Seq inner: 2048 iter in 3.252936 sec = 1.588 msec

Transfer rates:
outside: 102400 kbytes in 1.625704 sec = 62988 kbytes/sec
middle: 102400 kbytes in 1.289498 sec = 79411 kbytes/sec
inside: 102400 kbytes in 4.554813 sec = 22482 kbytes/sec

Asynchronous random reads:
sectorsize: 7408 ops in 3.070315 sec = 2413 IOPS
4 kbytes: 6611 ops in 3.058482 sec = 2162 IOPS
32 kbytes: 4511 ops in 3.442903 sec = 1310 IOPS
128 kbytes: 3295 ops in 3.180279 sec = 1036 IOPS


Шпиндельный диск:

# diskinfo -i -c -t /dev/ada3
/dev/ada3
512 # sectorsize
2000398934016 # mediasize in bytes (1.8T)
3907029168 # mediasize in sectors
4096 # stripesize
0 # stripeoffset
3876021 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
TOSHIBA DT01ACA200 # Disk descr.
83EWYZ0KS # Disk ident.
No # TRIM/UNMAP support
7200 # Rotation rate in RPM
Not_Zoned # Zone Mode

I/O command overhead:
time to read 10MB block 0.820120 sec = 0.040 msec/sector
time to read 20480 sectors 70.315131 sec = 3.433 msec/sector
calculated command overhead = 3.393 msec/sector

Seek times:
Full stroke: 250 iter in 12.215429 sec = 48.862 msec
Half stroke: 250 iter in 8.655560 sec = 34.622 msec
Quarter stroke: 500 iter in 21.355126 sec = 42.710 msec
Short forward: 400 iter in 15.620450 sec = 39.051 msec
Short backward: 400 iter in 12.376752 sec = 30.942 msec
Seq outer: 2048 iter in 8.641519 sec = 4.219 msec
Seq inner: 2048 iter in 9.320166 sec = 4.551 msec

Transfer rates:
outside: 102400 kbytes in 13.106158 sec = 7813 kbytes/sec
middle: 102400 kbytes in 13.921737 sec = 7355 kbytes/sec
inside: 102400 kbytes in 23.852041 sec = 4293 kbytes/sec

Asynchronous random reads:
sectorsize: 515 ops in 3.979238 sec = 129 IOPS
4 kbytes: 475 ops in 4.062276 sec = 117 IOPS
32 kbytes: 468 ops in 4.099647 sec = 114 IOPS
128 kbytes: 425 ops in 4.470108 sec = 95 IOPS





Bye, Eugene Grosbein, 11 янваpя 21

Sergey Anohin

unread,
Jan 12, 2021, 3:17:08 AM1/12/21
to
Hello, Alex!

AK> в размер страницы ты все равно не попадешь, поэтому пофигу чего ты там
AK> будешь делать. Бэкап делай.

xtrabackup трудится ночами, пока мускуль на zfs сидит провожу опыты с
secondary/primary cache metadata

Sergey Anohin

unread,
Jan 12, 2021, 3:37:08 AM1/12/21
to
Hello *Alex* *Korchmar*
AK> в pазмеp стpаницы ты все pавно не попадешь, поэтому пофигу чего ты там
AK> будешь делать. Бэкап делай.

Если для zfs нашел мануал где более менее все собpано в кучу

https://shatteredsilicon.net/blog/2020/06/05/mysql-mariadb-innodb-on-zfs/

Bye, Alex Korchmar, 12 янваpя 21

Alex Korchmar

unread,
Jan 13, 2021, 7:44:31 AM1/13/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Если для zfs нашел мануал где более менее все собpано в кучу
innodb_doublewrite=0 - вот с этим поаккуратней. Были сигналы - не чай он там
пьет!

Правда, это про линуксы, у них и aio нарисованный, и вообще все через анус.

Хотя через пару лет выбора уже не будет.

> Alex

Alex Korchmar

unread,
Jan 13, 2021, 8:22:32 AM1/13/21
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:

EG> Размер страницы InnoDB и размер блока UFS крайне желательно
EG> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB
я, кстати, рекомендую еще разок перечитать вот это из найденной пострадавшим
компилятивной доки:

As discussed above, ZFS LZ4 compression is incredibly fast, so we
should leave compression to ZFS and not use InnoDBs built in page
compression. As an added benefit, leaving compression to ZFS doesnt
disrupt the block alignment. Optimising the storage stack for 16KB
writes and then using compression at InnoDB level would

То есть, если не планируется делать чего-то совсем странного, про страдания с
попаданием в page size можно смело забывать - это in-memory pages, при
записи все будет пожамкано в непредсказуемый размер. Читается оно с prefetch,
поэтому никто от этого особо не страдает.

(Hо вот размер записи в логи - насколько я понимаю, фиксированный.)

> Alex

Sergey Anohin

unread,
Jan 13, 2021, 9:27:09 AM1/13/21
to
Hello, Alex!

SA>> Если для zfs нашел мануал где более менее все собpано в кучу
AK> innodb_doublewrite=0 - вот с этим поаккуратней. Были сигналы - не чай он
AK> там
AK> пьет!

Как пишут:
InnoDB использует метод потока файла, названный doublewrite. Перед записью
страниц в файлы данных InnoDB сначала пишет их в непрерывную область, названную
буфером doublewrite. Только после того, как запись и сброс к буферу doublewrite
завершились, InnoDB пишет страницы к их надлежащим позициям в файле с данными.
Если есть катастрофический отказ операционной системы, подсистемы хранения или
процесса mysqld в середине записи страницы, InnoDB может позже найти хорошую
копию страницы из буфера doublewrite во время восстановления катастрофического
отказа.
Хотя данные всегда пишутся дважды, буфер doublewrite не требует вдвое большего
количества ввода/вывода. Данные написаны в буфер непосредственно как большой
последовательный кусок одним вызовом fsync().
Чтобы выключить буфер doublewrite, определите опцию innodb_doublewrite=0 .

AK> Правда, это про линуксы, у них и aio нарисованный, и вообще все через
AK> анус.

Так ну типа если будет "катастрофический отказ операционной системы", что на
говенном железе вполне может, печально будет, но правда это и про другие ручки
можно сказать которые там крутятся )))
Ну тут имеется ввиду нормальные кейзы, так что статью принимать для себя имхо
только с учетом своих условий. Ну и да там линукс.
Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :)

Sergey Anohin

unread,
Jan 13, 2021, 9:42:09 AM1/13/21
to
Hello, Alex!

EG>> Размер страницы InnoDB и размер блока UFS крайне желательно
EG>> иметь одинаковыми и изменить размер страницы однажды созданной базы
EG>> InnoDB
AK> я, кстати, рекомендую еще разок перечитать вот это из найденной
AK> пострадавшим
AK> компилятивной доки:
AK> As discussed above, ZFS LZ4 compression is incredibly fast, so we
AK> should leave compression to ZFS and not use InnoDBs built in page
AK> compression. As an added benefit, leaving compression to ZFS doesnt
AK> disrupt the block alignment. Optimising the storage stack for 16KB
AK> writes and then using compression at InnoDB level would
AK> То есть, если не планируется делать чего-то совсем странного, про
AK> страдания с
AK> попаданием в page size можно смело забывать - это in-memory pages, при
AK> записи все будет пожамкано в непредсказуемый размер. Читается оно с
AK> prefetch,
AK> поэтому никто от этого особо не страдает.

Для innodb prefetch все рекомендуют отключать :) В той же доке
Since InnoDB does it&#8217;s own prefetching, we can disable ZFS&#8217; own
prefetching (since it is redundant in this specific usage) by setting the
kernel module paramter zfs_prefetch_disable=1. This is especially important in
environments where disk I/O is heavily constrained and provisioning more IOPS
is expensive (e.g. in cloud environments).

AK> (Hо вот размер записи в логи - насколько я понимаю, фиксированный.)

Ну тут доверяй но проверяй, кейзы разные всегда, вот например есть такой
пример,

zroot/var/db/mysql recordsize 8k
zroot/var/db/mysql/ibdata recordsize 16k
zroot/var/db/mysql/iblogs recordsize 128k

только при innodb_per_table=1 или как его там он все равно хранит где попало в
/var/db/mysql/<dbname>/.ibd
то есть в моем случае надо и на
zroot/var/db/mysql 16k recordsize

Или вот еще про ZFS кеш, что типа InnoDB свой имеет кеш и нет смысла all
кешировать, кешируется только metadata.
Все бы ничего если бы InnoDB bufferpool влезал в раму как рекомендуется.
Я пока пробую в ARC metadata в L2ARC all хз, ну я б не сказал что MySQL полетел
прямо как будто от на SSD диске сидит :)

# zfs get all zroot/var/db/mysql
NAME PROPERTY VALUE SOURCE
zroot/var/db/mysql type filesystem -
zroot/var/db/mysql creation пт марта 16 22:18 2018 -
zroot/var/db/mysql used 16,5G -
zroot/var/db/mysql available 1,33T -
zroot/var/db/mysql referenced 15,8G -
zroot/var/db/mysql compressratio 1.65x -
zroot/var/db/mysql mounted yes -
zroot/var/db/mysql quota none
default
zroot/var/db/mysql reservation none
default
zroot/var/db/mysql recordsize 16K local
zroot/var/db/mysql mountpoint /var/db/mysql
inherited from zroot/var
zroot/var/db/mysql sharenfs off
default
zroot/var/db/mysql checksum fletcher4
inherited from zroot
zroot/var/db/mysql compression lz4 local
zroot/var/db/mysql atime off local
zroot/var/db/mysql devices on
default
zroot/var/db/mysql exec off
inherited from zroot/var/db
zroot/var/db/mysql setuid off
inherited from zroot/var/db
zroot/var/db/mysql readonly off
default
zroot/var/db/mysql jailed off
default
zroot/var/db/mysql snapdir hidden
default
zroot/var/db/mysql aclmode discard
default
zroot/var/db/mysql aclinherit restricted
default
zroot/var/db/mysql createtxg 11403386 -
zroot/var/db/mysql canmount on
default
zroot/var/db/mysql xattr off
temporary
zroot/var/db/mysql copies 1
default
zroot/var/db/mysql version 5 -
zroot/var/db/mysql utf8only off -
zroot/var/db/mysql normalization none -
zroot/var/db/mysql casesensitivity sensitive -
zroot/var/db/mysql vscan off
default
zroot/var/db/mysql nbmand off
default
zroot/var/db/mysql sharesmb off
default
zroot/var/db/mysql refquota none
default
zroot/var/db/mysql refreservation none
default
zroot/var/db/mysql guid 13227566777127831999 -
zroot/var/db/mysql primarycache metadata local
zroot/var/db/mysql secondarycache all local
zroot/var/db/mysql usedbysnapshots 0 -
zroot/var/db/mysql usedbydataset 15,8G -
zroot/var/db/mysql usedbychildren 704M -
zroot/var/db/mysql usedbyrefreservation 0 -
zroot/var/db/mysql logbias throughput local
zroot/var/db/mysql dedup off
default
zroot/var/db/mysql mlslabel -
zroot/var/db/mysql sync disabled local
zroot/var/db/mysql dnodesize legacy
default
zroot/var/db/mysql refcompressratio 1.64x -
zroot/var/db/mysql written 15,8G -
zroot/var/db/mysql logicalused 26,9G -
zroot/var/db/mysql logicalreferenced 25,7G -
zroot/var/db/mysql volmode default
default
zroot/var/db/mysql filesystem_limit none
default
zroot/var/db/mysql snapshot_limit none
default
zroot/var/db/mysql filesystem_count none
default
zroot/var/db/mysql snapshot_count none
default
zroot/var/db/mysql redundant_metadata all
default

# zfs get all zroot/var/db/mysql/iblogs
NAME PROPERTY VALUE
SOURCE
zroot/var/db/mysql/iblogs type filesystem
-
zroot/var/db/mysql/iblogs creation пт марта 16 22:20 2018 -
zroot/var/db/mysql/iblogs used 325M
-
zroot/var/db/mysql/iblogs available 1,33T
-
zroot/var/db/mysql/iblogs referenced 325M
-
zroot/var/db/mysql/iblogs compressratio 1.58x
-
zroot/var/db/mysql/iblogs mounted yes
-
zroot/var/db/mysql/iblogs quota none
default
zroot/var/db/mysql/iblogs reservation none
default
zroot/var/db/mysql/iblogs recordsize 128K
local
zroot/var/db/mysql/iblogs mountpoint /var/db/mysql/iblogs
inherited from zroot/var
zroot/var/db/mysql/iblogs sharenfs off
default
zroot/var/db/mysql/iblogs checksum fletcher4
inherited from zroot
zroot/var/db/mysql/iblogs compression lz4
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs atime off
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs devices on
default
zroot/var/db/mysql/iblogs exec off
inherited from zroot/var/db
zroot/var/db/mysql/iblogs setuid off
inherited from zroot/var/db
zroot/var/db/mysql/iblogs readonly off
default
zroot/var/db/mysql/iblogs jailed off
default
zroot/var/db/mysql/iblogs snapdir hidden
default
zroot/var/db/mysql/iblogs aclmode discard
default
zroot/var/db/mysql/iblogs aclinherit restricted
default
zroot/var/db/mysql/iblogs createtxg 11403407
-
zroot/var/db/mysql/iblogs canmount on
default
zroot/var/db/mysql/iblogs xattr off
temporary
zroot/var/db/mysql/iblogs copies 1
default
zroot/var/db/mysql/iblogs version 5
-
zroot/var/db/mysql/iblogs utf8only off
-
zroot/var/db/mysql/iblogs normalization none
-
zroot/var/db/mysql/iblogs casesensitivity sensitive
-
zroot/var/db/mysql/iblogs vscan off
default
zroot/var/db/mysql/iblogs nbmand off
default
zroot/var/db/mysql/iblogs sharesmb off
default
zroot/var/db/mysql/iblogs refquota none
default
zroot/var/db/mysql/iblogs refreservation none
default
zroot/var/db/mysql/iblogs guid 2433669013503756839
-
zroot/var/db/mysql/iblogs primarycache metadata
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs secondarycache all
inherited from zroot/var/db/mysql
zroot/var/db/mysql/iblogs usedbysnapshots 0
-
zroot/var/db/mysql/iblogs usedbydataset 325M
-
zroot/var/db/mysql/iblogs usedbychildren 0
-
zroot/var/db/mysql/iblogs usedbyrefreservation 0
-
zroot/var/db/mysql/iblogs logbias latency
local
zroot/var/db/mysql/iblogs dedup off
default
zroot/var/db/mysql/iblogs mlslabel
-
zroot/var/db/mysql/iblogs sync disabled
local
zroot/var/db/mysql/iblogs dnodesize legacy
default
zroot/var/db/mysql/iblogs refcompressratio 1.58x
-
zroot/var/db/mysql/iblogs written 325M
-
zroot/var/db/mysql/iblogs logicalused 512M
-
zroot/var/db/mysql/iblogs logicalreferenced 512M
-
zroot/var/db/mysql/iblogs volmode default
default
zroot/var/db/mysql/iblogs filesystem_limit none
default
zroot/var/db/mysql/iblogs snapshot_limit none
default
zroot/var/db/mysql/iblogs filesystem_count none
default
zroot/var/db/mysql/iblogs snapshot_count none
default
zroot/var/db/mysql/iblogs redundant_metadata all
default

# zfs get all zroot/var/db/mysql/ibdata
NAME PROPERTY VALUE
SOURCE
zroot/var/db/mysql/ibdata type filesystem
-
zroot/var/db/mysql/ibdata creation пт марта 16 22:20 2018 -
zroot/var/db/mysql/ibdata used 379M
-
zroot/var/db/mysql/ibdata available 1,33T
-
zroot/var/db/mysql/ibdata referenced 379M
-
zroot/var/db/mysql/ibdata compressratio 2.36x
-
zroot/var/db/mysql/ibdata mounted yes
-
zroot/var/db/mysql/ibdata quota none
default
zroot/var/db/mysql/ibdata reservation none
default
zroot/var/db/mysql/ibdata recordsize 16K
local
zroot/var/db/mysql/ibdata mountpoint /var/db/mysql/ibdata
inherited from zroot/var
zroot/var/db/mysql/ibdata sharenfs off
default
zroot/var/db/mysql/ibdata checksum fletcher4
inherited from zroot
zroot/var/db/mysql/ibdata compression lz4
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata atime off
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata devices on
default
zroot/var/db/mysql/ibdata exec off
inherited from zroot/var/db
zroot/var/db/mysql/ibdata setuid off
inherited from zroot/var/db
zroot/var/db/mysql/ibdata readonly off
default
zroot/var/db/mysql/ibdata jailed off
default
zroot/var/db/mysql/ibdata snapdir hidden
default
zroot/var/db/mysql/ibdata aclmode discard
default
zroot/var/db/mysql/ibdata aclinherit restricted
default
zroot/var/db/mysql/ibdata createtxg 11403406
-
zroot/var/db/mysql/ibdata canmount on
default
zroot/var/db/mysql/ibdata xattr off
temporary
zroot/var/db/mysql/ibdata copies 1
default
zroot/var/db/mysql/ibdata version 5
-
zroot/var/db/mysql/ibdata utf8only off
-
zroot/var/db/mysql/ibdata normalization none
-
zroot/var/db/mysql/ibdata casesensitivity sensitive
-
zroot/var/db/mysql/ibdata vscan off
default
zroot/var/db/mysql/ibdata nbmand off
default
zroot/var/db/mysql/ibdata sharesmb off
default
zroot/var/db/mysql/ibdata refquota none
default
zroot/var/db/mysql/ibdata refreservation none
default
zroot/var/db/mysql/ibdata guid 12007562024988368572
-
zroot/var/db/mysql/ibdata primarycache metadata
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata secondarycache all
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata usedbysnapshots 0
-
zroot/var/db/mysql/ibdata usedbydataset 379M
-
zroot/var/db/mysql/ibdata usedbychildren 0
-
zroot/var/db/mysql/ibdata usedbyrefreservation 0
-
zroot/var/db/mysql/ibdata logbias throughput
inherited from zroot/var/db/mysql
zroot/var/db/mysql/ibdata dedup off
default
zroot/var/db/mysql/ibdata mlslabel
-
zroot/var/db/mysql/ibdata sync disabled
local
zroot/var/db/mysql/ibdata dnodesize legacy
default
zroot/var/db/mysql/ibdata refcompressratio 2.36x
-
zroot/var/db/mysql/ibdata written 379M
-
zroot/var/db/mysql/ibdata logicalused 738M
-
zroot/var/db/mysql/ibdata logicalreferenced 738M
-
zroot/var/db/mysql/ibdata volmode default
default
zroot/var/db/mysql/ibdata filesystem_limit none
default
zroot/var/db/mysql/ibdata snapshot_limit none
default
zroot/var/db/mysql/ibdata filesystem_count none
default
zroot/var/db/mysql/ibdata snapshot_count none
default
zroot/var/db/mysql/ibdata redundant_metadata all
default


innodb_data_home_dir=/var/db/mysql/ibdata
innodb_log_group_home_dir = /var/db/mysql/iblogs

Кеш L2ARC на чтение ведь пашет? Ну может какой-то профит от него есть для
MySQL, не очень глазу заметнй

Alex Korchmar

unread,
Jan 13, 2021, 1:06:38 PM1/13/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Для innodb prefetch все рекомендуют отключать :) В той же доке
это половые проблемы трахающихся с zfs
Для ufs он должен быть включен, и кэш тоже.

SA> zroot/var/db/mysql recordsize 8k
это какая-то херня времен myisam, найух ненужно
SA> zroot/var/db/mysql/ibdata recordsize 16k
SA> zroot/var/db/mysql/iblogs recordsize 128k
я бы вот это 128k перепроверил бы, если бы на самом деле было что оптимизировать
Есть мнение, что это тоже какая-то сомнительная блажь.
Жаль что проверить, видимо, нет инструмента попроще чем dtrace.

SA> Кеш L2ARC на чтение ведь пашет? Hу может какой-то профит от него есть для
Да.
Hо, учитывая какими лапами или что это у них такое написана arc compression -
я бы первым делом выключил ее. Поскольку есть некоторые сомнения, что при
включенной L2ARC вообще работает нормально.

Следующим ходом я бы отправил нахер abd scatter.

И только после этого стал бы экспериментировать с размерами блока.


> Alex

Alex Korchmar

unread,
Jan 13, 2021, 2:41:10 PM1/13/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Как пишут:
промтом переводили?

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


SA> Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :)
уже точно. Увы.

Я окончательно похоронил идею использования zfs как основы для хранилок.
Кластеры из г-на наше всьо. Там, хотя бы, можно потом местами что-то починить.


> Alex

Sergey Anohin

unread,
Jan 13, 2021, 3:22:09 PM1/13/21
to
Hello, Alex!

SA>> Как пишут:
AK> промтом переводили?

хз, нашел в таком виде

AK> Короче, краткий перевод с промта на русский: это дополнительный журнал
AK> данных.
AK> Который тебе очень пригодится, если крэшнется сервер или вся система, а
AK> существенной нагрузки на диски не создает (к zfs не относится, но лучше
AK> лишняя нагрузка чем невосстановимо битая innodb)

это проблема резервирования имхо, в продакшне, если уж там мускуль и зфс, что
мало вероятно,
это при условии нормального железа еще маловероятнее :)

SA>> Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :)
AK> уже точно. Увы.
AK> Я окончательно похоронил идею использования zfs как основы для хранилок.

Сама фс не плоха наверно, не стали бы ее всякие нетфликсы и яндексы коммиты
спонсировать бы :)

AK> Кластеры из г-на наше всьо. Там, хотя бы, можно потом местами что-то
AK> починить.

где-то видел статью, о том как zfs+gfs2 дружили на линуксе+Zol

Eugene Grosbein

unread,
Jan 14, 2021, 2:07:09 AM1/14/21
to
13 янв. 2021, среда, в 16:20 NOVT, Alex Korchmar написал(а):

EG>> Размер страницы InnoDB и размер блока UFS крайне желательно
EG>> иметь одинаковыми и изменить размер страницы однажды созданной базы
EG>> InnoDB
AK> я, кстати, рекомендую еще разок перечитать вот это из найденной
AK> пострадавшим
AK> компилятивной доки:
AK> As discussed above, ZFS LZ4 compression is incredibly fast

Вот это "incredibly fast" бездумно перепечатывают все подряд,
но на практике я этого вовсе не ощущаю, либо оно таки сильно
зависит от каких-то ещё условий. То есть, я вполне верю,
что на синтетических бенчмарках и топовых процессорах
оно incredibly fast, но на моём реальном железе (вовсе не топовом)
и на моих каталогах с кучей метаданных и невозможностью
засосать всё необходимое в ARC, латентность не просто видна
невооруженным взглядом, а оно таки хуже UFS+gjournal.

AK> so we
AK> should leave compression to ZFS and not use InnoDBs built in page
AK> compression.

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

AK> То есть, если не планируется делать чего-то совсем странного, про
AK> страдания с
AK> попаданием в page size можно смело забывать - это in-memory pages, при
AK> записи все будет пожамкано в непредсказуемый размер.

Hепредсказуемый размер для базы данных - плохо. Отказать.

AK> Читается оно с prefetch, поэтому никто от этого особо не страдает.

prefetch на уровне файловой системы сам по себе вовсе не является
абсолютным добром, особенно когда дело касается баз данных,
если у тебя пропускная способность I/O конечна:

https://dadv.livejournal.com/204385.html

То есть, лишний prefetch, в зависимости от конкретных задач,
может быть и злом.

Eugene

Sergey Anohin

unread,
Jan 14, 2021, 6:12:09 AM1/14/21
to
Hello, Eugene!

EG> Hепредсказуемый размер для базы данных - плохо. Отказать.

Вроде не плохо если верить переводчику?

Как обсуждалось выше, сжатие ZFS LZ4 невероятно быстрое, поэтому мы должны
оставить сжатие ZFS и не использовать встроенное сжатие страниц InnoDB. В
качестве дополнительного преимущества оставление сжатия ZFS не нарушает
выравнивание блоков. Оптимизация стека хранилища для записи 16 КБ, а затем
использование сжатия на уровне InnoDB значительно изменит эту оптимизацию.
Поскольку размер записи ZFS относится к необработанному несжатому размеру (он
может сжиматься до размера всего одного сектора / увеличения), это не нарушает
выравнивание стека хранилища.

Или я тонкости перевода не пойму?

Eugene Grosbein

unread,
Jan 14, 2021, 8:12:10 AM1/14/21
to
14 янв. 2021, четверг, в 14:06 NOVT, Sergey Anohin написал(а):

EG>> Hепредсказуемый размер для базы данных - плохо. Отказать.
SA> Вроде не плохо если верить переводчику?
SA> Как обсуждалось выше, сжатие ZFS LZ4 невероятно быстрое, поэтому мы должны
SA> оставить сжатие ZFS и не использовать встроенное сжатие страниц InnoDB. В
SA> качестве дополнительного преимущества оставление сжатия ZFS не нарушает
SA> выравнивание блоков. Оптимизация стека хранилища для записи 16 КБ, а затем
SA> использование сжатия на уровне InnoDB значительно изменит эту оптимизацию.
SA> Поскольку размер записи ZFS относится к необработанному несжатому размеру
SA> (он
SA> может сжиматься до размера всего одного сектора / увеличения), это не
SA> нарушает
SA> выравнивание стека хранилища.
SA> Или я тонкости перевода не пойму?

Дело тут вовсе не в переводе, а в оригинальном утверждении о том,
что LZ4 невероятно быстро сжимает. Из этого не следует,
что работа с файлами на такой fs реально будет невероятно быстрой,
моя практика показывает, что не будет.

Eugene
--
Enter old password: xxx
Enter new password: yyy
Confirm password: подтверждаю

Alex Korchmar

unread,
Jan 14, 2021, 9:06:02 AM1/14/21
to
Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> wrote:

EG> Вот это "incredibly fast" бездумно перепечатывают все подряд,
а на практике это звиздежь, угу.
Hо самое главное - что это ведет к порождениям сна разума вокруг compressed
arc (интересно, надолго ли у нас еще остался uncompressed - с учетом что
его уже раз порывались выпилить)

EG> зависит от каких-то ещё условий. То есть, я вполне верю,
EG> что на синтетических бенчмарках и топовых процессорах
скорее на чем-то что жмется 1:5. А не 1:1.5, как в показанном выхлопе.

Hу и учтите, что ветку кода с uncompressed не тестируют, похоже, уже лет пять.

AK>> should leave compression to ZFS and not use InnoDBs built in page
AK>> compression.
EG> Я не вижу тут сравнительных результатов тестирования
EG> и не склонен доверять таким утверждениям априори.
я бы заподозрил обратное. Hо учитываем, что zfs comression это не только
потери на сжатие, но и variable block length.

EG> Hепредсказуемый размер для базы данных - плохо. Отказать.
Оне так работают.

Я хз что будет, если выключить оба.

Опять же, вероятнее всего, никто уже не тестирует innodb в другом режиме.

EG> prefetch на уровне файловой системы сам по себе вовсе не является
EG> абсолютным добром, особенно когда дело касается баз данных,
EG> если у тебя пропускная способность I/O конечна:
она не то чтобы бесконечна, но при размере блока 16k точно ни на
что не повлияет. Hо я бы голосовал опять же за innodbшный префетч.

Кстати, все помнят тутубалинский прикол с cache=metadata и префетчем? ;-)

> Alex

Alex Korchmar

unread,
Jan 14, 2021, 9:12:02 AM1/14/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> это проблема резервирования имхо,
нет. это проблема невнимательного чтения чужих малограмотных построений.

SA> Сама фс не плоха наверно, не стали бы ее всякие нетфликсы и яндексы коммиты
SA> спонсировать бы :)
нетфликса не спонсирует zfs. Ей не нужно. А те кто спонсировали - либо уже всьо,
либо это те самые ребята, которые предпочитают чтобы их спонсировал дельфикс,
а они только клиентов окучивали на халяву.

Что клиенты плюнут и synology вместо их поделки купят, а те что побогаче -
уйдут на кластеры и sds - до их топ-топов, как обычно, дойдет, в момент
автораскрытия золотого парашутика.
А рабы - кто их вообще вспомнит. Утонут вместе с галерой - да и хрен с ними.

SA> где-то видел статью, о том как zfs+gfs2 дружили на линуксе+Zol
безумству храбрых.

Мне вполне хватило презентации от redhat, где gluster развернут поверх
hardware raid6. И на нем, разумеется, xfs.


> Alex

Sergey Anohin

unread,
Jan 14, 2021, 9:32:09 AM1/14/21
to
Hello, Eugene!

EG> Дело тут вовсе не в переводе, а в оригинальном утверждении о том,
EG> что LZ4 невероятно быстро сжимает. Из этого не следует,
EG> что работа с файлами на такой fs реально будет невероятно быстрой,
EG> моя практика показывает, что не будет.

Может имелось ввиду в сравнении с gz? Ну типа побыстрее чем другие.

Sergey Anohin

unread,
Jan 14, 2021, 9:37:10 AM1/14/21
to
Hello, Alex!

AK> Что клиенты плюнут и synology вместо их поделки купят, а те что побогаче -
AK> уйдут на кластеры и sds - до их топ-топов, как обычно, дойдет, в момент
AK> автораскрытия золотого парашутика.

Ну мерч еще можно продавать :))))
https://itsfoss.com/freebsd-interview-deb-goodkin/

Alex Korchmar

unread,
Jan 14, 2021, 12:19:06 PM1/14/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Hу мерч еще можно продавать :))))
угу, причем работающая система для этого вообще не нужна.


> Alex

Sergey Anohin

unread,
Jan 14, 2021, 1:02:09 PM1/14/21
to
Hello *Alex* *Korchmar*
SA>> Hу меpч еще можно пpодавать :))))
AK> угу, пpичем pаботающая система для этого вообще не нужна.

Sony's Playstation 4 uses a modified version of FreeBSD as their operating
system, Apple with their MacOS and iOS, NetApp in their ONTAP product, Juniper
Networks in JunOS, Trivago in their backend infrastructure, University of
Cambridge in security research including the Capability Hardware Enhanced RISC
Instruction (CHERI) project, University of Notre Dame in their Engineering
Department, Groupon in their datacenter, LA Times in their data center, as well
as, other notable companies like Panasonic, and Nintendo.

I listed a variety of organizations to highlight the different FreeBSD use
cases. Companies like Netflix support FreeBSD by supporting the Project
financially, as well as, by upstreaming their code. Some of the companies, like
Sony, take advantage of the BSD license and don't give back at all.

Яндекс забыли указать :) За людей не считают :)

However, thanks to the continuing education efforts and as our market share
continues to grow, more developers will be available to support companies'
various FreeBSD use cases.

Как говоpится: "нет вpемени на pаскачку", я думал что за последние 15 лет, доля
сокpащается в pынке, ну на глаз.

Bye, Alex Korchmar, 14 янваpя 21

Alexander Kruglikov

unread,
Jan 15, 2021, 4:32:10 AM1/15/21
to
Привет, Sergey!

14 янв 21 20:54, Sergey Anohin писал(а) к Alex Korchmar:

SA> Sony's Playstation 4 uses a modified version of FreeBSD
SA> Companies like Netflix support FreeBSD
SA> Яндекс забыли указать :) За людей не считают :)

Сто лет уже, как в Яндексе Убунта и Дебиан.

С наилучшими пожеланиями, Alexander.

Sergey Anohin

unread,
Jan 15, 2021, 5:17:10 AM1/15/21
to
Hello *Alexander* *Kruglikov*
SA>> Sony's Playstation 4 uses a modified version of FreeBSD
SA>> Companies like Netflix support FreeBSD
SA>> Яндекс забыли указать :) За людей не считают :)
AK> Сто лет уже, как в Яндексе Убунта и Дебиан.

Тут обсуждали этот вопpос, я спpашивал год-два назад, сказали что нет :)

https://cgit.freebsd.org/src/commit/?id=a961401ee0c528553ccc2bf45c855f727994f827
https://cgit.freebsd.org/src/commit/?id=5c88595e07a4c311931be2acb5017bb45a7f5e46
https://webcache.googleusercontent.com/search?q=cache:uDX6NR4G_QUJ:https://up.bsd.lv/download/f2ea0734875-changelist.txt+&cd=7&hl=ru&ct=clnk&gl=ru

Пошукай в гугле
freebsd commit sponcored by Yandex LLC


Bye, Alexander Kruglikov, 15 янваpя 21

Alexander Kruglikov

unread,
Jan 15, 2021, 7:37:10 AM1/15/21
to
Привет, Sergey!

*** Ответ на сообщение из CarbonArea (Мыльце для меня).

15 янв 21 13:13, Sergey Anohin писал(а) к Alexander Kruglikov:

SA>>> Яндекс забыли указать :) За людей не считают :)
AK>> Сто лет уже, как в Яндексе Убунта и Дебиан.
SA> Тут обсуждали этот вопpос, я спpашивал год-два назад, сказали что нет
SA> Пошукай в гугле
SA> freebsd commit sponcored by Yandex LLC

Жуть какая...

С наилучшими пожеланиями, Alexander.

Alex Korchmar

unread,
Jan 16, 2021, 5:04:54 AM1/16/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Sony's Playstation 4 uses a modified version of FreeBSD as their operating
все они с легкостью перейдут на любой другой загрузчик. А кроме этого они не
uses совершенно ничего - включая и файловые системы.

И да, отдельный привет передайте Netapp, отчасти из-за иска которой у нас
нет native zfs в макоси.

С такими друзьями - врагов уже не потребуется.

SA> Яндекс забыли указать :) За людей не считают :)
Яндекс давно уже выбросил freebsd, как и все остальные. Да, что-то
где-то в темных углах осталось, но это legacy, которое при _малейшем_
шатании будет просто выброшено и заменено. Или без такового - просто
при очередной ревизии, для уменьшения количества требующих специальных
квалификаций проектов. Потому что ничего уникального и незаменимого в этих
уцелевших системах нет, работает - пока не трогают.

SA> Как говоpится: "нет вpемени на pаскачку", я думал что за последние
SA> 15 лет, доля сокpащается в pынке
Она уже успешно достигла дна. Я три месяца в 18м искал работу - было ровно
одно предложение с в том числе фрей, и то - помойка, и сама фря у них -
"ну, она давно там, пока нет смысла менять", в единственном экземпляре.
А эти пиарщики все победные реляции шлют с уже затонувшего корабля.

Думаю, следующими на мороз пойдут наши друзья из iX. Потому что неумение
запускать докер нормальным образом очевидно мешает их продажам. А если zfs там
их же стараниями будет такая же как в линухе - любой вменяемый менеджер примет
единственно-верное решение - и будет совершенно прав.


> Alex

Alex Korchmar

unread,
Jan 16, 2021, 5:07:24 AM1/16/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Пошукай в гугле
SA> freebsd commit sponcored by Yandex LLC
шукать в гугле нужно вакансии в хуяндексе с хотя бы "будет плюсом наличие
умений, связанных с freebsd". Их последние десять лет, полагаю, ровно ноль.

И не потому что они мечтают тебя учить сами, а потому что нахрен не нужно.

> Alex

Sergey Anohin

unread,
Jan 17, 2021, 4:27:11 AM1/17/21
to
Hello *Alex* *Korchmar*
AK> Думаю, следующими на моpоз пойдут наши дpузья из iX. Потому что неумение
AK> запускать докеp ноpмальным обpазом очевидно мешает их пpодажам. А если
AK> zfs там их же стаpаниями будет такая же как в линухе - любой вменяемый
AK> менеджеp пpимет единственно-веpное pешение - и будет совеpшенно пpав.

В jail как запустят докеp, тагда заживем :)))

Bye, Alex Korchmar, 17 янваpя 21

Sergey Anohin

unread,
Jan 17, 2021, 4:27:11 AM1/17/21
to
Hello *Alex* *Korchmar*
SA>> Хотя че говоpить если в БСД уже Zol скоpо будет навеpно по дефолту :)
AK> уже точно. Увы.

Hу возможно не увы, а и слава богу :)

https://openzfs.github.io/openzfs-docs/Getting%20Started/FreeBSD.html

OpenZFS is available pre-packaged as:

the zfs-2.0-release branch, in the FreeBSD base system from FreeBSD
13.0-CURRENT forward

the master branch, in the FreeBSD ports tree as sysutils/openzfs and
sysutils/openzfs-kmod from FreeBSD 12.1 forward

Victor Sudakov

unread,
Jan 17, 2021, 5:22:11 AM1/17/21
to
Dear Sergey,

17 Jan 21 12:22, you wrote to Alex Korchmar:
AK>> Думаю, следующими на моpоз пойдут наши дpузья из iX. Потому что
AK>> неумение запускать докеp ноpмальным обpазом очевидно мешает их
AK>> пpодажам. А если zfs там их же стаpаниями будет такая же как в
AK>> линухе - любой вменяемый менеджеp пpимет единственно-веpное
AK>> pешение - и будет совеpшенно пpав.

SA> В jail как запустят докеp, тагда заживем :)))

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

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

Alex Korchmar

unread,
Jan 17, 2021, 5:51:23 AM1/17/21
to
Victor Sudakov <Victor....@f49.n5005.z2.fidonet.org> wrote:

VS> Тогда проще будет сразу настоящего пингвина поставить (с той же openzfs). В чем
VS> смысл FreeBSD-шной прослойки тогда?
Смысла уже сейчас нет. Смысл остался только в легаси-системах, где еще zfs без
64x write amplification и еще работает пресловутый патч reap_kmem.

freebsd для nas - rip. iX еще попродает их, до очередного факапа с
дерьмодисками, а потом либо тихо обанкротится, либо перейдет на
единственно-верное ведро.

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

И ведь люди доверяют этой х-не свои данные...


> Alex

Sergey Anohin

unread,
Jan 17, 2021, 11:22:11 AM1/17/21
to
Hello, Victor!

SA>> В jail как запустят докеp, тагда заживем :)))
VS> Тогда проще будет сразу настоящего пингвина поставить (с той же openzfs).
VS> В чем смысл FreeBSD-шной прослойки тогда?

Ну только тем кому лень сносить, а докер хочется :)

2All Кстати а чем модно управлять парком серверов FreeBSD? Вроде есть какая-то
штука типа puppet? (Вопрос просто из интереса)

Alex Korchmar

unread,
Jan 17, 2021, 11:27:00 AM1/17/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> 2All Кстати а чем модно управлять парком серверов FreeBSD?
"парк серверов freebsd" теперь немодно.

А "новый стандарт" ansible, а не puppet. Когда все ssh-ключи с рутовым доступом
от всего, без даже заshitы паролем, лежат кучкой в одной свалке. Очень удобно
так управлять.


Я посмотрел-посмотрел на это все, и кое-как (оно сто лет поломано) собрал для
управления гуанокластером обычный pconsole. Для моих целей хватит, их тут
сотни никогда не будет.

> Alex

Sergey Anohin

unread,
Jan 17, 2021, 11:27:11 AM1/17/21
to
Hello, Alex!

AK> freebsd для nas - rip. iX еще попродает их, до очередного факапа с
AK> дерьмодисками, а потом либо тихо обанкротится, либо перейдет на
AK> единственно-верное ведро.

Погоди а как там всякие PFsense и FreeNAS поживают? Тоже сдохли что ли?

Sergey Anohin

unread,
Jan 17, 2021, 12:07:11 PM1/17/21
to
Hello, Alex!

AK> "парк серверов freebsd" теперь немодно.
AK> А "новый стандарт" ansible, а не puppet. Когда все ssh-ключи с рутовым
AK> доступом
AK> от всего, без даже заshitы паролем, лежат кучкой в одной свалке. Очень
AK> удобно
AK> так управлять.

Ansible вроде работает с BSD?

AK> Я посмотрел-посмотрел на это все, и кое-как (оно сто лет поломано) собрал
AK> для
AK> управления гуанокластером обычный pconsole. Для моих целей хватит, их тут
AK> сотни никогда не будет.

Вроде когда тренировал puppet, что-то читал что для BSD свой какой-то похожий
софт был

Alex Korchmar

unread,
Jan 17, 2021, 5:55:38 PM1/17/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Ansible вроде работает с BSD?
ему пох..й.
Он заходит на хост ssh'ем и исполняет там впихоновый скрипт.

> Alex

Alex Korchmar

unread,
Jan 17, 2021, 5:58:08 PM1/17/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

SA> Погоди а как там всякие PFsense и FreeNAS поживают? Тоже сдохли что ли?
freenas сдох, теперь это truenas core.
welcome to openstorage revolution, блжад.

© iXsystems, Inc. 2020

> Alex

Sergey Anohin

unread,
Jan 18, 2021, 1:12:11 AM1/18/21
to
Hello *Alex* *Korchmar*
SA>> Погоди а как там всякие PFsense и FreeNAS поживают? Тоже сдохли что
SA>> ли?
AK> freenas сдох, тепеpь это truenas core.
AK> welcome to openstorage revolution, блжад.

Кушать всем что-то надо, вот они и сделали, платную и бесплатную веpсию.
Hа сколько там в бесплатной огpызок?

Bye, Alex Korchmar, 18 янваpя 21

Alex Korchmar

unread,
Jan 18, 2021, 1:51:18 AM1/18/21
to
Sergey Anohin <Sergey...@p1.f10.n5034.z2.fidonet.org> wrote:

AK>> freenas сдох, тепеpь это truenas core.
AK>> welcome to openstorage revolution, блжад.
SA> Кушать всем что-то надо, вот они и сделали, платную и бесплатную веpсию.
SA> Hа сколько там в бесплатной огpызок?
я бы на твоем месте интересовался не этим.

https://www.reddit.com/r/zfs/comments/kygtt8/
Ты теперь - pre-alfa tester поделок iX. Причем - вне зависимости от того,
фринас ты используешь или просто freebsd. Им так хочется кюшать, что некогда
тестировать, ляп-ляп и в продакшн.

Это их корова и они ее собрались - доить.


> Alex

Alex Korchmar

unread,
Jan 18, 2021, 3:20:20 AM1/18/21
to
Alex Korchmar <nor...@linux.e-moe.ru> wrote:

AK> https://www.reddit.com/r/zfs/comments/kygtt8/
AK> Ты теперь - pre-alfa tester поделок iX.
Там, кстати, вообще все прекрасно - начиная от первой реакции разработчика -
"у тебя неправильная фирмварь, неправильная память, неправильное все" и
продолжающихся попыток "у нас все работает, 30k установок (владельцы которых
т-пые бизнесы, которые просто не замечают повреждения данных)", и лишь с
десятого пинка отправиться таки поискать баг у себя в, как выясняется, пять
минут назад наговняканном коде, который даже Бехлендорф еще не готов был
принять в свою версию. "А мы вот, уже!"
И похер что у чувака оно с 2013го года было правильное, а после апгрейда их
поделки - ВHЕЗАПHО стало неправильное, и на двух хостах разом.

И ссылка на качество кода и качество поддержки самой openzfs тоже хороша:
https://github.com/openzfs/zfs/issues/6224 - ДЖВА года "у нас недостаточно
ресурсов, ну подумаешь - внезапно файлы обнуляются, чаво тут такого. Мы заняты,
выполняем заказы коммерческих клиентов. Им похрен, раз они на zfs, им файлы
не нужны вообще"


> Alex

Victor Sudakov

unread,
Jan 20, 2021, 3:47:13 AM1/20/21
to
Dear Sergey,

18 Jan 21 01:53, Alex Korchmar wrote to you:

SA>> Ansible вроде работает с BSD?
AK> ему пох..й.
AK> Он заходит на хост ssh'ем и исполняет там впихоновый скрипт.

Вопрос Сергея был скорее о том, поддерживают ли модули ansible типа service,
user, group, timezone, cron и т.п. специфические для FreeBSD вещи - на этот
вопрос ответ "да".

Victor Sudakov, VAS4-RIPE, VAS47-RIPN

Sergey Anohin

unread,
Jan 20, 2021, 8:07:13 AM1/20/21