25.06.2017 01:50, Sergey Matveev пишет: > *** artiom <artio...@yandex.ru> [2017-06-25 01:36]: >> Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал, >> посмотрел e4defrag-ом, меньше двух процентов. > > На моём ноутбуке сейчас :-): > > # zpool list > NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH > secure 1008M 149M 859M - 68% 14% 1.00x ONLINE > stcvol 15.9G 1.83G 14.0G - 42% 11% 1.00x ONLINE > zroot 89G 32.3G 56.7G - 44% 36% 1.00x ONLINE > 68% фрагментации, вы это серьёзно?
>> Так всё-таки RAM или дисковое пространство свободное больше требуется? > > И то и другое :-). Если высокая фрагментация (мало свободного места), то > вы всё-равно упрётесь в лавинообразный рост IO на диск и память тут не > поможет. ZFS всегда пишет данные в самое большое свободное место на > диске (самую большу "дырку"). Вообще штатно считается что в большинстве > случаев фрагментация не является проблемой на практике в большинстве > режимов использования/нагрузки. Собственно лично я с фрагментацией > сталкивался только на дисках куда сбрасываю бэкапы, где я делал это > впритык, до последнего гигабайта. > Я понимаю, но это значит, что надо за процентом заполнения следить. >>> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде >>> resilvering-а, то бишь rebuild-а на диски, при котором на них будет >>> дефрагментированный образ создан. >> Условно: mv всего на другой раздел? > > Да, можно и так. Суть одна. Заставить прочитать и записать в другое > место. Чтение пускай не очень быстрое (из-за фрагментированного файла), > но запись уже более быстрая (менее разряженно). > >> А нет a-la e4defrag? > > Нету ни этого, ни xfs_fsr. Только вот хаки. Которые метаинформацию никак > не трогают. Повторюсь: проблема фрагментации зависит от режимов > нагрузки. Но достаточно, в большинстве случаев, просто иметь место про > запас и не париться. > Это печально. Кстати, а как оно распределяет большой файл по дискам в пуле (в разных режимах)?