>> Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно посмотреть?) А посмотреть то чем можно?
> http://www.linux.org.ru/forum/general/9560485?cid=9563032
Изя, ты самостоятельно думать не умеешь и только копипастишь?
> Если не менять свойство recordsize, задающее максимальный размер блока, то это будет
> 128 килобайт. Файлы, размер которых не превышает максимальный размер блока, занимают
> ровно столько секторов, сколько требуется для их сохранения. При их модификации
> происходит выделение нового блока, так что файлы размером до максимального размера
> блока всегда остаются непрерывными.
чудесно. что происходит со старым блоком, после того как данные "переехали" в новый?
hint: metaslab, space map.
вся техника борьбы с фрагментацией в zfs описывается вот тут:
When ZFS decides to allocate blocks from a particular metaslab, it first reads that metaslab's space map from disk and replays the allocations and frees into an in-memory AVL tree of free space, sorted by offset. This yields a compact in-memory representation of free space that supports efficient allocation of contiguous space. ZFS also takes this opportunity to condense the space map: if there are many allocation-free pairs that cancel out, ZFS replaces the on-disk space map with the smaller in-memory version.
(отсюда взято https://blogs.oracle.com/bonwick/entry/space_maps )
> ---///
> По-моему, объяснение годится.
нет не годится. если мы модифицируем большой файл, внутри будут "дырки"(из-за cow).
и ситуация только усугубляется при заполнении пула.
терминальный случай - постоянная перезапись файлов на заполненном пуле.
