The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Мобильная платформа Android начинает использование файловой ..., opennews (ok), 12-Дек-10, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


18. "Мобильная платформа Android начинает использование файловой ..."  –5 +/
Сообщение от iZEN (ok), 13-Дек-10, 01:03 
Я так понял, в случае зависания и/или вытаскивания батарейки из работающего телефона без вызова функции упреждающего сброса буфера вполне возможна не только потеря данных, находящихся в буфере, но и частичная деструкция файловой системы. Скажите, это так? Тогда "готова к продакшену" — это точно не про Ext4. :)) Уж лучше бы UFS2 с Soft Updates использовали.
Ответить | Правка | Наверх | Cообщить модератору

20. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от Анон (?), 13-Дек-10, 03:00 
Не сохранятся только последние ИЗМЕНЕНИЯ данных.
Данные будут, но не самой последней версии, "в случае зависания и/или вытаскивания батарейки из работающего телефона без вызова функции упреждающего сброса буфера"
Ответить | Правка | Наверх | Cообщить модератору

27. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от User294 (ok), 13-Дек-10, 05:15 
> Уж лучше бы UFS2 с Soft Updates использовали.

Ага, вот гугл - дураки, а изен один такой в шляпе и со шпагой. А вы допортируете на это железо *бсд до юзабельного на практике а не в теории состоянии? Да, со всякими там 3D, акселерометрами, вайфаем/блутусом, хитрожопым управлением питанием, точскринами, камерами на хитрых и-фейсах и прочая. После этого можно будет обнаружить что скорость работы ископаемой ФС без экстентов - оставляет желать много лучшего. И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

35. "Мобильная платформа Android начинает использование файловой ..."  –1 +/
Сообщение от iZEN (ok), 13-Дек-10, 16:03 
>> Уж лучше бы UFS2 с Soft Updates использовали.
> Ага, вот гугл - дураки, а изен один такой в шляпе и
> со шпагой. А вы допортируете на это железо *бсд до юзабельного
> на практике а не в теории состоянии?

Я не призываю портировать ядро FreeBSD на Android-смартфоны (хотя это было бы логичным — уйти от зависимости от других корпораций, ключевых разработчиков Linux). Достаточно перенести саму ФС — благо, в Linux уже есть поддержка этой ФС, но в зачаточном состоянии (читает только). Исходники UFS2 открыты под BSDL.

> Да, со всякими там 3D, акселерометрами, вайфаем/блутусом, хитрожопым управлением питанием, точскринами, камерами на хитрых и-фейсах и прочая.
> После этого можно будет обнаружить что скорость работы ископаемой ФС без экстентов - оставляет желать много лучшего.

Не вижу логической связи ФС с 3D и Wi-Fi. Как и где ты её обнаружил?

UFS2 меньше подвержена фрагментации и сливу свободного пространства в полузанятые блоки. У семейства файловых систем типа Ext, как у FAT16, слив свободного пространства на недоконца занятых блоках — самая больная тема, причём независимо от того, что в последней версии Ext4 появилась поддержка _предвыделения_ блоков (экстенты).

> И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.

Google смог выбросить glibc и заменить её BSD-реализацией libc. Почему ты думаешь, что заменить устаревшее ядро на более современное ей составит очень больших затрат? Ведь основной тренд разработки Android связан не с системным программным обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.

Снова носом в землю, да?

Ответить | Правка | Наверх | Cообщить модератору

38. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от pavel_simple (ok), 13-Дек-10, 19:07 
>>> Уж лучше бы UFS2 с Soft Updates использовали.
>> Ага, вот гугл - дураки, а изен один такой в шляпе и
>> со шпагой. А вы допортируете на это железо *бсд до юзабельного
>> на практике а не в теории состоянии?
> Я не призываю портировать ядро FreeBSD на Android-смартфоны (хотя это было бы
> логичным — уйти от зависимости от других корпораций

других это каких? уйти о одних в виде OIN и попасть к дгугим в виде злобных пропиетарщиков с патентными пулами типа MS? -- толсто
, ключевых разработчиков Linux).
> Достаточно перенести саму ФС — благо, в Linux уже есть поддержка
> этой ФС, но в зачаточном состоянии (читает только). Исходники UFS2 открыты
> под BSDL.

