Продолжайте наблюдение.

btrfs - Честно сделал все файлы.

«честно» сделал вид, что сделал файл. Как обычно.

Либо место контролировалось (хотя зачем если фйлы из пустоты)

вообще-то нули != пустота.

А то, что ты делал, не имеет смысла — это нормальное поведение, когда 0/0 == 17. Почему нет? Всё сходится: 0*17 == 0.

«Честно» - там было 10Тб? :)

ну и сто ещё

Я сейчс играюсь с zfs.

Система жесть. Сейчас вот 1.75T Пакуется...
Обычная t процессора = 38
rsync с пакованной zfs на пакованную zfs
Оба ядра процессора заняты на 100%
Сейчас t процессора = 61
#top показывает:
top - 18:23:09 up 6:33, 7 users, load average: 8,87, 6,78, 4,56
Tasks: 717 total, 6 running, 708 sleeping, 0 stopped, 3 zombie
%Cpu0 : 23,3 us, 68,0 sy, 0,0 ni, 6,3 id, 2,3 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu1 : 83,9 us, 7,4 sy, 0,0 ni, 1,0 id, 7,4 wa, 0,0 hi, 0,3 si, 0,0 st
KiB Mem: 8066832 total, 7939452 used, 127380 free, 19136 buffers
KiB Swap: 15622140 total, 13040 used, 15609100 free, 2689936 cached

Тут еще %wa приемлемые. Когда шел синк со включенным дедупом - оно давало до 60 %wa. Впрочем только рестартанул рсинк и ему еще сутки синкаться...

Как показывают циферьки скорость копирования 15Mb/sec что вполне ограничивается скоростью USB интерфейса и упковка gzip-9 в данном случае не тормозит. Процессор успевает за USB. Вот на USB3 уже тормозить будт процессор, шина там спокойно 100Mb/s тянет.

нули не, а seek да.

Смотрим внимательнее:

dd if=/dev/zero of=fs100T.bin bs=1024 count=0 seek=100T

Нулей тут 0 а вот позиция сикается на 100T

Ага.

Там было 10Gb+10Tb+100Tb пустоты, ибо нулей туда не пиалось.
По факту записи (когда скажем форматировал) распределялись блоки и в файлах была рабочая информация.

Место то на диске было, спрашиваю!?

Да не было у него места. EXT4 и JFS честные фс и пишут то что им дали.

Мерси, так бы он и говорил. А ещё лучше указывал в начальных условиях задачи. А то, что остальные ФС втиснули файлы, превосходящие размер пустого места, указывает лишь на некоторый велосипедизм&костылизм в коде оных.

Посыпаю голову пеплом.

Спасибо за обсуждение.
Действительно всё оказалось в малом месте.
Из этих fs только btrfs пишет на диск по мере заполнения.
Остальные «честные» fs честно пишут в индексы при создании
fs и файлы начинают занимать место.
у btrfs раздел даже 5E занимает 5Mb на диске.
У ext4 128T занимают 11G
У jfs 100T занимают 13G
Надо место расчистить и еще раз замер сделать чтоли :)
Посмотреть сколько занимают на диске одинаковые пустые разделы с разными fs.

Спасибо за обсужение!

я видел, что у тебя seek. Молодец. Возьми с полки пирожок. Там два, возьми тот, что посередине.

Надо место расчистить и еще раз замер сделать чтоли

когда коту делать нечего...

Я не кот а маньяк измерятор :)

При нынешних объемах винтов хочется выбрать для хранения всего скраба хорошую fs, чтобы по прошествии времени не не огрести граблей. Лучше на них наступить в тесте а не в бою. Ну и чисто из любознательности хочется знть расход и пределы современных fs.

Пока наступал на грабли с:

btrfs - получал убитую fs от штатных операций типа создания/записи нулей в файлы.

