нет, не по дефолту, я специально продумывал аналог lvm+xfs и даже успел протестировать во freebsd снапшоты с UFS, но потом меня отвлекло это и я уже забыл, как это должно было все работать.

обрушения системы с dd были у меня вызваны переполнением gjournal, там фиксированный размер.

тормоза и лаги, очевидно, тоже его задержками.

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

во фряхе бардак. UFS - это три технологии журналирования:

1. Soft-Updates (облегченный вариант)
2. Soft-Updates + FS level Journaling (переусложненный по сравнению с линуксом, но дефолт)
3. GEOM (block level) journaling. журналирует на уровне блоков сразу и данные и метаданные. это я и хотел использовать.

witch ~ # tunefs -p /dev/XXX
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: soft update journaling: (-j)                       disabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             0%
tunefs: space to hold for metadata blocks: (-k)            0
tunefs: optimization preference: (-o)                      space
tunefs: volume label: (-L)                                 home

снапшоты фс не работают с (2). эту проблему все еще решают

но мне не это нужно. мне нужен снапшот блочного девайса, а не fs.

The performance degradation occurs when your zpool is either very full or very fragmented. The reason for this is the mechanism of free block discovery employed with ZFS. Opposed to other file systems like NTFS or ext3, there is no block bitmap showing which blocks are occupied and which are free. Instead, ZFS divides your zvol into (usually 200) larger areas called "metaslabs" and stores AVL-trees1 of free block information (space map) in each metaslab. The balanced AVL tree allows for an efficient search for a block fitting the size of the request.

While this mechanism has been chosen for reasons of scale, unfortunately it also turned out to be a major pain when a high level of fragmentation and/or space utilization occurs. As soon as all metaslabs carry a significant amount of data, you get a large number of small areas of free blocks as opposed to a small numbers of large areas when the pool is empty. If ZFS then needs to allocate 2 MB of space, it starts reading and evaluating all metaslabs' space maps to either find a suitable block or a way to break up the 2 MB into smaller blocks. This of course takes some time. What is worse is the fact that it will cost a whole lot of I/O operations as ZFS would indeed read all space maps off the physical disks. For any of your writes.

The drop in performance might be significant. If you fancy pretty pictures, take a look at the blog post over at Delphix which has some numbers taken off an (oversimplified but yet valid) zfs pool. I am shamelessly stealing one of the graphs - look at the blue, red, yellow, and green lines in this graph which are (respectively) representing pools at 10%, 50%, 75%, and 93% capacity drawn against write throughput in KB/s while becoming fragmented over time:

сегодня проапдейтил сервер на F13.1, посмотрю, как работать будет. F13.0 глючил и вис.

это ни о чем не говорит вообще. я тоже не ощутил землетрясение в турции.