покажи хоть один вменяемый тест где семейство ext2/3/4 "ведёт" себя хуже UFS2 -- не когда не задавал себе вопрос типа "а нахера UFS2 если они ничем не лучше"
>> Да, со всякими там 3D, акселерометрами, вайфаем/блутусом, хитрожопым управлением питанием, точскринами, камерами на хитрых и-фейсах и прочая.
>> После этого можно будет обнаружить что скорость работы ископаемой ФС без экстентов - оставляет желать много лучшего.
> Не вижу логической связи ФС с 3D и Wi-Fi. Как и где
> ты её обнаружил?
> UFS2 меньше подвержена фрагментации и сливу свободного пространства в полузанятые блоки.
> У семейства файловых систем типа Ext, как у FAT16, слив свободного
> пространства на недоконца занятых блоках — самая больная тема, причём независимо
> от того, что в последней версии Ext4 появилась поддержка _предвыделения_ блоков
> (экстенты).

для таких экономных как ты придумали дефрагменторы -- хотя целесообразносьт их использования под большим вопросом
>> И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.
> Google смог выбросить glibc и заменить её BSD-реализацией libc. Почему ты думаешь,
> что заменить устаревшее ядро на более современное ей составит очень больших
> затрат? Ведь основной тренд разработки Android связан не с системным программным
> обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.

пруфлинк?
> Снова носом в землю, да?

успокойся -- а то от злости зубы покрошаться

Ответить | Правка | Наверх | Cообщить модератору

43. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от iZEN (ok), 13-Дек-10, 22:32 
>> Я не призываю портировать ядро FreeBSD на Android-смартфоны (хотя это было бы
>> логичным — уйти от зависимости от других корпораций
> других это каких? уйти о одних в виде OIN и попасть к
> дгугим в виде злобных пропиетарщиков с патентными пулами типа MS? --
> толсто, ключевых разработчиков Linux).

Прикольно жить в чёрно-белом мире. :))

> покажи хоть один вменяемый тест где семейство ext2/3/4 "ведёт" себя хуже UFS2
> -- не когда не задавал себе вопрос типа "а нахера UFS2
> если они ничем не лучше"

Критерий хуже/лучше для смартфонов явно не в быстроте чтения-записи, но в экономичном использовании полезного пространства файловой системой под данные пользователя.

Помниться, в 1997 году 500Мб файловый образ Mathlab не мог полностью уместиться на диске 1ГБ FAT16 из-за того, что размер кластера 32k байт, а средний размер файлика Matlab'а был около 15 кбайт — файловая система просто не находила столько кластеров для каждого маленького файла, хотя свободного места было для двух матлабов. :)) Проблему решили с переходом на FAT32 в Windows 95 OSR2 и NTFS в Windows NT4 WS, у которых кластера по 4k байт. ;)

> для таких экономных как ты придумали дефрагменторы -- хотя целесообразносьт их использования под большим вопросом

Как мне поможет дефрагментатор, если свободное пространство поглощено неполностью занятыми блоками и его в принципе нельзя никак уже использовать?

>>> И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.
>> Google смог выбросить glibc и заменить её BSD-реализацией libc. Почему ты думаешь,
>> что заменить устаревшее ядро на более современное ей составит очень больших
>> затрат? Ведь основной тренд разработки Android связан не с системным программным
>> обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.
> пруфлинк?

http://en.wikipedia.org/wiki/GNU_C_Library#Use_in_small_devices
http://en.wikipedia.org/wiki/Android_Market#Implementation_d...

Ответить | Правка | Наверх | Cообщить модератору

46. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от pavel_simple (ok), 15-Дек-10, 00:30 
>[оверквотинг удален]
>> если они ничем не лучше"
> Критерий хуже/лучше для смартфонов явно не в быстроте чтения-записи, но в экономичном
> использовании полезного пространства файловой системой под данные пользователя.
> Помниться, в 1997 году 500Мб файловый образ Mathlab не мог полностью уместиться
> на диске 1ГБ FAT16 из-за того, что размер кластера 32k байт,
> а средний размер файлика Matlab'а был около 15 кбайт — файловая
> система просто не находила столько кластеров для каждого маленького файла, хотя
> свободного места было для двух матлабов. :)) Проблему решили с переходом
> на FAT32 в Windows 95 OSR2 и NTFS в Windows NT4
> WS, у которых кластера по 4k байт. ;)

а я т думал чт разницу в цене 4G или 16G гораздо проще компенсировать чем мощьностью и соответственно объёмом батарейки -- ну тебе видимо видней.

