> Если уж жажда бурной деятельности прет и готовые решения не нравятся, логично тогда уж тратить силы на ФС оптимизированную специально для флеша

Угу. Только вот Ext4 с журналирование для флэша ну никак не прёт. :))

> Сам по себе UFS2 по своим структурам - обычное такое древнее говно мамонта

По своим структурам UFS2 прогрессивнее чем Ext4. Со времён UFS1 там столько перелопатили — мама, не горюй.

> И какая-никакая оптимизация работы с флеш-дисками с контроллером в EXT4 есть.

И какая же? Даже теоретически: журналирование для обеспечения целостности транзакций на флэше — бред.

> Тем более что в гугле работает Теодор Тсо, автор этого самого EXT4.

Ну, и? Из-за безысходности и зоопарка недо-ФС в ядре линукса, похоже, выхода нет, как использовать всё ещё экспериментальную ФС с сомнительной надёжностью.
К тому же, Google в своей конфигурации серверного использует Ext4 с ОТКЛЮЧЕННЫМ журналом и с опцией "nobarrier" — фактически не использует никаких средств обеспечения надёжности самой ФС, полагаясь на более высокоуровневые средства восстановления. Так зачем такую идеологию протаскивать в малонадёжные мобильные девайсы, жизнь которых ВСЕЦЕЛО зависит от батарейки? Называется: "слетела файловая система — заново всё перезальём, не расстроимся." :)) С таким наплевательским подходом к пользовательским данным (которые в мобильниках вряд ли кто бэкапит), Google точно завоюет мир — пользователю придётся все свои файлы хранить в сети, а не на ненадёжном и глючном флэше мобильника. ;)

> Что-то у вас аналитические способности как обычно - ни в зуб ногой. Прицепились к 1 решению, и пытаетесь его сватать везде. Игнорируя уйму причин по которым это заведомо неперспективно и неоптимально.

Перечитай ЕЩЁ раз, какие преимущества UFS2 на флэше перед другими традиционными ФС я привел:

1) отсутствие журналирования для обеспечения транзакций и замена его механизмом CoW Soft Updates ведёт к большей надёжности флэша.

Согласен?

2) Отсутствие потери свободного пространства на мелких файлах за счёт эффективного использования фрагментов блоков.

Согласен?

> У ext4 аллокатор умеет продвинутости типа delayed allocation и прочая.

Зачем оно нужно на флэше?

"Прирост производительности от отложенного и много­блочного размещения оказался существенным: на 30% возросла пропускная способность ФС, нагрузка на CPU снизилась почти на 50%. Цена этого решения – УВЕЛИЧЕНИЕ_ВРЕМЕНИ_МОНТИРОВАНИЯ ФС."

"ошибка в файловой системе ext4, приводящая к потере данных, заключается в том, что при использовании отложенного распределения информации в ext4 (Delayed allocation) существует вероятность потерять при крахе системы содержимое большого числа файлов (в журнал изменения вносятся сразу, но сами данные на диск записаться не успевают)."

> Для классической ФС полузанятый блок - вообще довольно горбатое понятие. В такой ФС блок по исходной задумке или считается полностью занятым, или полностью свободным т.к. используются битовые карты занятости и у бита описывающего блок есть ровно 2 состояния.

Тебе хорошо жить в чёрно-белом мире битовых карт, которые описывают только блоки целиком? Ну и живи! Мне интересен более (по)дробный мир с эффективным управлением пространством. ;)

> Более современное что? EXT4 на уровне своего устройства явно современнее чем UFS2. Хотя-бы теми же экстентами.

Что же Ext4 до сих пор не умеет снапшотиться и не поддерживает CoW без журналирования? А для гарантированной (непротиворечивой) записи в случае сбоев электричества приходится выставлять флаг barrier.