Телефоны, основанные на новом выпуске (http://www.opennet.me/opennews/art.shtml?num=28904) платформы Android (включая выходящий на следующей неделе телефон Nexus S (http://www.google.com/nexus/)), будут использовать (http://thunk.org/tytso/blog/2010/12/12/android-will-be-using.../) для хранения данных на внутреннем Flash-накопителе файловую систему Ext4, вместо ранее используемой YAFFS (http://www.yaffs.net/). Основная причина миграции в том, что Ext4 демонстрирует заметно более высокую производительность. Несмотря на то, что YAFFS специально создана для Flash-накопителей, данная ФС имеет однопоточную архитектуру, что не позволяет ей полностью использовать потенциал современных многоядерных CPU.
В блоге разработчиков платформы Android опубликовано (http://android-developers.blogspot.com/2010/12/saving-data-s...) предупреждение с рекомендацией использования системного вызова fsync() или sync_file_range() для принудительного сброса данных на диск, т...URL: http://thunk.org/tytso/blog/2010/12/12/android-will-be-using.../
Новость: http://www.opennet.me/opennews/art.shtml?num=28973
Это спасает скорее в случае краха приложения. При крахе системы fsync может и не спасти.Интересно, увеличится ли срок жизни флешки?
> Это спасает скорее в случае краха приложения.ничего подобного, никакой связи между "грязными" страницами в памяти и userspace нет вообще. Крах приложения не вызовет недозапись кэшей.
Так в том-то и дело, что между write и close в пользовательской программе и блоками на диске слишком много промежуточных слоёв (не забываем, речь о Java).
>>в пользовательской программе и блоками на дискеСам же и написал - запись на диск идет в модуле ФС. Чего там ява недовыполнила - её проблемы за целостность и кэширование отвечает только менеджер записи.
:)
Обычно пользователям плевать на целостность кэша,
более интересует целый годовой отчет, аль курсовая
едущие для сдачи или в печать. Это примерно где-то между
нажатием на Save и оценкой в зачётке или подписью генерального.
>>Интересно, увеличится ли срок жизни флешки?Причём тут флешка? У флешки вообще FAT32, тут говорят про встроенную память
А она на магнитных сердечниках?
У меня на флешке ext3, ЧЯДНТ?
пользуешься журналируемой фс на флешке. нормальные люди пользуются udf.
>>>Интересно, увеличится ли срок жизни флешки?
> Причём тут флешка? У флешки вообще FAT32, тут говорят про встроенную памятьПользователей Windoze просят покинуть этот ресурс.
> Интересно, увеличится ли срок жизни флешки?По сравнению с YAFFS? Зависит от. Если флеха за умным контроллером размазывающим записи самостоятельно - более-менее пофигу. Если без контроллера напрямую к процу прицеплена - скорее уменьшится, т.к. EXT4 никогда не создавалась с целью минимизации количества перезаписи блоков флеша и не затачивалась под размазывание записей по всему носителю равномерно.
А как же, типа, минимизация износа? ext4 ведь - журналирующая..
> А как же, типа, минимизация износа? ext4 ведь - журналирующая..а прошлая тоже была журналируемой. Потом флешка вроде как сама должна следить за степенью износа своих страниц.
> Потом флешка вроде как сама должна следить за степенью износа своих страниц.Как бы от флешки зависит. Умные флешки с контроллером, типа SD карт, встроенных eMMC и прочая - да, следят. А "глупый" NAND напрямую прицепленный к процу - извините. Какой там флеш у гугля поюзан - а гугл его знает :)
У меня некоторые станции грузятся с флешек, в виде лайв-систем, а там где нужно было чтоб все же можно было изменять систему - 2 флешки по 8Гб в софт-raid нормально. Везде райзерфс.PS флешки китайские у нас копейки стоят - дешевле полноценных жестких дисков ставить, тем более что лишние гигабайты так и подмывают планктон их забить всякой чухней.
ага, тоже про это подумал
noatime norelatime уменьшит износ
> noatime norelatime уменьшит износСкажи это sqlite или mysql :-)
Журналирование в ext4 можно отключить, что и делают люди для тех же SDD.
чем им интересно не понравилась jffs2?
http://www.yaffs.net/comparison-yaffs-vs-jffs
Тогда уж UBIFS, сделанная нокией или LogFS. Неужели екст4 чётче?
> чем им интересно не понравилась jffs2?Проблемами с масштабируемостью, вероятно. У нее время монтирования сильно растет с ростом размера файловой системы. ФС крупнее нескольких сотен мегов ... нескольких Гб задолбаться можно монтировать. При современных размерах флеша это как бы проблема - если бОльшая часть времени загрузки девайса будет монтированием файловой системы - это как бы слегка маразм, а?
>>Интересно, увеличится ли срок жизни флешки?Причём тут флешка? У флешки вообще FAT32, тут говорят про встроенную память
> Причём тут флешка? У флешки вообще FAT32, тут говорят про встроенную памятькак выше спросили не менее умного другого человека, неужели встроенная память на магнитных сердечниках?
294ый выше ответил уже.
>YAFFSКстати, читал в списке рассылки оной(в сентябре кажется), что её решили принять в мэйнстрим. И проспонсировали это дело ни кто-нибудь, а гугле. Видимо поматросили и решили, что рановато.
Я так понял, в случае зависания и/или вытаскивания батарейки из работающего телефона без вызова функции упреждающего сброса буфера вполне возможна не только потеря данных, находящихся в буфере, но и частичная деструкция файловой системы. Скажите, это так? Тогда "готова к продакшену" — это точно не про Ext4. :)) Уж лучше бы UFS2 с Soft Updates использовали.
Не сохранятся только последние ИЗМЕНЕНИЯ данных.
Данные будут, но не самой последней версии, "в случае зависания и/или вытаскивания батарейки из работающего телефона без вызова функции упреждающего сброса буфера"
> Уж лучше бы UFS2 с Soft Updates использовали.Ага, вот гугл - дураки, а изен один такой в шляпе и со шпагой. А вы допортируете на это железо *бсд до юзабельного на практике а не в теории состоянии? Да, со всякими там 3D, акселерометрами, вайфаем/блутусом, хитрожопым управлением питанием, точскринами, камерами на хитрых и-фейсах и прочая. После этого можно будет обнаружить что скорость работы ископаемой ФС без экстентов - оставляет желать много лучшего. И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.
>> Уж лучше бы UFS2 с Soft Updates использовали.
> Ага, вот гугл - дураки, а изен один такой в шляпе и
> со шпагой. А вы допортируете на это железо *бсд до юзабельного
> на практике а не в теории состоянии?Я не призываю портировать ядро FreeBSD на Android-смартфоны (хотя это было бы логичным — уйти от зависимости от других корпораций, ключевых разработчиков Linux). Достаточно перенести саму ФС — благо, в Linux уже есть поддержка этой ФС, но в зачаточном состоянии (читает только). Исходники UFS2 открыты под BSDL.
> Да, со всякими там 3D, акселерометрами, вайфаем/блутусом, хитрожопым управлением питанием, точскринами, камерами на хитрых и-фейсах и прочая.
> После этого можно будет обнаружить что скорость работы ископаемой ФС без экстентов - оставляет желать много лучшего.Не вижу логической связи ФС с 3D и Wi-Fi. Как и где ты её обнаружил?
UFS2 меньше подвержена фрагментации и сливу свободного пространства в полузанятые блоки. У семейства файловых систем типа Ext, как у FAT16, слив свободного пространства на недоконца занятых блоках — самая больная тема, причём независимо от того, что в последней версии Ext4 появилась поддержка _предвыделения_ блоков (экстенты).
> И, кстати, гугл не может подождать лишний десяток лет - конкуренты его платформу за это время замнут, знаете ли.
Google смог выбросить glibc и заменить её BSD-реализацией libc. Почему ты думаешь, что заменить устаревшее ядро на более современное ей составит очень больших затрат? Ведь основной тренд разработки Android связан не с системным программным обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.
Снова носом в землю, да?
>>> Уж лучше бы 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 связан не с системным программным
> обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.пруфлинк?
> Снова носом в землю, да?успокойся -- а то от злости зубы покрошаться
>> Я не призываю портировать ядро 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...
>[оверквотинг удален]
>> если они ничем не лучше"
> Критерий хуже/лучше для смартфонов явно не в быстроте чтения-записи, но в экономичном
> использовании полезного пространства файловой системой под данные пользователя.
> Помниться, в 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...так где? чёта не вижу
> Прикольно жить в чёрно-белом мире. :))Вам привет от битовых карт :-P.
> Критерий хуже/лучше для смартфонов явно не в быстроте чтения-записи, но в экономичном
> использовании полезного пространства файловой системой под данные пользователя.Прикалываетесь? Тормозные телефоны никто не будет покупать. И платформе настанет рослый полярный лис.
> Помниться, в 1997 году 500Мб файловый образ Mathlab
Зачем юзеру андроида 500 меговый (wtf образ то?) матлаба в телефоне в виде кучи мелких файлов? И вообще, ради чего оптимизить хранение уймы мелких файлов? Они занимают основную массу диска? Я почему-то думал что обычно львиную долю занимает музыка, фото, видео и что там еще. Ну сэкономите вы <4 Кб на 2-4 мега. Офигенный выигрыщ, аж менее 1%.
> Как мне поможет дефрагментатор, если свободное пространство поглощено неполностью занятыми
> блоками и его в принципе нельзя никак уже использовать?Человеку которому надо 500 меговый матлаб с мелкими файлами в телефоне помогать должен наверное не дефрагментатор...
> Я не призываю портировать ядро 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 связан не с системным программным
> обеспечением, а с ПРИКЛАДНЫМ, независимым от ядра и его операционного окружения.А новость вот про системное ПО. А чем еще по вашему файлоавя система является?
> Снова носом в землю, да?
О, вы занялись самокритикой? Это правильно!
> Если уж жажда бурной деятельности прет и готовые решения не нравятся, логично тогда уж тратить силы на ФС оптимизированную специально для флешаУгу. Только вот 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.
> :)) Уж лучше бы UFS2 с Soft Updates использовали.Старая она уж слишком. Лучше уж тогда HAMMER из DragonFlyBSD, к-я кластерная, к-я умеет делать умеет делать моментальные снепшоты в любой промежуток времени, к-я версионная:)
>> :)) Уж лучше бы UFS2 с Soft Updates использовали.
> Старая она уж слишком. Лучше уж тогда HAMMER из DragonFlyBSD, к-я кластерная,
> к-я умеет делать умеет делать моментальные снепшоты в любой промежуток времени,
> к-я версионная:)Приплыли. А что, UFS2 уже разучилась делать снапшоты в любой момент времени без отмонтирования?
И, да, снапшоты — не главное на смартфонах, хотя это и может способствовать быстрому восстановлению после сбоев и зависаний.
А вот тут http://linux-tipps.blogspot.com/2010/10/disabling-fsync-in-l...
Убунтовцы призывают удалить сискал fsync() с целью продления жизни батарейки.
ну дык... убунта не виснет.
а если нет упса и электричество в розетке закончилось?
Речь идёт о laptop. У них есть батарейки и Убунта говорит, когда закончится заряд, и может засыпать, если заряд меньше определённого процента.
> Речь идёт о laptop. У них есть батарейки и Убунта говорит, когда
> закончится заряд, и может засыпать, если заряд меньше определённого процента.А если отсоединить батарею и в этот момент электричество кончится?
Очередная победа отдела маркетинга над надёжностью.
> сам он ни разу не сталкивался с крахом ОС AndroidУ меня Samsung i5700 хотя бы раз в неделю виснет, приходится вынимать аккумулятор и ставить обратно чтобы перезагрузить. Иногда заместо повисания самопроизвольно перезагружается.
Nexus S кстати тоже делает Samsung.