>[оверквотинг удален]
> Как мне поможет дефрагментатор, если свободное пространство поглощено неполностью занятыми
> блоками и его в принципе нельзя никак уже использовать?
>>>> И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.
>>> Google смог выбросить glibc и заменить её BSD-реализацией libc. Почему ты думаешь,
>>> что заменить устаревшее ядро на более современное ей составит очень больших
>>> затрат? Ведь основной тренд разработки Android связан не с системным программным
>>> обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.
>> пруфлинк?
> http://en.wikipedia.org/wiki/GNU_C_Library#Use_in_small_devices
> http://en.wikipedia.org/wiki/Android_Market#Implementation_d...

так где? чёта не вижу

Ответить | Правка | Наверх | Cообщить модератору

49. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от User294 (ok), 17-Дек-10, 22:33 
> Прикольно жить в чёрно-белом мире. :))

Вам привет от битовых карт :-P.

> Критерий хуже/лучше для смартфонов явно не в быстроте чтения-записи, но в экономичном
> использовании полезного пространства файловой системой под данные пользователя.

Прикалываетесь? Тормозные телефоны никто не будет покупать. И платформе настанет рослый полярный лис.

> Помниться, в 1997 году 500Мб файловый образ Mathlab

Зачем юзеру андроида 500 меговый (wtf образ то?) матлаба в телефоне в виде кучи мелких файлов? И вообще, ради чего оптимизить хранение уймы мелких файлов? Они занимают основную массу диска? Я почему-то думал что обычно львиную долю занимает музыка, фото, видео и что там еще. Ну сэкономите вы <4 Кб на 2-4 мега. Офигенный выигрыщ, аж менее 1%.

> Как мне поможет дефрагментатор, если свободное пространство поглощено неполностью занятыми
> блоками и его в принципе нельзя никак уже использовать?

Человеку которому надо 500 меговый матлаб с мелкими файлами в телефоне помогать должен наверное не дефрагментатор...

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

48. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от User294 (ok), 17-Дек-10, 22:17 
> Я не призываю портировать ядро FreeBSD на Android-смартфоны

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

> (хотя это было бы  логичным — уйти от зависимости от других корпораций,

Да, конечно. Зачем это они нахаляву вкалывают на гугл?! Надо взвалить полный цикл R&D на себя любимых, ради благой цели потом ни с кем не делиться и всем диктовать. Только зачем все это гуглу? Если они не хотели бы делиться и совместно работать с другим - было логично вообще не раздавать андроид всем подряд, не пытаться пропихать патчи в майнлайн и прочая.

> ключевых разработчиков Linux).

А если ручник отпуcтить - можно еще узнать что Теодор Тсо (да, автор этого самого EXT4) ушел работать в гугл. По-моему, вполне себе ключевой разработчик да еще и в нужном месте в нужное время.

> Достаточно перенести саму ФС — благо, в Linux уже есть поддержка
> этой ФС, но в зачаточном состоянии (читает только). Исходники UFS2 открыты
> под BSDL.

Кому и зачем это будет надо? Сам по себе UFS2 по своим структурам - обычное такое древнее говно мамонта, на уровне раритетов типа EXT2. Бсдуны в силу отсутствия ресурсов насколько я помню заломались переделать древнючие структуры своей ФС. В EXT4 - не поломались. И какая-никакая оптимизация работы с флеш-дисками с контроллером в EXT4 есть. Ну и какой смысл портировать этого урода? Тем более что в гугле работает Теодор Тсо, автор этого самого EXT4. Что-то у вас аналитические способности как обычно - ни в зуб ногой. Прицепились к 1 решению, и пытаетесь его сватать везде. Игнорируя уйму причин по которым это заведомо неперспективно и неоптимально.

> Не вижу логической связи ФС с 3D и Wi-Fi. Как и где ты её обнаружил?

Элементарно, Ватсон: работающий 3D и вайфай со всякими там акселерометрами есть в пингвине. А UFS2 в полноценном виде есть только во фре. В этом месте должно бы допереть что возникает некий конфликт хотелок. И, черт возьми, с учетом перечисленных факторов я не вижу смысла портировать древний крап, пусть и подпертый красиво отполированным костылем, в пингвина. А портировать бсд на такие девайсы - ну, портируйте. Желательно до того как их процессоры останутся доступны только в музее политехники. Гугл это делать не будет - у них уже есть *работающее* решение. Которое работает. Сейчас.

> UFS2 меньше подвержена фрагментации

