Доброго всем здравия коллеги.
Обращаюсь к вам с вопросом, т.к. сам уже не могу понять, что происходит.
Имеем FreeBSD:
FreeBSD web.novour.com 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
На борту несколько дисков:
# gpart show
=> 34 976773101 ada0 GPT (466G)
34 6 - free - (3.0K)
40 1024 1 freebsd-boot (512K)
1064 33554432 2 freebsd-swap (16G)
33555496 943217632 3 freebsd-zfs (450G)
976773128 7 - free - (3.5K)=> 34 976773101 ada1 GPT (466G)
34 6 - free - (3.0K)
40 1024 1 freebsd-boot (512K)
1064 33554432 2 freebsd-swap (16G)
33555496 943217632 3 freebsd-zfs (450G)
976773128 7 - free - (3.5K)=> 34 976770988 ada2 GPT (466G)
34 976770988 - free - (466G)=> 34 1953522988 ada3 GPT (932G)
34 1953522988 1 freebsd-zfs (932G)=> 34 976770988 diskid/DISK-WD-WCAPW5786264 GPT (466G)
34 976770988 - free - (466G)Система полность на ZFS, ada0 и ada1 - это система в программном ZFS зеркале, ada3 - это терабайтный диск для бекапов.
сегодня обратил внимание, что нет свободного места, как итог неработающие сервисы:
# df -h
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 393G 393G 3,6M 100% /
devfs 1,0K 1,0K 0B 100% /dev
zbackup 913G 689G 225G 75% /backup
zroot/jails 3,7M 160K 3,6M 4% /jails
zroot/jails/cloud 2,6G 2,6G 3,6M 100% /jails/cloud
zroot/tmp 3,1G 3,1G 3,6M 100% /tmp
zroot/usr/home 409M 406M 3,6M 99% /usr/home
zroot/usr/ports 7,4G 7,4G 3,6M 100% /usr/ports
zroot/usr/src 1,0G 1,0G 3,6M 100% /usr/src
zroot/var 26G 26G 3,6M 100% /var
zroot/var/crash 1,5G 1,5G 3,6M 100% /var/crash
zroot/var/log 2,6G 2,6G 3,6M 100% /var/log
zroot/var/mail 90M 87M 3,6M 96% /var/mail
zroot/var/tmp 7,4M 3,9M 3,6M 52% /var/tmp
zroot/jails/www 3,0G 3,0G 3,6M 100% /jails/www
devfs 1,0K 1,0K 0B 100% /jails/cloud/dev
devfs 1,0K 1,0K 0B 100% /jails/www/devПоудалял все, что могло занимать место, в частности удалил порты и получил результат:
# df -h
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 404G 392G 12G 97% /
devfs 1,0K 1,0K 0B 100% /dev
zbackup 913G 689G 225G 75% /backup
zroot/jails 12G 160K 12G 0% /jails
zroot/jails/cloud 15G 2,6G 12G 18% /jails/cloud
zroot/tmp 15G 3,1G 12G 20% /tmp
zroot/usr/home 13G 406M 12G 3% /usr/home
zroot/usr/ports 12G 5,2M 12G 0% /usr/ports
zroot/usr/src 13G 1,0G 12G 8% /usr/src
zroot/var 38G 26G 12G 68% /var
zroot/var/crash 14G 1,5G 12G 11% /var/crash
zroot/var/log 15G 2,6G 12G 18% /var/log
zroot/var/mail 12G 87M 12G 1% /var/mail
zroot/var/tmp 12G 3,9M 12G 0% /var/tmproot@web:/ # du -sh *
8,5K COPYRIGHT
689G backup
6,8M bhyve
1,4M bin
891M boot
198M compat
4,0K dev
129K devd.core
4,5K entropy
3,1M etc
512B home
33G iso
2,6G jails
9,8M lib
261K libexec
8,5K media
8,5K mnt
65K nfsd.core
53K ntpd.core
26K opt
8,5K proc
5,8M rescue
4,7G root
21K rpcbind.core
6,8M sbin
512B sys
3,1G tmp
35G usr
30G var
49G vbox
65K vsftpd.coreКак я понимаю, корень занимает аж 392Гб, но где они, эти 392Гб, и что это занимает столько места, никак не могу понять...
Прошу помощи в поисках граблей, которые сожрали 200Гб места.
>Прошу помощи в поисках граблей, которые сожрали 200Гб места.Перезагрузите сервер, а потом покажите # df -h.
>>Прошу помощи в поисках граблей, которые сожрали 200Гб места.
> Перезагрузите сервер, а потом покажите # df -h.Уже делал так и не раз:(
# df -h
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 404G 392G 12G 97% /
devfs 1,0K 1,0K 0B 100% /dev
zbackup 913G 689G 225G 75% /backup
zroot/jails 12G 152K 12G 0% /jails
zroot/jails/cloud 15G 2,6G 12G 17% /jails/cloud
zroot/tmp 15G 3,1G 12G 20% /tmp
zroot/usr/home 13G 406M 12G 3% /usr/home
zroot/usr/ports 12G 3,1M 12G 0% /usr/ports
zroot/usr/src 13G 1,0G 12G 8% /usr/src
zroot/var 38G 26G 12G 68% /var
zroot/var/crash 14G 1,5G 12G 11% /var/crash
zroot/var/log 15G 2,6G 12G 18% /var/log
zroot/var/mail 12G 87M 12G 1% /var/mail
zroot/var/tmp 12G 4,0M 12G 0% /var/tmp
devfs 1,0K 1,0K 0B 100% /jails/cloud/dev
>>Прошу помощи в поисках граблей, которые сожрали 200Гб места.
> Перезагрузите сервер, а потом покажите # df -h.Я понимаю, для особо утончённого развлечения можно и сервис-пак посоветовать переставить.
Может, начать с перезапуска apache-а и syslog-а?
---
Хотя, конечно, хлопотно, через форум, да без всякой надежды на взаимность от ТС-а, не нашедшего
http://www.freebsd.org.ru/FAQ/disks.html#DU-VS-DF
https://www.freebsd.org/doc/faq/disks.html#du-vs-df
и предыдущие (много!) темы в этом форуме про то же самое.А я вот в похожих случаях пользую [что-то вроде!] -
# lsof |awk '$4=="DEL"' |lessНо у меня GNU, bash и ядро, лицензиея и 60-летняя история -- всё совсем не такое, как в этой теме. Позтому не буду утверждать, что здесь надо именно так.
--
ТС, я вижу, без взаимности уже вернулся... Кстати, во времена DOS-а (да, MS-) место терялось ещё и в "потерянных" кластерах. Надо бы ещё chkdsk ака fsck посоветовать, но... на ZFS всё, точно-точно, окажется совсем не так. :S
>>>Прошу помощи в поисках граблей, которые сожрали 200Гб места.
>> Перезагрузите сервер, а потом покажите # df -h.
> Я понимаю, для особо утончённого развлечения можно и сервис-пак посоветовать переставить.Очень смешно:-D
> Может, начать с перезапуска apache-а и syslog-а?
Apache отключался и перезагружался, т.к. я менял некоторые настройки.
А syslog при чем?!>[оверквотинг удален]
> А я вот в похожих случаях пользую [что-то вроде!] -
> # lsof |awk '$4=="DEL"' |less
> Но у меня GNU, bash и ядро, лицензиея и 60-летняя история --
> всё совсем не такое, как в этой теме. Позтому не буду
> утверждать, что здесь надо именно так.
> --
> ТС, я вижу, без взаимности уже вернулся... Кстати, во времена DOS-а (да,
> MS-) место терялось ещё и в "потерянных" кластерах. Надо бы ещё
> chkdsk ака fsck посоветовать, но... на ZFS всё, точно-точно, окажется
> совсем не так. :SКоллега. Я погуглил этот вопрос и потому обратился к всем вам...
Но данные df и du не могут отличаться аж на 200Гб
>>>>Прошу помощи в поисках граблей, которые сожрали 200Гб места.Кстати, снапшоты, манифесты^WMFT-ы, ADS-ы, расширенные атрибуты, альтернативно одарённые потоки, скрытые "папки" -- мало ли какой бесовщины туда понавложали?! Окропление святой водой не рассматривается?
Не, я серьёзно. duckduckgo://zfs where free space gone
даёт километры и килограмы ссылок. С этим явно что-то нечисто!http://superuser.com/questions/661205/removing-files-on-zfs-...
""The output from the df -g command must be interpreted differently for ZFS than other file systems."" --http://docs.oracle.com/cd/E19253-01/819-5461/gbchp/index.html
Замуровали демоны.
>>> Перезагрузите сервер, а потом покажите # df -h.
>> Я понимаю, для особо утончённого развлечения можно и сервис-пак посоветовать переставить.
> Очень смешно:-D
>> Может, начать с перезапуска apache-а и syslog-а?
> Apache отключался и перезагружался, т.к. я менял некоторые настройки.
> А syslog при чем?!Он номер два в моём Личном Списке подозреваемых: он тоже внезапно! пишет логи, которые кто-то мог удалить.
>>[оверквотинг удален]
> Коллега. Я погуглил этот вопрос и потому обратился к всем вам...
> Но данные df и du не могут отличаться аж на 200ГбДа, конечно! И перезагружался же уже. Найди chkdsk.exe или scandisk.exe -- может, помогут. Только обязательно из правильного сервис-пака.
++
Ещё (да-да! со времён того же DOS-а): хвосты кластеров и много (на 200Гб - МНО-О-О-ОГО!) мелких файлов. Хотя, du этому обучен, вроде, должен быть. Но ведь ZFS - Прогресс. "А вдруг?!" Стереть порты?...
> Доброго всем здравия коллеги.
> Обращаюсь к вам с вопросом, т.к. сам уже не могу понять, что
> происходит.# man zfs -> см list (zfs list -o space [-t]) quotas, reservations, snapshots
- remove oldest snaphot
- remove unwanted files ( use echo|cat|dd to empty logs or unwanted files)
>> Доброго всем здравия коллеги.
>> Обращаюсь к вам с вопросом, т.к. сам уже не могу понять, что
>> происходит.
> # man zfs -> см list (zfs list -o space [-t]) quotas,
> reservations, snapshots
> - remove oldest snaphot
> - remove unwanted files ( use echo|cat|dd to empty logs or unwanted
> files)Все бы хорошо коллега, но увы, снепшотов нет:(
> Все бы хорошо коллега, но увы, снепшотов нет:(Ну так приведите zfs list -t snapshot
>> Все бы хорошо коллега, но увы, снепшотов нет:(
> Ну так приведите zfs list -t snapshot+ zfs list -o space
>>> Все бы хорошо коллега, но увы, снепшотов нет:(
>> Ну так приведите zfs list -t snapshot
> + zfs list -o space# zfs list -t snapshot
no datasets available
# zfs list -o space
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
zbackup 290G 623G 0 623G 0 2,84M
zroot 43,4G 398G 0 144K 0 398G
zroot/ROOT 43,4G 355G 0 144K 0 355G
zroot/ROOT/default 43,4G 355G 0 355G 0 0
zroot/jails 43,4G 3,38G 0 160K 0 3,38G
zroot/jails/cloud 43,4G 2,59G 0 2,59G 0 0
zroot/jails/www 43,4G 809M 0 809M 0 0
zroot/tmp 43,4G 3,14G 0 3,14G 0 0
zroot/usr 43,4G 3,90G 0 144K 0 3,90G
zroot/usr/home 43,4G 406M 0 406M 0 0
zroot/usr/ports 43,4G 2,45G 0 2,45G 0 0
zroot/usr/src 43,4G 1,05G 0 1,05G 0 0
zroot/var 43,4G 31,8G 0 29,9G 0 2,00G
zroot/var/crash 43,4G 1,89G 0 1,89G 0 0
zroot/var/log 43,4G 99,8M 0 99,8M 0 0
zroot/var/mail 43,4G 2,18M 0 2,18M 0 0
zroot/var/tmp 43,4G 8,88M 0 8,88M 0 0
Коллеги. Неужели ни у кого не возникает никаких мыслей и идей по этому поводу?!
Ну не могли же просто в никуда деться 355 Гб дискового пространства...
Покажите zpool get freeing
у меня както 600 мб зависло в состоянии freeing> Коллеги. Неужели ни у кого не возникает никаких мыслей и идей по
> этому поводу?!
> Ну не могли же просто в никуда деться 355 Гб дискового пространства...
> Покажите zpool get freeing
> у меня както 600 мб зависло в состоянии freeing
>> Коллеги. Неужели ни у кого не возникает никаких мыслей и идей по
>> этому поводу?!
>> Ну не могли же просто в никуда деться 355 Гб дискового пространства...# zpool get freeing
NAME PROPERTY VALUE SOURCE
zbackup freeing 0 default
zroot freeing 0 default
колдунство какое то
остается только отмонтировать/примонтировать все файловые системы по очереди
сделать scrub
и написать разработчикам
>[оверквотинг удален]
>> у меня както 600 мб зависло в состоянии freeing
>>> Коллеги. Неужели ни у кого не возникает никаких мыслей и идей по
>>> этому поводу?!
>>> Ну не могли же просто в никуда деться 355 Гб дискового пространства...
> # zpool get freeing
> NAME PROPERTY VALUE SOURCE
> zbackup freeing 0
> default
> zroot freeing 0
> default
>[оверквотинг удален]
>>> у меня както 600 мб зависло в состоянии freeing
>>>> Коллеги. Неужели ни у кого не возникает никаких мыслей и идей по
>>>> этому поводу?!
>>>> Ну не могли же просто в никуда деться 355 Гб дискового пространства...
>> # zpool get freeing
>> NAME PROPERTY VALUE SOURCE
>> zbackup freeing 0
>> default
>> zroot freeing 0
>> defaultВот о том и речь. Но чудес-то не бывает. Где это место, мне не понятно:(
scrub делал, для всех разделов, толку нет:( Clean тоже делал, результат отсутсвует:(
Конечно можно как вариант все заново накатить, раз уж я еще хотел совместить с заменой матери, но блин...
Была у нас подобная хрень на соляре пару лет назад.Это все безумный zfs.
Открывали case в Оракле и Sun'техники посоветовали таким образом считать занятое/свободное пространство на FS:
zfs get -rHp all zroot | grep usedbydataset | awk '{ SUM += $3} END { print SUM/1024/1024}'
zfs get -rHp all zroot | grep usedbyrefreservation | awk '{ SUM += $3} END { print SUM/1024/1024 }'
zpool listРешили проблему переносом файловых систем LDOM'ов на дисковый массив и удалением левых датасетов на локальных дисках.
Бесполезный совет:
Если есть возможность избавляйся от ZFS в пользу UFS.>[оверквотинг удален]
>>> NAME PROPERTY VALUE SOURCE
>>> zbackup freeing 0
>>> default
>>> zroot freeing 0
>>> default
> Вот о том и речь. Но чудес-то не бывает. Где это место,
> мне не понятно:(
> scrub делал, для всех разделов, толку нет:( Clean тоже делал, результат отсутсвует:(
> Конечно можно как вариант все заново накатить, раз уж я еще хотел
> совместить с заменой матери, но блин...
>[оверквотинг удален]
> Это всё неграмотные лошары типа вас :)
>> zfs get -rHp all zroot | grep usedbyrefreservation | awk '{ SUM
> То есть вы не фффтыкнули что это за зверёк такой - "refreservation",
> но применить его посчитали абсолютно необходимым, не ну круто же, пацаны
> заценят :)
> Вопрос к топик стартеру - у тебя такое юзается?
>> Бесполезный совет:
>> Если есть возможность избавляйся от ZFS в пользу UFS.
> Бесполезный ответ - раз люди пошли в ZFS, это "жу-жу" - не
> с проста. А стало быть - нет такой возможности.Я почитал что есть "refreservation" и что он делает, отвечу на ваш вопрос: Нет, не юзается:
# zfs get refreservation zroot
NAME PROPERTY VALUE SOURCE
zroot refreservation none default
>[оверквотинг удален]
>>> Бесполезный совет:
>>> Если есть возможность избавляйся от ZFS в пользу UFS.
>> Бесполезный ответ - раз люди пошли в ZFS, это "жу-жу" - не
>> с проста. А стало быть - нет такой возможности.
> Я почитал что есть "refreservation" и что он делает, отвечу на ваш
> вопрос: Нет, не юзается:
> # zfs get refreservation zroot
> NAME PROPERTY VALUE
> SOURCE
> zroot refreservation none defaultВ дополнение к предыдущему посту, покажу результат вывода его команд:
# zfs get -rHp all zroot | grep usedbydataset | awk '{ SUM += $3} END { print SUM/1024/1024}'
404840
# zfs get -rHp all zroot | grep usedbyrefreservation | awk '{ SUM += $3} END { print SUM/1024/1024 }'
0
# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
zbackup 928G 649G 279G 69% 1.00x ONLINE -
zroot 448G 395G 52,6G 88% 1.00x ONLINE -Правда зачем, сам не понимаю, тут и так все понятно.
Я пытаюсь понять и не могу: занято пространство, значит должны быть какие-то данные, которые можно найти, но найти эти данные, для последующего уничтожения не могу.
> Правда зачем, сам не понимаю, тут и так все понятно.
> Я пытаюсь понять и не могу: занято пространство, значит должны быть какие-то
> данные, которые можно найти, но найти эти данные, для последующего уничтожения
> не могу.скрытые файлы
du -sh .*
или файлы в смонтированном катологе
/usr/home
например
>> Правда зачем, сам не понимаю, тут и так все понятно.
>> Я пытаюсь понять и не могу: занято пространство, значит должны быть какие-то
>> данные, которые можно найти, но найти эти данные, для последующего уничтожения
>> не могу.
> скрытые файлы
> du -sh .*
> или файлы в смонтированном катологе
> /usr/home
> напримерУвы. Не все так просто:
# du -sh .*
825G .
825G ..
2,3M .eaccelerator.tmpно мало того, .zfs не отобразило, в то время как:
# du -sh .zfs
8,5K .zfs
> В дополнение к предыдущему посту, покажу результат вывода его команд:
> # zfs get -rHp all zroot | grep usedbydataset | awk '{
> SUM += $3} END { print SUM/1024/1024}'
> 404840То есть 404840 мегабайт. Если поделить 404840 на 1024 получается как раз 395.35 гигабайт.
То есть получается, что прямое суммирование занятого места по всем датасетам даёт ту же величину, что и вывод zpool list.Дальше можно укоротить команду до
zfs get -rHp all zroot | grep usedbydataset
и посмотреть, какие датасеты занимают много места.
>[оверквотинг удален]
>> # zfs get -rHp all zroot | grep usedbydataset | awk '{
>> SUM += $3} END { print SUM/1024/1024}'
>> 404840
> То есть 404840 мегабайт. Если поделить 404840 на 1024 получается как раз
> 395.35 гигабайт.
> То есть получается, что прямое суммирование занятого места по всем датасетам даёт
> ту же величину, что и вывод zpool list.
> Дальше можно укоротить команду до
> zfs get -rHp all zroot | grep usedbydataset
> и посмотреть, какие датасеты занимают много места.дело в том, что уже понятно на каком датасете занято место, но вот вывод:
# zfs get -rHp all zroot | grep usedbydataset
zroot usedbydataset 147456 -
zroot/ROOT usedbydataset 147456 -
zroot/ROOT/default usedbydataset 381276020736 -
zroot/jails usedbydataset 163840 -
zroot/jails/cloud usedbydataset 2787168256 -
zroot/jails/www usedbydataset 852393984 -
zroot/tmp usedbydataset 3364298752 -
zroot/usr usedbydataset 147456 -
zroot/usr/home usedbydataset 425463808 -
zroot/usr/ports usedbydataset 1902833664 -
zroot/usr/src usedbydataset 1122840576 -
zroot/var usedbydataset 29531144192 -
zroot/var/crash usedbydataset 2585751552 -
zroot/var/log usedbydataset 491827200 -
zroot/var/mail usedbydataset 13787136 -
zroot/var/tmp usedbydataset 9691136 -Это zroot/ROOT/default
Собственно он и монтируется к корню. Но, выше я выкладывал содержимое всего корня и его листинг...
Вот и не могу понять где грабли:(
> Вот и не могу понять где грабли:(У файловых систем есть ещё свойство copies, чтобы каждый файл в нескольких экземплярах хранить. Может оно больше единицы? Можно проверить так:
zfs get -rHp all zroot | grep copies
>> Вот и не могу понять где грабли:(
> У файловых систем есть ещё свойство copies, чтобы каждый файл в нескольких
> экземплярах хранить. Может оно больше единицы? Можно проверить так:
> zfs get -rHp all zroot | grep copiesДа нет. все норм:
# zfs get -rHp all zroot | grep copies
zroot copies 1 default
zroot/ROOT copies 1 default
zroot/ROOT/default copies 1 default
zroot/jails copies 1 default
zroot/jails/cloud copies 1 default
zroot/jails/www copies 1 default
zroot/tmp copies 1 default
zroot/usr copies 1 default
zroot/usr/home copies 1 default
zroot/usr/ports copies 1 default
zroot/usr/src copies 1 default
zroot/var copies 1 default
zroot/var/crash copies 1 default
zroot/var/log copies 1 default
zroot/var/mail copies 1 default
zroot/var/tmp copies 1 default
> Вот и не могу понять где грабли:(Ещё одна идея: может быть свойство reservation включено на маленьких файловых системах, типа /var/tmp. В результате имеется свободное место, но оно для них зарезервировано.
>> Вот и не могу понять где грабли:(
> Ещё одна идея: может быть свойство reservation включено на маленьких файловых системах,
> типа /var/tmp. В результате имеется свободное место, но оно для них
> зарезервировано.Увы нет.:(
ну я думаю, "Забить", т.к. все равно планирую переделывать, ставить виртуализацию и разворачивать то что нужно уже на виртуозках. Сейчас вот только мечусь между выбором XEN или KVM.
Не знаю ни тот ни другой. Нужны поддержка всех ОС, глубокие настройки ВМ, желательно вплоть до частоты процессора, ну и естественно максимальная производительность, какая только возможна:)Но огромное спасибо за участие:)
Я вот решил посмотреть на SmartOS пока лето и есть время. Поэтому ZFS у меня есть и мне интересно, что с ней может быть не так.Я всё-таки хотел бы ещё спросить. Что будет корнем, если отмонтировать пул? В SmartOS корень это ramdisk, из пула некоторые директории цепляются к дереву директорий. А в BSD я не совсем понимаю, как это устроено.
У SmartOS, кстати, kvm есть. Но только для интеловских процессоров, да и то не для всех. Ему нужна Virtualization Technology eXtensions (VT-x) and Extended Page Tables (EPT a.k.a. Intel VT-X with Extended Page Tables)
И ещё, для полноты картины.
used property = usedbychildren + usedbydataset + usedbyrefreservation + usedbysnapshotsВ Вашем случае used и usedbydataset, насколько я понимаю одинаковые. Тем не менее ещё скажу про ранее не упомянутую опцию для файловых систем refreservation, которая как reservation, определяет минимальную потребность в дисковом пространстве для данной файловой системы, только не включает снапшоты и клоны.
Это из Oracle® Solaris ZFS Administration Guide
dd if=/dev/zero of=/BIGZERO; sync; rm /BIGZERO; sync; df /;?
>dd if=/dev/zero of=/BIGZERO; sync; rm /BIGZERO; sync; df /;
> ?Это заполняем все свободное пространство, потом удаляем?!
>>dd if=/dev/zero of=/BIGZERO; sync; rm /BIGZERO; sync; df /;
>> ?
> Это заполняем все свободное пространство, потом удаляем?!ага
По файликам что говорит?
find / -noleaf -xdev -type f -printf "%6k\n" | awk '{s+=$1} END {print s" kb"}'
> По файликам что говорит?
>
> find / -noleaf -xdev -type f -printf "%6k\n" | awk '{s+=$1} END
> {print s" kb"}'
>Немного не понимаю смысл:(
и у find во FreeBSD нет ключа -printf:(
>> По файликам что говорит?
>>
>> find / -noleaf -xdev -type f -printf "%6k\n" | awk '{s+=$1} END
>> {print s" kb"}'
>>
> Немного не понимаю смысл:(сумму размеров файлов считает.
> и у find во FreeBSD нет ключа -printf:(
печалька, вроде noleaf тоже не было.
>>> По файликам что говорит?
>>>
>>> find / -noleaf -xdev -type f -printf "%6k\n" | awk '{s+=$1} END
>>> {print s" kb"}'
>>>
>> Немного не понимаю смысл:(
> сумму размеров файлов считает.
>> и у find во FreeBSD нет ключа -printf:(
> печалька, вроде noleaf тоже не было.Увы да:(
Заполнение свободного места ничего не дало. При этом всем, так получилось, что 62 свободные Гб забило быстро, буквально за пол часа наверное, а вот последующее место, очень долго. за почти 4 часа даже 1 Гб не записался.
При этом, файл был правильного размера, 62,2Гб и свободно 7,8Гб.
В общем, плюнул, остановил, почистил и пускай дальше работает.
> В общем, плюнул, остановил, почистил и пускай дальше работает.Извините за навязчивость.
Не очень ясно получилось оформить мысль, которая в голове крутилась. Всё-таки попробую сформулировать вопрос ещё раз, более коротко и прямолинейно.Не может такого быть, что под примонтированными файловыми системами содержатся данные? В этом случае команда du их не видит, а место они занимают.
И в дополнение. Ещё есть хорошая команда, которая позволяет посмотреть все свойства, всех файловых систем, установленные локально. Что в данном случае означает, отличающиеся от дефолтных и не унаследованные.
zfs get -s local allИ ещё одна команда, которая может быть что-то способна прояснить --- полный лог всех изменений в пуле:
zpool history
> В общем, плюнул, ...В single mode, отмонтировал бы остальные разделы, оставил только корень и изучал бы.
У меня есть подозрение на некое перекрёстное монтирование.
> Заполнение свободного места ничего не дало. При этом всем, так получилось, что
> 62 свободные Гб забило быстро, буквально за пол часа наверное, а апример
> вот последующее место, очень долго. за почти 4 часа даже 1
> Гб не записался.при использовании dd указывый bs, например устанавливай его в 1m.
покажи du -xhd1 /
>> Заполнение свободного места ничего не дало. При этом всем, так получилось, что
>> 62 свободные Гб забило быстро, буквально за пол часа наверное, а апример
>> вот последующее место, очень долго. за почти 4 часа даже 1
>> Гб не записался.
> при использовании dd указывый bs, например устанавливай его в 1m.
> покажи du -xhd1 /Вот. забавный результат:
# du -xhd1 /
289K /libexec
1,4M /bin
32G /usr
33G /iso
1,3G /root
8,5K /proc
8,5K /media
3,4M /etc
2,3M /.eaccelerator.tmp
1,5K /backup
1,0G /boot
10M /lib
7,9M /rescue
12G /vbox
1,2M /tmp
8,5K /mnt
7,0M /sbin
8,5K /opt
512B /dev
8,5K /var
198M /compat
8,5K /jails
79G /
где блин 270Гб?! Ума не приложу:(
круто, покажи еще:
zfs list -o name,used,quota,reservation,compression,compressratio,checksum,copies,usedbysnapshots,refreservation,refquota,usedbychildren,usedbydataset,usedbyrefreservation,userrefs,written zroot/ROOT/defaultи
ls -aR /.zfs/
> круто, покажи еще:
> zfs list -o name,used,quota,reservation,compression,compressratio,checksum,copies,usedbysnapshots,refreservation,refquota,usedbychildren,usedbydataset,usedbyrefreservation,userrefs,written
> zroot/ROOT/default
> и
> ls -aR /.zfs/
# zfs list -o name,used,quota,reservation,compression,compressratio,checksum,copies,usedbysnapshots,refreservation,refquota,usedbychildren,usedbydataset,usedbyrefreservation,userrefs,written zroot/ROOT/default
NAME USED QUOTA RESERV COMPRESS RATIO CHECKSUM COPIES USEDSNAP REFRESERV REFQUOTA USEDCHILD USEDDS USEDREFRESERV USERREFS WRITTEN
zroot/ROOT/default 350G none none off 1.00x on 1 0 none none 0 350G 0 - 350G
и
# ls -aR /.zfs/
. .. shares snapshot/.zfs/shares:
. ../.zfs/snapshot:
. ..
да, проблема похожа на реальную... кроме скраба - фиг знает, что делать
а что zdb -bb говорит?
> а что zdb -bb говорит?Честно говоря, я не знаю что сделать с этими данными:
<code>
367G completed ( 701MB/s) estimated time remaining: 0hr 00min 00sec leaked space: vdev 0, offset 0xb407000, size 16384
leaked space: vdev 0, offset 0xb463000, size 16384
leaked space: vdev 0, offset 0xd8a9b000, size 12288
leaked space: vdev 0, offset 0x57ee4000, size 16384
leaked space: vdev 0, offset 0x4475d000, size 16384
leaked space: vdev 0, offset 0x108d7f000, size 16384
leaked space: vdev 0, offset 0x12bc8b000, size 16384
leaked space: vdev 0, offset 0x13b3df000, size 16384
leaked space: vdev 0, offset 0x122b58000, size 16384
leaked space: vdev 0, offset 0x6a84dd000, size 12288
leaked space: vdev 0, offset 0x125c31d000, size 12288
leaked space: vdev 0, offset 0x1208233000, size 16384
leaked space: vdev 0, offset 0x1305b2f000, size 24576
leaked space: vdev 0, offset 0x135fd05000, size 16384
leaked space: vdev 0, offset 0x1a18375000, size 16384
leaked space: vdev 0, offset 0x1a1d73a000, size 16384
leaked space: vdev 0, offset 0x1a19398000, size 16384
leaked space: vdev 0, offset 0x1a6a60f000, size 12288
leaked space: vdev 0, offset 0x1a847a1000, size 20480
leaked space: vdev 0, offset 0x1aadc0d000, size 12288
leaked space: vdev 0, offset 0x1a731f0000, size 12288
leaked space: vdev 0, offset 0x1a1daa6000, size 16384
leaked space: vdev 0, offset 0x1c13ed5000, size 16384
leaked space: vdev 0, offset 0x1c38ad2000, size 12288
leaked space: vdev 0, offset 0x1c45b6d000, size 16384
leaked space: vdev 0, offset 0x1c365f5000, size 12288
leaked space: vdev 0, offset 0x1cf6747000, size 12288
leaked space: vdev 0, offset 0x1cece89000, size 12288
leaked space: vdev 0, offset 0x1ca10ac000, size 12288
leaked space: vdev 0, offset 0x22000b7000, size 12288
leaked space: vdev 0, offset 0x2327554000, size 12288
leaked space: vdev 0, offset 0x23399c2000, size 12288
leaked space: vdev 0, offset 0x2331ce6000, size 12288
leaked space: vdev 0, offset 0x260591a000, size 12288
leaked space: vdev 0, offset 0x2613b6b000, size 16384
leaked space: vdev 0, offset 0x260c38f000, size 16384
leaked space: vdev 0, offset 0x26e875b000, size 12288
leaked space: vdev 0, offset 0x2697bb6000, size 12288
leaked space: vdev 0, offset 0x2638fd8000, size 12288
leaked space: vdev 0, offset 0x2705e85000, size 16384
leaked space: vdev 0, offset 0x27103a7000, size 16384
leaked space: vdev 0, offset 0x27101ec000, size 16384
leaked space: vdev 0, offset 0x2705ee6000, size 16384
leaked space: vdev 0, offset 0x27766b6000, size 12288
leaked space: vdev 0, offset 0x271ace6000, size 12288
leaked space: vdev 0, offset 0x271550e000, size 12288
leaked space: vdev 0, offset 0x2801674000, size 16384
leaked space: vdev 0, offset 0x2801362000, size 16384
leaked space: vdev 0, offset 0x28080ff000, size 16384
leaked space: vdev 0, offset 0x28525e1000, size 12288
leaked space: vdev 0, offset 0x283cd7c000, size 12288
leaked space: vdev 0, offset 0x2826a6a000, size 12288
leaked space: vdev 0, offset 0x2803bb0000, size 16384
leaked space: vdev 0, offset 0x2a1260c000, size 16384
leaked space: vdev 0, offset 0x2aff92a000, size 20480
leaked space: vdev 0, offset 0x2a567e0000, size 12288
leaked space: vdev 0, offset 0x2a3822e000, size 16384
leaked space: vdev 0, offset 0x2e005e1000, size 16384
leaked space: vdev 0, offset 0x2e4b034000, size 12288
leaked space: vdev 0, offset 0x2e31b56000, size 8192
leaked space: vdev 0, offset 0x3006cec000, size 16384
leaked space: vdev 0, offset 0x30098e0000, size 12288
leaked space: vdev 0, offset 0x3008808000, size 16384
leaked space: vdev 0, offset 0x307457d000, size 12288
leaked space: vdev 0, offset 0x3044e70000, size 12288
leaked space: vdev 0, offset 0x3626083000, size 16384
leaked space: vdev 0, offset 0x362eebd000, size 12288
leaked space: vdev 0, offset 0x3627054000, size 20480
leaked space: vdev 0, offset 0x3663889000, size 12288
leaked space: vdev 0, offset 0x36ab0b3000, size 12288
leaked space: vdev 0, offset 0x36cbcd2000, size 12288
leaked space: vdev 0, offset 0x368fbf5000, size 12288
leaked space: vdev 0, offset 0x365d09e000, size 12288
leaked space: vdev 0, offset 0x3b10ea4000, size 16384
leaked space: vdev 0, offset 0x3b7cf19000, size 12288
leaked space: vdev 0, offset 0x3b6f213000, size 12288
leaked space: vdev 0, offset 0x3d4f7c9000, size 12288
leaked space: vdev 0, offset 0x3d0063b000, size 16384
leaked space: vdev 0, offset 0x3f07638000, size 8192
leaked space: vdev 0, offset 0x3fd7270000, size 12288
leaked space: vdev 0, offset 0x3fbab86000, size 12288
leaked space: vdev 0, offset 0x5203561000, size 16384
block traversal size 394363428864 != alloc 394364608512 (leaked 1179648)bp count: 4667001
ganged count: 129042
bp logical: 404707126272 avg: 86716
bp physical: 388077384704 avg: 83153 compression: 1.04
bp allocated: 394363428864 avg: 84500 compression: 1.03
bp deduped: 0 ref>1: 0 deduplication: 1.00
SPA allocated: 394364608512 used: 81.98%
Dittoed blocks on same vdev: 374898Blocks LSIZE PSIZE ASIZE avg comp %Total Type
- - - - - - - unallocated
2 32K 8K 24.0K 12.0K 4.00 0.00 object directory
2 1K 1K 24.0K 12.0K 1.00 0.00 object array
1 16K 4K 12.0K 12.0K 4.00 0.00 packed nvlist
- - - - - - - packed nvlist size
1 16K 4K 12.0K 12.0K 4.00 0.00 bpobj
- - - - - - - bpobj header
- - - - - - - SPA space map header
1.85K 8.70M 7.39M 44.9M 24.3K 1.18 0.01 SPA space map
13 728K 728K 728K 56.0K 1.00 0.00 ZIL intent log
59.7K 956M 243M 487M 8.15K 3.94 0.13 DMU dnode
17 34.0K 34.0K 140K 8.23K 1.00 0.00 DMU objset
- - - - - - - DSL directory
19 10.0K 10.0K 228K 12.0K 1.00 0.00 DSL directory child map
17 8.50K 8.50K 204K 12.0K 1.00 0.00 DSL dataset snap map
26 230K 62.0K 312K 12.0K 3.71 0.00 DSL props
- - - - - - - DSL dataset
- - - - - - - ZFS znode
- - - - - - - ZFS V0 ACL
4.19M 376G 361G 365G 87.1K 1.04 99.41 ZFS plain file
202K 269M 178M 1.63G 8.25K 1.51 0.44 ZFS directory
16 16K 16K 128K 8K 1.00 0.00 ZFS master node
214 3.14M 822K 1.68M 8.04K 3.92 0.00 ZFS delete queue
- - - - - - - zvol object
- - - - - - - zvol prop
- - - - - - - other uint8[]
- - - - - - - other uint64[]
- - - - - - - other ZAP
- - - - - - - persistent error log
1 128K 8K 24.0K 24.0K 16.00 0.00 SPA history
- - - - - - - SPA history offsets
1 512 512 12.0K 12.0K 1.00 0.00 Pool properties
- - - - - - - DSL permissions
- - - - - - - ZFS ACL
- - - - - - - ZFS SYSACL
- - - - - - - FUID table
- - - - - - - FUID table size
1 1.50K 1.50K 12.0K 12.0K 1.00 0.00 DSL dataset next clones
- - - - - - - scan work queue
32 23.0K 23.0K 256K 8K 1.00 0.00 ZFS user/group used
- - - - - - - ZFS user/group quota
- - - - - - - snapshot refcount tags
- - - - - - - DDT ZAP algorithm
- - - - - - - DDT statistics
- - - - - - - System attributes
16 8K 8K 128K 8K 1.00 0.00 SA master node
16 24.0K 24.0K 128K 8K 1.00 0.00 SA attr registration
32 512K 128K 256K 8K 4.00 0.00 SA attr layouts
- - - - - - - scan translations
- - - - - - - deduplicated block
18 9.00K 9.00K 216K 12.0K 1.00 0.00 DSL deadlist map
- - - - - - - DSL deadlist map hdr
1 1.50K 1.50K 12.0K 12.0K 1.00 0.00 DSL dir clones
- - - - - - - bpobj subobj
14 164K 56.0K 168K 12.0K 2.93 0.00 deferred free
- - - - - - - dedup ditto
4 33.0K 9.00K 48.0K 12.0K 3.67 0.00 other
4.45M 377G 361G 367G 82.5K 1.04 100.00 Total
</code>
>> а что zdb -bb говорит?
> Честно говоря, я не знаю что сделать с этими данными:Ох ши ...
Ну и фарш. Навскидку - пробовал ли ты прогнать scrub?
>>> а что zdb -bb говорит?
>> Честно говоря, я не знаю что сделать с этими данными:
> Ох ши ...
> Ну и фарш. Навскидку - пробовал ли ты прогнать scrub?Пробовал, и даже не один раз. Эффекта ноль.