> Смешанный.Может означать все что угодно. Однако нехило бы описать что и как измерялось, по сравнению с чем, и указать какие-то детали.
>> Это расплата за продвинутый дизайн и удобный менеджмент
> Не знать, сколько _реально_ в FS осталось свободного места - это да,
Ды ты в современной системе и сколько RAM свободной - де факто не знаешь. Можешь посмотреть как в линухе аллокация памяти сделана по дефолту, с оверкомитом и проч. Идея кстати примерно та же самая. Но ты конечно можешь у себя отрубить оверкомит... только тогда сильно меньше программ сможешь запускать при прочих равных. Почему-то.
А прикинь, файлуха может не знать заранее что я рефлинкну вон тот 3-терабайтный образ. Смотри, мы начинаем с 3Тб файлом и 5Тб хранилкой. Вроде бы 2 Тб места примерно. Делаем пару рефлинканутых "копий". Опа, у нас как бы 9 терабайт - на 5 тер места. Реально конечно там 3 терабайта + отличия. Но де факто это оверкомит и "оверселл". И откуда б заранее знать насколько рефлинкнутые копии разъедутся? Захотят - станут независимые. Или останутся почти идентичными. С сжатием - аналогично. И так далее.
> мегаудобнейший дизайн и наиэффективнейший менеджмент. Честно - одна из самых веских
> причин обходить стороной.
Ну да, ну да, в бак с топливом "боинга" на лету неудобно светить фонариком и оценивать на глаз, приходится датчикам доверять, плюс-минус цать литров.
Ващет файлухи на 100% забивать - не очень удачная идея в целом из-за жуткой фрагментации. Так что в нормальном случае это не проблема. При том если btrfs после этого можно попробовать отдефрагать, в случае сабжа - получится убер-тормозной пул с которым вообще хз что делать. Но вообще-то такая же фигня даже и из ext4 и xfs получается. У ext4 даже дефраг есть но он видите ли не умеет агрегацию свободного места и вообще базовый весьма.
А, да, EXT4 кстати - вообще идиотская ФС. Например совсем не умеет деаллокацию директорий. Если в дире одно время отращивалось 100500 файлов и дира вымахала до эн мегз - мало того что дира останется эн мегз навечно! Кроме этого - даже если там ща 100 файлов, операции с этой дирой тормозят как будто там все 100500 на месте. Такая вот скалабельная, крутая фс - которая даже деаллоккацию дир не могет. И которой цук номерков на иноды может не хватить. И эти люди тут еще юродствовать смеют на тему сабжа.
> Потому что внезапный отказ в записи - это почти гарантированно потеря данных
> с любым софтом ныне.
Как там поживает деаллокация дир в EXT4 или ограничение на число инодов? А, ничо, эти копролиты - нормуль, не жмут?
> Зачем? Достаточно знать, сколько там _реально_ ещё можно записать, без "сожмётся"
> и "совпадают". Если удастся записать больше - хорошо, но ни в коем случае
> не меньше.
Оно что-то такое видимо и выдает как оценку для доступного места. Но реально ессно возможны варианты. Кроме того...
...у ФС есть метаданные. Вот смотрите: кто-то даже делал супер-архивер, который попытался взять приз на конкурсе сжатия. Идея была простая:
- А можно сохранять в несколько файлов?!
- ОкеЙ, сохраняйте!
Ну чувак и читал данные исходного файла. Разложил прочитанные данные по именам файлов в дире. И вот - обана! - смотрите дети, идеальный архивер! Суммарный вес файлов - ноль! Данные же в именах хранятся, зачем в файл что-то писать. Сумма размеров файлов - вообше ноль.
Вот только приз ему кажется не дали. Да и вообще - если попробовать так архивировать, можно заметить что в принципе можно догнаться до точки когда формально на ФС аллоцировано 0 байтов в файлы, но записать почему-то не получается. А как вы собрались заранее оценивать размер метаданных и соотношение оного VS данные - кто б его знает. Для ФС с tail packing и inlining мелких файлов - это как бы аргумент.
>> С cow нет причин почему бы данные разрушились
> Конечно нет, ZFS не даст соврать. И ищи потом свищи,
Ну, вообще, если попортилась копия, копии, да еще быстро упавшая лицом на тот кулак 2 раза подряд - это еще ухитриться надо. А с твоим EXT4 педальным ты и осыпон половины файлухи не заметишь. И таки глядя на коллекцию BadHardware отловленого btrfs я имею сказать что "it works!" и я буду предпочитать такую диагностирумеость и верификацию работы моих систем и далее. Это спасает от множества дурачких приключений и непоняток.
> где у тебя в этой каше был оригинал данных, он там на весь
> диск разложен. Ещё одна прелесть не-CoW - данные фрагментируются не сильно,
Ну вот вообще ниоткуда не следует. Если подзабить и активно поюзать даже тот же EXT4 - тупить он начнет весьма ощутимо, особенно на механике.
> и можно хоть что-то выдернуть при 3.14це, который такого выдёргивания требует.
Я и с btrfs'а вытащу, при том в отличие от твоего хексэдитора - прям встроеным альтернативным парсером. Да еще - имея под рукой ТРИ копии суперов, много разных точек входа в иерархию деревьев, ибо GC ж не прибивает более старый вид сразу и оно энное время живет. Это повышает шансы что основной объем метаданных зацепится без урона вообще. Особенно учитывая что хранится даже на 1-дисковом стораже с DUP, а на более приличной конфиге и как RAID1 (можно даже c3/c4, если девайсов много). Я как-то предпочту не натыкаться на мануальный парсинг данных, чем упражняться в нем, при прочих равных. И я это говорю как датарек-любитель, способный поболтать на равных с себе подобными. Вооон там в советах, я изобрел способ gumanzoy по ресету и рескану за несколько лет до него. Правда я скрипты не делал - тупо oneliner "по ситуации" на машине запускал.
