FreeBSD - изменение зарезервированного обьема дискового пространства

  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '2:e96e0d63d48c400e44381d2ad280e4d4' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p class=\"rtecenter\"><img alt=\"FreeBSD Logo\" src=\"http://muff.kiev.ua/files/FreeBSD.jpg\" style=\"height:150px; width:150px\" /></p>\n<p class=\"rtejustify\">Собирая очередной <a href=\"http://muff.kiev.ua/content/graid5-programnyi-raid-5\">програмнный RAID5 на FreeBSD</a>, решил обратить внимание сообщества на следующий момент:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>\n<p class=\"rtejustify\"># <strong>df -h</strong></p>\n<pre class=\"rtejustify\">\nFilesystem Size Used Avail Capacity Mounted on\n/dev/mirror/gm0a 446G 4,4G 405G 1% /\ndevfs 1,0K 1,0K 0B 100% /dev\n/dev/raid5/raid5 <span style=\"color:#FF0000\">13T</span> 8,0K <span style=\"color:#FF0000\">12T</span> 0% /raid5</pre></td>\n</tr>\n</tbody>\n</table>\n<p class=\"rtejustify\">&quot;Пропал&quot; терабайт доступного дискового пространства... Как это возможно?</p>\n<p class=\"rtejustify\">Дело в том, что часть каждого раздела <strong>UFS</strong> (по умолчанию 8%) зарезервировано для использования операционной системой и пользователем <strong>root</strong>. Утилита&nbsp;<strong>df</strong> не учитывает это при подсчёте значения в колонке&nbsp;<strong>Capacity</strong>, так что оно может превышать 100%. Обратите внимание, что колонка&nbsp;<strong>Blocks</strong>&nbsp;всегда больше, чем сумма значений в колонках&nbsp;<strong>Used</strong>&nbsp;и&nbsp;<strong>Avail</strong>, обычно на 8%.</p>\n<p class=\"rtejustify\">В моем случае, поскольку раздел довольно большой, потеря дискового пространства довольно существенная, поэтому изменим размер зарезервированного пространства до 2% (260GB должно быть более чем достаточно...)</p>\n<p class=\"rtejustify\">Отмонтируем раздел:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>#&nbsp;<strong>umount /dev/raid5/raid5</strong></td>\n</tr>\n</tbody>\n</table>\n<p>С помощью утилиты&nbsp;<strong>tunefs</strong> изменим размер зарезервированного дискового пространства:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>#&nbsp;<strong>tunefs -m <span style=\"color:#FF0000\">2</span> /dev/raid5/raid5</strong><br />\n tunefs: minimum percentage of free space changes from 8% to 2%<br />\n tunefs: should optimize for space with minfree &lt; 8%</td>\n</tr>\n</tbody>\n</table>\n<p>Монтируем раздел:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>#&nbsp;<strong>mount -t ufs /dev/raid5/raid5 /raid5</strong></td>\n</tr>\n</tbody>\n</table>\n<p>Проверяем результат:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>\n<p>#&nbsp;<strong>df -h</strong></p>\n<pre>\nFilesystem Size Used Avail Capacity Mounted on\n/dev/mirror/gm0a 446G 4,4G 405G 1% /\ndevfs 1,0K 1,0K 0B 100% /dev\n/dev/raid5/raid5 13T 8,0K 13T 0% /raid5</pre></td>\n</tr>\n</tbody>\n</table>\n<p>Поскольку в даном выводе размер зарезервированного пространства не подсчитать, ознакомимся с&nbsp;выводом утилиты <strong>df</strong>&nbsp;без ключа <strong>-h</strong>:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>\n<p># <strong>df</strong></p>\n<pre>\nFilesystem 1K-blocks Used Avail Capacity Mounted on\n/dev/mirror/gm0a 467188468 4627044 425186348 1% /\ndevfs 1 1 0 100% /dev\n/dev/raid5/raid5 14191346200 8 13907519268 0% /raid5</pre></td>\n</tr>\n</tbody>\n</table>\n<p>Посчитаем процентное соотношение:</p>\n<table border=\"1\" cellpadding=\"1\" cellspacing=\"1\" style=\"width:100%\">\n<tbody>\n<tr>\n<td>13907519268 х 100 /&nbsp;14191346200 = 97,99</td>\n</tr>\n</tbody>\n</table>\n<p class=\"rtejustify\">Получается 98% доступно... Все сходится.</p>\n<p class=\"rtejustify\">Также стоит обратить внимание еще на такой момент. При уменьшении зарезервированного дисткового пространства до 5% и ниже, FFS отключает алгоритм оптимизации выделения свободных блоков, что приводит к росту фрагментации, росту затрат дискового пространства при расположении файлов (из-за неоптимального расположения, части блоков остаются не занятыми, если файл не занимает его целиком) и, теоретически, к снижению скорости чтения. Здесь стоит подумать и выбирать: оставить зарезервированное пространство, либо отказываться от него и иметь возможность заюзать лишние гигабайты, и получить выше перечисленные проблемы.</p>\n<p class=\"rtejustify\">В моем частном случае даный массив будет использоваться только под хранение бекапов, размеры которых десятки гигабайт одним файлом. Поэтому, исходя из сравнительно небольшого суммарного количества файлов, проблему фрагментации можно игнорировать.</p>\n', created = 1767577422, expire = 1767663822, headers = '', serialized = 0 WHERE cid = '2:e96e0d63d48c400e44381d2ad280e4d4' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 112.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '2:07243fc0252056071eaa62af8c18d662' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p class=\"rtecenter\"><a class=\"thickbox\" href=\"/files/imagepicker/1/wake_up_ua.png\"><img alt=\"Вставай, Україно!\" class=\"imgp_img\" src=\"/files/imagepicker/1/thumbs/wake_up_ua.png\" style=\"height:200px; width:150px\" /></a></p>\n', created = 1767577422, expire = 1767663822, headers = '', serialized = 0 WHERE cid = '2:07243fc0252056071eaa62af8c18d662' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 112.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '3:cc913d232116f0426090404133377d88' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '2:d9a86123bfcbc57878743027b584400b' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p class=\"rtecenter\"><a href=\"http://muff.kiev.ua/rss.xml\"><img alt=\"RSS\" width=\"160\" height=\"60\" src=\"http://muff.kiev.ua/files/muf-rss.png\" /></a></p>\n', created = 1767577422, expire = 1767663822, headers = '', serialized = 0 WHERE cid = '2:d9a86123bfcbc57878743027b584400b' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 112.
  • user warning: Table './muffsql1/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '3:39649256b636e3d5ded656bc52bd8c01' in /usr/local/www/muff.kiev.ua/includes/cache.inc on line 27.
Версия для печатиОтправить другуPDF version

FreeBSD Logo

Собирая очередной програмнный RAID5 на FreeBSD, решил обратить внимание сообщества на следующий момент:

# df -h

Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0a    446G    4,4G    405G     1%    /
devfs               1,0K    1,0K      0B   100%    /dev
/dev/raid5/raid5     13T    8,0K     12T     0%    /raid5

"Пропал" терабайт доступного дискового пространства... Как это возможно?

Дело в том, что часть каждого раздела UFS (по умолчанию 8%) зарезервировано для использования операционной системой и пользователем root. Утилита df не учитывает это при подсчёте значения в колонке Capacity, так что оно может превышать 100%. Обратите внимание, что колонка Blocks всегда больше, чем сумма значений в колонках Used и Avail, обычно на 8%.

В моем случае, поскольку раздел довольно большой, потеря дискового пространства довольно существенная, поэтому изменим размер зарезервированного пространства до 2% (260GB должно быть более чем достаточно...)

Отмонтируем раздел:

umount /dev/raid5/raid5

С помощью утилиты tunefs изменим размер зарезервированного дискового пространства:

tunefs -m 2 /dev/raid5/raid5
tunefs: minimum percentage of free space changes from 8% to 2%
tunefs: should optimize for space with minfree < 8%

Монтируем раздел:

mount -t ufs /dev/raid5/raid5 /raid5

Проверяем результат:

df -h

Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0a    446G    4,4G    405G     1%    /
devfs               1,0K    1,0K      0B   100%    /dev
/dev/raid5/raid5     13T    8,0K     13T     0%    /raid5

Поскольку в даном выводе размер зарезервированного пространства не подсчитать, ознакомимся с выводом утилиты df без ключа -h:

# df

Filesystem         1K-blocks    Used       Avail Capacity  Mounted on
/dev/mirror/gm0a   467188468 4627044   425186348     1%    /
devfs                      1       1           0   100%    /dev
/dev/raid5/raid5 14191346200       8 13907519268     0%    /raid5

Посчитаем процентное соотношение:

13907519268 х 100 / 14191346200 = 97,99

Получается 98% доступно... Все сходится.

Также стоит обратить внимание еще на такой момент. При уменьшении зарезервированного дисткового пространства до 5% и ниже, FFS отключает алгоритм оптимизации выделения свободных блоков, что приводит к росту фрагментации, росту затрат дискового пространства при расположении файлов (из-за неоптимального расположения, части блоков остаются не занятыми, если файл не занимает его целиком) и, теоретически, к снижению скорости чтения. Здесь стоит подумать и выбирать: оставить зарезервированное пространство, либо отказываться от него и иметь возможность заюзать лишние гигабайты, и получить выше перечисленные проблемы.

В моем частном случае даный массив будет использоваться только под хранение бекапов, размеры которых десятки гигабайт одним файлом. Поэтому, исходя из сравнительно небольшого суммарного количества файлов, проблему фрагментации можно игнорировать.

Ваша оценка: Нет Средняя: 4.4 (5 голосов)

Вставай, Україно!

Литература

Надпись на воротах: "ОСТОРОЖНО - ЗЛАЯ @".