> Что то не везет вам в думании ...

Да ладно вам, нормально вполне. Кстати понимание работы этой механики еще не означает одобрение такого подхода и/или симпатий ко многим методам работы капиталистов.

> заметил в силу своей природной незамечательности что иногда интересы очень разных
> корпараций вдруг удивительно сочетаются?

Они вдруг удивительно сочетаются лишь до той поры пока это выгодно. А как только дружба начинает мешать выгоде - так сразу же вчерашний друг-союзник радостно пыряется кинжалом в спину, приговаривая что-то там про "Это просто бизнес, ничего личного!". Поэтому глядя на улыбчивые физиономии друзей-капиталистов не забывайте о том что они улыбаясь и дружа с удовольствием прокатят "ближнего своего" и пырнут в спину, если это сулит хоть какую-то прибыль. При том чем больше прибыль, тем беспринципнее капиталист прет по головам и трупам. Природа настоящего капиталиста такова.

>> хотел аппаратный RAID - пойдет да купит его. А btrfs -
>> просто полезняшка для админов этакая.
> Ну да ZFS рекомендуюут ставиь не на райды а на диски, уж остальное додумайте сами ...

Да, я додумал: вы зациклены на *bsd и ZFS. И никак не можете понять, что архитектурно btrfs мало того что не слишком похож на zfs, так еще исправляет ряд его упущений и обладает рядом настроек которые в принципе позволят ему достаточно сухо и комфортно жить на весьма разных по своей природе накопителях.

>> Чего бы ради? В случае "сферического коня в вакууме", когда файл лежит
>> идеально непрерывно, одним фрагментом - практически любая ФС ...
> Дальше можно не читать. Странно что при всей своей эрудиции месье не
> понимает что файл идеально непрерывно может лежать только после дефрагментации

Мсье сообщает что файл может лежать непрерывно и при просто быстрой записи файла на незасранный том. Более того, качественно реализованный аллокатор активно стремиться добиться именно такого случая настолько насколько позволяют реалии свободного места на диске. Чем больше свободного места на диске и меньше фрагментировано свободное место, тем лучше это получается. В клиническом случае если мы резво пишем файл на только что созданную пустую ФС, он скорее всего будет выложен идеально линейно.

>  и только в ntfs или fat :)))

Ну нихрена себе ламерство. А какие законы природы запрещают файлам лежать линейно на остальных ФС? Чисто теоретически, структуры большинства ФС это вполне допускают и приветствуют. Чисто практически - уж насколько получится. И даже мелкие неидеальности типа seek в сторону 1 раз на 100Мб мало чего меняют. Ну будет не 100% скорости а 99%, допустим. Никто и не заметит особой разницы. Фрагментация являет собой проблему когда том становится загажен и не удается выкроить непрерывный кусок.

> а для других фс даже дефрагментаторов нет :)))

Во первых, можно отдефрагать неудачно разложенный файл просто его копированием и удалением старого размазанного варианта, например. При этом используется свойство аллокатора пытаться разложить файл максимально линейно. Таким манером можно частично отдефрагментировать практически любую "классическую" ФС, как минимум для наиболее злободневных файлов. Лишь бы свободного места было много, иначе аллокатору негде будет развернуть деятельность по оптимизации и получится опа. Такое помогает от неудачно разместившихся файлов, если совсем опа в ФС еще не наступила. По поводу чего и не советуют тома забивать более чем на 70-90%. Иначе сильно фрагментируется свободное место и том коллапсирует. Что будет - отлично видно на примере изена, с его легендарными 6Мб/сек на шпиндель :)

Во вторых, для ext4 дефрагер есть. С неких пор поставляется с остальными утилитками для файловой системы. Называется e4defrag. В свежих выпусках дистров обычно есть сразу.

В третьих, в случае CoW файловых систем обязан быть garbage collector разгребающий устаревшие неиспользуемые блоки. Иначе CoW логика просто забьет том до отказа. А раз он всяко есть и кантует блоки - пусть заодно и дефрагит в процессе! В btrfs этот достаточно очевидный факт до разработчиков дошел и там GC совмещен с дефрагером, по поводу чего у btrfs есть встроенный дефраг. В ZFS такого не было, да. Почему? Наверное потому что это одна из первых CoW ФС.

Так что ваши сведения кривоваты и староваты. FAIL.

> Неужели месье асилил Левашева ?

Не припоминаю такой фамилии. Но мсье знает некоторые другие фамилии. Например, Ланау и Лившиц. Забавные дяденьки - спокойно считают в уме интегралы на 2 страницы и полагают что все остальные могут не хуже, поэтому просто не приводят подобные преобразования в своей книжке :). Ну а в плане электроникм мсье попалась достаточно годная книжка по основам полупроводниковой схемотехники от У. Титце и К. Шенка (в переводе на русский, они изначально немцы). Все основы изложенные там до сих пор вполне актуальны.

И да, смею заверить что грубо прикинуть как будет разложен файл, хоть немного преставляя себе логику работы ФС - я в состоянии. Как в состоянии предсказать некоторые сценарии, например то что получилось на томе у какого-нибудь изена :). Я даже не видя того что у него на томе могу примерно представить себе как сие выглядит, если отрисовать занятость тома. ИЧСХ, оно как-то так обычно и оказывается.

>> - вы вообще остаетесь без доступа к данным. Резко, больно и внезапно.
> Да в курсе, работали  с хецнером и улетающими райдами... :))) Вот
> потому то zfs и нужно ставить на диски, а не на рейды - глюки контроллеров
> сразу идут лесом.

Собственно, одна из причин по которым не все юзают аппаратные рэйды. А также ФС с управлением томами самолично имеет больше шансов разложить данные по дискам более удачно если природа хранилища не скрыта от нее железкой.

А так - оракл может чисто номинально дружить с кем угодно. Но в конечном итоге они базы продают. Рэйды им могут быть интересны, если это помогает базы продавать. Но в целом им перпендикулярно, существуют рэйды или нет. Это вообще кастомеровские проблемы и проблемы сторонних контор. А их интересуют продажи баз. Продастся ли при этом аппаратный рэйд - уж точно не проблема оракла. Поэтому называя вещи своими именами, ораклу более-менее все-равно. Тем более что если некое хранилище работает, то btrfs поверх него ничему не противоречит. Тем более что в btrfs настраивается как именно хранить данные и метаданные. Например если кто уверен что хранилище офигеть какое надежное - он может выключить зеркалирование метаданных, например. Скорость возрастет. А надежность... ну если хранилище надежное - сами знали на что шли.

> К чему это ... наверно обострение.

Да, обострение чувства голода. Кушать хочется после того как втирают всякое ламерство про фрагментацию :)

> Так или иначе но linux на btrfs на 1-2 гига оперы это полный П...ц
> Ну если хотите в этом сами убедиться - попробуйте.

Это вы про ZFS. Не надо переносить его свойства на btrfs. Я его ради лулзов запускал на железке с 64Мб и хилым процом. Даже работало. Хотя ext4 показал себя несколько быстрее в такой конфигурации и меньше нагружал проц, что для мелкой железки актуально. А на типовом девайсе типа нотика с 2Гб оперативы оно себя будет чувствовать вполне по королевски. Оно в целом помедленнее ext4 (который вышел на удивление шустрым), но в последнее время основательно подтянули. Я ссылочку на недавние бенчи привел.