zfs со включенным режимом dedup. Первый опыт - попытка rsync на 1.75Tb zfs раздел с включенной упаковкой gzip-9 и включенным дедупом.
Через 5 дней, 7ч, 51 мин. машина повисла. При дальнейших попытках сделать туда рсинк получил еще несколько повисаний.
Однако в целом наличие компрессии и интересная архитектура очень к ней привлекают. Мне она интересна прежде всего вложенными контейнерами, на которые вроде как и лимиты можно поставить. Например есть раздел - но раздел зовется не /dev/калямаля а по человечески скажем Data и в нем я делаю скажем подразделы DB,DL,Backup,Heap и для каждого раздела могу указать свои параметры. Например архивацию включить лишь для Heap где валяется всё подряд. Ну или для некритичных по времени других разделов.
При этом любой из получившихся разделов можно подмонтировать в свой путь и система это хранит в переменной mountpoint каждого раздела. При загрузке она это честно монтирует куда указано. При этом в любой момент времени сказав #zpool list (ну или df -h) можно получить объем данных для разделов а по #zfs get compressratio Data - получить итоговый процент упаковки.
Ну и при всём этом расходуется место ОДНОГО раздела (в нашем случае это data. А как часто случается что не хватает места на каком то разделе и начинается: «i like to move it, move it...»
Надеюсь что перспективе можно будет грузиться с любого тома zfs. Хотел было сказать что это позволит держать зоопарк систем, но осознал что zfs пока поддерживается лишь в Open Solaris, Linux, BSD. Причем Linux только x64.

В общем пока экспериментирую дальшне. В данный момент на xfs живущей в 100Гб файле на zfs разделе сделан пустой файл размером 1Экзобайт и идет его форматирование под xfs. Система жутко тормозит. Пишу на ощупь. Надеюсь успею это отправить...

Забыл уточнить про btrfs а редактировать нельзя стало пока писал уточнение.

На btrfs я рсинкал реальный раздел со включенной упаковкой (тестировал упаковку btrfs). Тест показал что лучше не надо.

В итоге режим упаковки на Linux пока жизнеспособен лишь на zfs (reiser 4 не пробовал)

Мои тесты пока показали что режим упаковки жизнеспособен пока лишь на zfs, которая и без этого имеет много преимужеств - и реальных и заявленных. Для этой системы отсутствует даже fsck, ибо по заявлению создателей всё под контролем. Есть 3 алгоритма упаковки, в планах еще придумать как оценить и выбрать лучший алгоритм. Впрочем даже если для разного назначения будет свой «лучший» то никто не мешает в zfs создать для каждого назначения свой том со своим алгоритмом, но пространство при этом будет распределяться из общего пула. Пока использую gzip-9 потому что не нужна сорость - просто синкаю на внешний USB hdd основной раздел.

У zfs есть один огромный минус правда несущественный в текущий момент. Она есть лишь для x64 Linux и бэкап можно будет восстановить или подключить лишь на x64 Системе.

Как вариант попробовать x32 BSD и проверить взлетит ли этот раздел там. Если взлетит то получим вещь в себе. Загрузочный x32 BSD на внешнем USB винте который подгрузившись позволит еще и использовать большой упакованный пул. Пока на нем лишь x32 Linux.

Хочешь стабильности - используй ext4/xfs. Сжатие и прочее делай поверх.

Я когда работал со sparsed файлами, то было страшновато подумать что когда-то потом write в средине файла может упасть по нехватке места. Страшно жить!

Оффтоп: NTFS тоже умеет создавать такие файлы :D Но для этого в родительской папке должна быть включена компрессия

zfs

машина повисла

Линукс? У меня было то же самое

Хочешь стабильности - используй ext4/xfs. Сжатие и прочее делай поверх.

Хм. Поверх это как?
По поводу xfs на просторах интернета байки о том что обнуляется если ресетнуть во время записи. Ресетить не собираюсь но zfs устраивала мне локапы при которых SysRq-B не ребутил.
Так что все дороги ведут к ext4. Тем более что и файлы оно создает до 10T включительно, вот 100T не получилось. :)

По поводу xfs на просторах интернета байки о том что обнуляется если ресетнуть во время записи.

Раньше была такая особенность. Сейчас это поправили.

В итоге режим упаковки на Linux пока жизнеспособен лишь на zfs (reiser 4 не пробовал)

reiser4 по факту сжимает лучше всех из-за уникальной фичи «liquid records»

1 Эксабайт по факту таки сделался.

Заняло это 5 часов, 23 минуты и 30 секунд :)
Получившийся раздел монтируется. Вот такой бутерброд:
hdd<->lvm<->zfs-<->xfs(file)<->xfs(1Eb File с xfs в нём).
По факту расход пространства на пустую фс даёт:
#du -sh *
исполненная там где живут файлы. У меня для xfs на xfs оно дало:

11M<--->1G.bin
11M<--->10G.bin
51M<--->100G.bin
513M<-->1T.bin
2,0G<-->10T.bin
2,0G<-->100T.bin
2,1G<-->1P.bin
2,2G<-->10P.bin
3,6G<-->100P.bin
19G<--->1E.bin

Для jfs расход на пустую структуру:

Для jfs расход на пустую fs получился следующим:

4,3M<-->1G.bin
42M<--->10G.bin
141M<-->100G.bin
257M<-->1T.bin
1,4G<-->10T.bin
13G<--->100T.bin

Для ext4 расход на пустую структуру:

Для ext4 расход на пустую fs:

33M<--->1G.bin
131M<-->10G.bin
133M<-->100G.bin
139M<-->1T.bin
210M<-->10T.bin
1,7G<-->100T.bin

btrfs Рекордсмен по экономии расхода на пустую структуру.

btrfs самый экономичный. Файлсистемы готовит не 5 часов (как xfs) а мгновенно расход получается:

4,1M<-->1G.bin
4,1M<-->10G.bin
4,1M<-->100G.bin
4,1M<-->1T.bin
4,1M<-->10T.bin
4,1M<-->100T.bin
4,1M<-->1P.bin
4,1M<-->10P.bin
4,1M<-->100P.bin
4,3M<-->1E.bin

Итого на этом бутерброде максимальные разделы получились:

xfs - 1E
jfs - 100T
ext4 - 100T
btrfs - 1E
Вопрос с нехваткой места сейчас не стоит ибо крайней создавал 1E xfs который занял 19Gb и выполнился успешно, следовательно другие fs отвалившиеся по ошибкам не смогли сделать структуру по другим причинам.
Проверялись размеры кратные 10. Возможно 7.999E получилось бы но после 1E я пробовал 10E файл на xfs.

Мерси, так бы он и говорил. А ещё лучше указывал в начальных >условиях задачи. А то, что остальные ФС втиснули файлы, >превосходящие размер пустого места, указывает лишь на >некоторый велосипедизм&костылизм в коде оных.

В сообщении с которого стартовал топик было написано:

Этот скрипт исполнялся на 10Gb системах смонтированных из файла.

Уы небыло.

Место то на диске было, спрашиваю!?

Впрочем в сообщении с которого стартовал топик были указаны исходные условия.

Вы меня прямо таки озадачили...

Раньше была такая особенность. Сейчас это поправили.

Я уже сделал раздел на jfs.
Банально по скорости:
#find . -type f 2>&1|wc -l
она быстрее xfs
4.5сек против 12 (отмонтировал перед измерением чтобы сбросить кэши)
С jfs тоже возникла странность. Изначально это был 500Gb раздел, я добавил к lvm разделу еще 250Gb и устроил онлайн
ресайз до 750. После этого оно показало по #df -h:
/dev/mapper/st3t-bkp 749G 446G 304G 60% /opt/bkp
Я всё рсинкнул на временный, форматнул в xfs и оно дало:
/dev/mapper/st3t-bkp 749G 531G 218G 71% /opt/bkp
Мне не понравилось что стало занимать 531 вместо 446 на jfs и я решил откатиться. Но в итоге получил:
/dev/mapper/st3t-bkp 749G 531G 218G 71% /opt/bkp

Откуда растут ноги у этой странности не понимаю.

Но вот для xfs есть defrag а для jfs нет. Но jfs Ресайзится в онлайне :)

Сабж. Прямо уж и не знаю на чем остановиться....
Хотя есть еще ext4 :)

Впрочем, с какого перепою ты тогда пишешь, что другие ФС не справились с задачей? Тебе обладатель гуманитарной какой профессии причинил неудобство твоим гениталиям?

Нашел откуда растут ноги.

Откуда растут ноги у этой странности не понимаю.

Нашел. При рсинке ошибся а когда заметил прервал надесь что новый рсинк всё лишнее удалит. Но оказывается

rsync src/* dst --delete нифига не всё удляет в dst
а вот cd src;rsync . ../dst удаляет всё.

Про xfs вы писали:

Раньше была такая особенность. Сейчас это поправили.

Как удалось найти - попрвлено это в Ядре 3.3
XFS: the filesystem of the future?
Новость првда от 20 янвря 2012... Сейчас на дворе Октябрь 2013 а в Debian Wheezy штатное 3.2.0

До сих пор я не осознавал такой разрыв времени...

Впрочем видел еще упомянание о том что у человека 22Tb в RAID6 и он на 4Gb памяти не смог запустить xfs_check - тот падал по аут оф мемори.