Меньше чем что? Чем EXT4? А как это измерялось? И какие к тому предпосылки на уровне логики работы ФС и свойств ее структур? Это даже если забыть о том что seek time флеша близок к нулю и фрагментация там не особо страшна, так что если даже допустить что вы не соврали, это было бы пофигу. Но вы скорее всего соврали, потому что все что можно представить поблочной аллокацией, можно представить и экстентами - никаких вопиющих причин у схем с экстентами чтобы сильнее фрагментироваться я не вижу. Все определяется логикой аллокатора. У ext4 аллокатор умеет продвинутости типа delayed allocation и прочая. И бенчи вон были по которым он блозок к XFS по скорости становится. Как же это оно так быстро работает с жуткой фрагментацией? ;)

> и сливу свободного пространства в полузанятые блоки.

Для классической ФС полузанятый блок - вообще довольно горбатое понятие. В такой ФС блок по исходной задумке или считается полностью занятым, или полностью свободным т.к. используются битовые карты занятости и у бита описывающего блок есть ровно 2 состояния. Логика с битмапами не предполагает простых и быстрых операций с гранулярностью менее 1 блока. Можно донавесить костылей, но будет тормозить т.к. не вписывается в исходную идею дизайна и требует лишних операций где-то сбоку. Удивительно, правда? А если посмотреть какие файлы занимают у юзеров на телефоне место - гм, фотки/мп3/видео, занимающие львиную долю места не так уж и много выиграют от экономии менее чем 4Кб на сколько-то там Мб. Это какие-то доли процента будут.

> от того, что в последней версии Ext4 появилась поддержка _предвыделения_ блоков
> (экстенты).

Ох и ламерство же. Экстенты - это не предвыделение блоков. Это альтернативный способ пометки блоков как используемых, как правило ведущий к улучшению скорости работы файловой системы. Традиционные блочные схемы обычно используют битовые карты, где каждый бит соответствует состоянию блока (используется/не используется). Педалинг большой битовой карты с изменением в ней состояния кучи битов при выделении большого непрерывного куска получается довольно медленной операцией - для *каждого* выделяемого блока надо поменять его бит. Время этой операции пропорционально числу непрерывно записываемых блоков. А экстент - всего лишь диапазон блоков. При записи диапазона пофиг сколько в нем блоков, время операции от этого не меняется. Одно дело указать диапазон, и совсем другое - весь его прощелкать в битовой карте на каждый блок. Понимаете разницу между алгоритмом с временем работы O(n) и O(1), или для вас такое слишком сложно? Ну, в 80х и ранних 90х прошлого века лучше вот не умели, диски и файлы были мелкими и все это как-то работало худо-бедно. А сейчас, вы только представьте себе, научились вот делать лучше. И все мало-мальски современные ФС недавней разработки бросились юзать экстенты. И чего бы это они? Может, потому что такая схема пометки занятости блоков эффективнее под многими нагрузками? :)

> Google смог выбросить glibc и заменить её BSD-реализацией libc.

Эээ и чего? Ну а кто-то смог использовать eglibc, uClibc и прочая. И что из этого следует?

> Почему ты думаешь, что заменить устаревшее ядро на более современное
> ей составит очень больших затрат?

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

> Ведь основной тренд разработки Android связан не с системным программным
> обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.

А новость вот про системное ПО. А чем еще по вашему файлоавя система является?

> Снова носом в землю, да?

О, вы занялись самокритикой? Это правильно!

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

50. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от iZEN (ok), 18-Дек-10, 09:19 
> Если уж жажда бурной деятельности прет и готовые решения не нравятся, логично тогда уж тратить силы на ФС оптимизированную специально для флеша

Угу. Только вот 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.

Ответить | Правка | Наверх | Cообщить модератору

31. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от Аноним (-), 13-Дек-10, 10:38 
> :)) Уж лучше бы UFS2 с Soft Updates использовали.

Старая она уж слишком. Лучше уж тогда HAMMER из DragonFlyBSD, к-я кластерная, к-я умеет делать умеет делать моментальные снепшоты в любой промежуток времени, к-я версионная:)

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

37. "Мобильная платформа Android начинает использование файловой ..."  +/
Сообщение от iZEN (ok), 13-Дек-10, 16:09 
>> :)) Уж лучше бы UFS2 с Soft Updates использовали.
> Старая она уж слишком. Лучше уж тогда HAMMER из DragonFlyBSD, к-я кластерная,
> к-я умеет делать умеет делать моментальные снепшоты в любой промежуток времени,
> к-я версионная:)

Приплыли. А что, UFS2 уже разучилась делать снапшоты в любой момент времени без отмонтирования?

И, да, снапшоты — не главное на смартфонах, хотя это и может способствовать быстрому восстановлению после сбоев и зависаний.


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру