Этот ответ относится к большинству приложений. Необходимо спросить себя следующее:
Необходимо взвесить ответы на те вопросы против издержек, которые это берет для поддержания программного обеспечения локально. С конюшней Debian, если существует ошибка безопасности, фиксация будет бэкпортирована в более старую версию. При выполнении собственной версии необходимо будет бэкпортировать фиксацию сами или обновить до более новой версии. Обновление производственного программного обеспечения может быть страшным, особенно если изменения внесены в конфигурации, или изменения ожидали поведение прежней версии. Последовательные среды идеальны для производства.
Как администратор, выбор является Вашим.
Мне установили тот же инструмент на Fedora 19, и я заметил в .spec
зарегистрируйте URL, которые приводят к этой названной странице: Хранение редких изображений файловой системы. Эта страница включала некоторые примеры для создания данных тестирования, таким образом, я выполнил команды для создания соответствующих файлов.
$ dd if=/dev/zero of=fs.image bs=1024 seek=2000000 count=0
$ /sbin/mke2fs fs.image
$ ls -l fs.image
-rw-rw-r--. 1 saml saml 2048000000 Jan 4 21:42 fs.image
$ du -s fs.image
32052 fs.image
Когда я работал zerofree -v
управляйте, чтобы я получил следующее:
$ zerofree -v fs.image
...counting up percentages 0%-100%...
0/491394/500000
Когда я использовал инструмент filefrag
опросить fs.image
файл я получил следующее.
$ filefrag -v fs.image
Filesystem type is: ef53
File size of fs.image is 2048000000 (500000 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 620: 11714560.. 11715180: 621:
1: 32768.. 32769: 11716608.. 11716609: 2: 11715181:
2: 32892.. 33382: 11716732.. 11717222: 491: 11716610:
3: 65536.. 66026: 11722752.. 11723242: 491: 11717223:
...
s_block_count
ссылаемый в Вашем исходном коде также совпал с исходным кодом для моей версии zerofree.c
.
if ( verbose ) {
printf("\r%u/%u/%u\n", nonzero, free,
current_fs->super->s_blocks_count) ;
}
Таким образом, мы теперь знаем это s_blocks_count
500 000 блоков 4 096 байтов.
Мы можем также запросить файл изображения fs.image
использование tune2fs
.
$ sudo tune2fs -l fs.image | grep -i "block"
Block count: 500000
Reserved block count: 25000
Free blocks: 491394
First block: 0
Block size: 4096
Reserved GDT blocks: 122
Blocks per group: 32768
Inode blocks per group: 489
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
От этого вывода мы можем определенно видеть что 2-е и 3-и числа, сообщаемые zerofree
на самом деле:
Free blocks: 491394
Block count: 500000
1-е число, о котором сообщают, является на самом деле количеством блоков, которые найдены, которые не являются нулем. Это может быть подтверждено путем рассмотрения фактического исходного кода для zerofree
.
Существует названный счетчик, nonzero
который становится увеличенным каждый раз через основной цикл, это анализирует блоки.
if ( i == current_fs->blocksize ) {
continue ;
}
++nonzero ;
if ( !dryrun ) {
ret = io_channel_write_blk(current_fs->io, blk, 1, empty) ;
if ( ret ) {
fprintf(stderr, "%s: error while writing block\n", argv[0]) ;
return 1 ;
}
}
Таким образом, после некоторого подробного анализа было бы похоже, что те числа следующие:
Небольшая поправка к очень подробному ответу: первое число - это количество свободных ненулевых блоков. (То есть он не считает ненулевые файловые блоки).
Таким образом, оно никогда не превышает количество свободных блоков.
Если вы запустите zerofree (без -n) в файловой системе, а затем запустите его снова (необязательно с -n для пробного запуска), вы увидите, что первое число изменилось на 0, даже с ненулевыми данными файла на файловая система.