История изменений

Там речь про SSD шла. Насколько фрагментация ему мешает?

https://superuser.com/questions/1325962/sequential-vs-random-i-o-on-ssds

Пишут, что и для SSD имеет значение.

Могу подтвердить из собственного опыта, что фрагментированный за полгода ZFS пул на Samsung EVO после дефрагментации читает данные при send | receive в несколько раз быстрее (примерно в 2-3 раза).

Т.е. повторный send | receive проходит в разы быстрее первого на том же оборудовании и соответственно показатели фрагментации пула (свободного места?) в zpool list сильно падают.

И это для нагрузки далеко не такой, как у СУБД. У меня обычные файлики документов, сорцов, копий веб страничек и т.п.

Думаю, ежедневно нагруженная СУДБ может фрагментировать пул значительно сильнее.

Там речь про SSD шла. Насколько фрагментация ему мешает?

https://superuser.com/questions/1325962/sequential-vs-random-i-o-on-ssds

Пишут, что и для SSD имеет значение.

Могу подтвердить из собственного опыта, что фрагментированный за полгода ZFS пул на Samsung EVO после дефрагментации читает данные при send | receive в несколько раз быстрее (примерно в 2-3 раза).

Т.е. повторный send | receive проходит в разы быстрее первого на том же оборудовании и соответственно показатели фрагментации пула (свободного места?) в zpool list сильно падают.

И это для нагрузки далеко не такой, как у СУБД. У меня обычные файлики документов, сорцов, копий веб страничек и т.п.

Там речь про SSD шла. Насколько фрагментация ему мешает?

https://superuser.com/questions/1325962/sequential-vs-random-i-o-on-ssds

Пишут, что и для SSD имеет значение.

Могу подтвердить из собственного опыта, что фрагментированный за полгода ZFS пул на Samsung EVO после дефрагментации читает данные при send | receive в несколько раз быстрее (примерно в 2-3 раза).

Т.е. повторный send | receive проходит в разы быстрее первого на том же оборудовании и соответственно показатели фрагментации пула (свободного места?) в zpool list сильно падают.