Именно эти проблемы учитывает UDF. На DVD-RW, кстати, та же проблема - надо писать туда, куда еще не писали, так как циклов перезаписи там еще меньше, чем на SSD - около 100.

вот и я о том - есть смысл писать на флешку/SSD в ФС UDF/ISO9660. Всё равно часто туда лучше не писать, а то, что файлы из одного каталога, читающиеся часто вместе, будут лежать на разных «концах» SSD не имеет значения. В отличие от оптики, кстати. А если место кончится, то можно всё стереть, как и оптику.

Если бы ты руководил Самсунг, они бы уже давно разорились. Никто в здравом уме не кладет все яйца в одну корзину.

Если речь идет о деньгах, то ты прав. Если бы ты делал телефон для себя, то не стал бы гнаться за тремя зайцами.

ну и зачем мне это?

Затем же, зачем тебе вещества, под воздействием которых в ответ на сообщение про виндовый драйвер ты написал «в слаке это не работает».

чтобы отдать устройство в венду, его надо отмонтировать от андройда

s/ в венду//

К.О. намекает на то, что использование раздела несколькими системами одновременно чревато приключениями не только в винде. :)

Ты за дискуссией следишь, или на последнее сообщение отвечаешь?

Конечно такой подход похож на FTL, но для современных ОС можно не использовать этот механизм. Это даст пользователю возможность обновлять софтовую реализацию (новые версии могут содержать меньше ошибок, быстрее работать, лучше подходить под некие специализированные случаи). Реализация же FTL «в железе» не даёт такой гибкости, лишь удорожая устройство. К тому же, дешёвые FTL проседают по производительности (приводят к обмену данными медленнее, чем может NAND) при длительных нагрузках, а их вычислительная мощность сильно уступает мощности дешёвых процессоров общего назначения.

В винду отдаётся не корень ведроида, а только /sdcard, которая и на некоторых новых устройствах идёт отдельным разделом и может быть смонтирована как usb-storage.

Да хоть корень, хоть /sdcard.

Догадываешься, что будет, если во время использования USB storage одна из сторон связки «Android <-> PC» будет на карту писать, а другая одновременно с этим тоже захочет что-нибудь считать/записать? Одна система меняет содержимое ФС, вторая об этом не знает (метеданные закешированы и т.п.) и рулит уже устаревшими данными... Очевидно, что результат такой работы непредсказуем, поэтому на время использования режима «флешки» телефонная система должна отмонтировать раздел. Но тогда теряется всякая возможность хоть как-то этим пространством воспользоваться, и если разработчик ОС ещё может подкрутить системные приложения, то сторонних разработчиков, программы которых могут использовать ту же карту памяти для хранения больших файлов, так не проконтролируешь.

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

В винду отдаётся не корень ведроида, а только /sdcard, которая и на некоторых новых устройствах идёт отдельным разделом и может быть смонтирована как usb-storage.

о том и речь, что если это отдельное устройство, то ничего и не изменилось, но там где отдельного устройства нет, приплыли...

легко. mount -o remount.

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

Ты за дискуссией следишь, или на последнее сообщение отвечаешь?

я утверждаю, что проблема не в том, что вендувс ext4 не увидит, а в том, что андройд не проживет без корня. И все.

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

а чего их контролировать? Их просто убивают на время и все, а новым говорят, что нету. Никто не гарантирует разработчикам, что в /mnt/sdcard вообще что-то есть, да еще с доступом на запись.

сам ознакомься, и не говори ерунды. Вероятность ремапа исчезающе мала, особенно если только-что была запись на сектор рядом. Сколько реаллокаций дорожек на твоём диске за всё время? Посчитай вероятность реаллокации.

В одних случаях может быть мала, в других велика. Ты не можешь расчитывать на это со 100%.

man fdisk. Распили диск, вначале идут более быстрые цилиндры. Даже с LBA. процентов так 5 ты выцыганишь.

это не факт. никто не обязывался.

Вообще, я кажется, догадываюсь, кто во флеше набыдлокодил. «память обычно копируется memcpy из начала в конец. Используй это!»

И да, «в разы» это ты что-то перебрал... В 2 раза максимум.

Это много.

Через полгода ее уже никто не вспомнит.

Если богатая контора будет проталкивать с тем же упорством, то забыть окажется сложно.

Пока гуёвые линуксовые лечилки дисков её однозначно не поддержат,

да ты ваще фантазер.

Считаешь, что добавить ещё одну ФС в partitionmanager и его гномий аналог нереально?

Затем же, зачем тебе вещества, под воздействием которых в ответ на сообщение про виндовый драйвер ты написал «в слаке это не работает».

ты укурился, и перепутал ЛОР с винфаком, на котором очевидно и хотел оставить свой пост про свой вендовый драйвер, который здесь никому не нужен.

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

нет. В андроиде не пробовал, но вот в Linux делал так неоднократно - создавал раздел, и перемонтировал туда корень. При этом старый корень размонтировался, и становился свободным. Без корня конечно жить нельзя, но это совсем не мешает его поменять в любой момент.

В одних случаях может быть мала, в других велика. Ты не можешь расчитывать на это со 100%.

а где написано про 100%?

это не факт. никто не обязывался.

факт. только профита в этом немного...

Вообще, я кажется, догадываюсь, кто во флеше набыдлокодил. «память обычно копируется memcpy из начала в конец. Используй это!»

я-то тут причём? я не пишу быдлокод. Если для тебя «заманчиво» юзать первые дорожки - я тебе рассказал как. Используй это, если «заманчиво». В данном случае хуже-то не станет, в отличие от memcpy(). А если и станет - ненамного, я ведь говорил - я проверил. Да, работает. Ненамного, но получше.

Это много.

много. Но не настолько, насколько ты пишешь. И ты ещё не учёл того факта, что основное время HDD тратит совсем не на чтение, а на то, что головками двигает. Потому куда важнее, что-бы данные были в одной куче, чем то, что они были в начале. Ну и забыл ты совсем о том, что плотность данных в начале диска меньше, чем в конце. Потому-что дорожки в начале короче. Это тебе не FDD.

Так, естественно, можно, но это делает всю ситуацию ненормальной. Если можно сколь угодно долго и полноценно работать с другим корнем, то на нем и надо оставаться. А старый корень смонтировать в /mnt/sdcard. А если нет, то это крайне ненадежно и неудобно.

Так, естественно, можно, но это делает всю ситуацию ненормальной.

это был ответ на

Было бы интересно глянуть, как ты корень у линукса отмонтируешь...

ответ - легко.

Вопрос «нормальности» касается лишь нормальности одмина, в некоторых ситуациях это вполне допустимо, и даже годно. Именно так я например перехожу на другой физический носитель - копирую туда систему, а потом перемонтирую туда же корень. УМВР ЧЯДНТ?

Конечно такой подход похож на FTL

...но строго хуже, потому что вынудит таскать код для разных архитекур.

Реализация же FTL «в железе» не даёт такой гибкости, лишь удорожая устройство. К тому же, дешёвые FTL проседают по производительности

Это спорно и не поддержано цифрами. Можно, конечно, перенести FTL в ОС, и делать ФС поверх «сырого» флеша, но в результате MS сделает свою закрытую реализацию, а все остальные пойдут на юг. И всё это - ради каких-то неочевидных выгод.

«ты укурился, и перепутал ЛОР с винфаком, на котором очевидно и хотел оставить свой пост про свой вендовый драйвер, который здесь никому не нужен.»

Все он правильно написал. Линуксоидам надо постоянно напоминать про убогость их поделок.

Для этого у андроидов поддиректория /mnt/storage (или /mnt/sdcard) может быть выполнена в виде отдельного файла с образом ФС, подключаемым через loop. Но в современных андроидах хранят все данные на ext.

Фирма Apple выпускает и компьютерное железо, и программное обеспечение. Это приводит к тому, что их операционная система максимально оптимизирована для работы на конкретном железе и использует его возможности на все 100%. Очевидно, что Samsung пытается копировать эту модель.

вам промыли мозги

я-то тут причём? я не пишу быдлокод. Если для тебя «заманчиво» юзать первые дорожки - я тебе рассказал как.

Ты делаешь совершенно неправомерные предположения, ровно такие же, как адобовцы. Есть слои абстракции и на уровне fs уже нет никаких дорожек, есть только блочное устройство, а под этим блочным устройством может быть что угодно. Ты можешь разбить fdisk-ом блочное устройство, но никтошеньки не обязывался «начало» в fdisk размещать в начале реального устройства. Блочным устройством может быть файл через loopback, размазаный случайным порядком по всему устройству, или кусок ОЗУ или что угодно.

Еще раз. Никто не обязывался соблюдать твои смелые предположения о том, как и где будут размещены твои данные. Это не более, чем временная практика, которая может быть изменена в люой момент. И ФС, которая пытается эту практику учесть в своих алгоритмах, заранее обречена.

Используй это, если «заманчиво». В данном случае хуже-то не станет, в отличие от memcpy(). А если и станет - ненамного, я ведь говорил - я проверил.

Это именно то, что говорят все быдлопрограммисты, в том числе адоба. Мы же проверили - работает!

много. Но не настолько, насколько ты пишешь.

в два раза, это уже разы. У меня скорость варьировалась от 75мб/сек до 25мб/сек

И ты ещё не учёл того факта, что основное время HDD тратит совсем не на чтение, а на то, что головками двигает.

Для этого кеш в само драйве и в операционной системе придуман.

Потому куда важнее, что-бы данные были в одной куче, чем то, что они были в начале.

Ну и забыл ты совсем о том, что плотность данных в начале диска меньше, чем в конце. Потому-что дорожки в начале короче. Это тебе не FDD.

Несколько фактов. Начало диска находится снаружи, а не внутри. Дорожки в начале диска длиннее, а не короче.

Плотность данных по всей площади диска как раз примерно одинакова, поскольку на первых дорожках секторов больше, чем на последних. Правда количество секторов меняется скачкообразно, по зонам, так что плотность плавает в пределах одной зоны и действительно в начале зоны несколько меньше, чем в конце.

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

ответ - легко.

согласен, вне контекста решаемой задачи легко. ;)

Вопрос «нормальности» касается лишь нормальности одмина, в некоторых ситуациях это вполне допустимо, и даже годно. Именно так я например перехожу на другой физический носитель - копирую туда систему, а потом перемонтирую туда же корень. УМВР ЧЯДНТ?

с этим спорить вообще не буду. сам так периодически делаю.

Для этого у андроидов поддиректория /mnt/storage (или /mnt/sdcard) может быть выполнена в виде отдельного файла с образом ФС, подключаемым через loop.

Еще проще нарезать устройство на партиции. Но это не решает вопросов

1) доступа из хостовой машины к корню, а не только к /mnt/sdcard

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

Но в современных андроидах хранят все данные на ext.

Когда есть отдельный объем под данные, то андройду пофиг. Он прекрасно дружит и с vfat. Проблема вовсе не в выборе ext.

Я тебе рассказываю о том, как сделано сейчас, ты мне рассказываешь о том, как можно сделать. Рассказывай самсунгу.

доступа из хостовой машины к корню, а не только к /mnt/sdcard

На андроидах даже с MTP такой доступ есть только к sdcard. К корню только через adb.

Я тебе рассказываю о том, как сделано сейчас, ты мне рассказываешь о том, как можно сделать. Рассказывай самсунгу.

у меня есть телефон mione , планшеты acer a500, ноут toshiba ac100 и микрокомп mk802.

Везде обычные партиции mmcblkXp[12345]

На андроидах даже с MTP такой доступ есть только к sdcard. К корню только через adb.

Вот поэтому я и пользуюсь curlftpfs и горя не знаю. ;)

вам промыли мозги

хороший аргумент в оправдание Samsung

Замечательно

хм...

Самсунг кроме карявых теликов ничего ещё годного не придумал, темболее не произвёл. Как бэ намикаю ;)

«Самсунг кроме карявых теликов ничего ещё годного не придумал, темболее не произвёл. Как бэ намикаю ;)»

Меня мой телефон и мои Blu-ray плееры вполне устраивают.

PS Подозреваю, что это ты не произвел ничего, кроме жидкого кала. А Самсунг уже давно весь мир своими товарами обеспечивает, и корейцев и жителей остального мира работой обеспечивает.

Дети не видели, компоненты какой фирмы стоят в аппаратуре большинства остальных фирм :3

Меня мой телефон и мои Blu-ray плееры вполне устраивают.

Рад за вас! То, что вас устраивает — ещё ничего не говорит.

Дети не видели, компоненты какой фирмы стоят в аппаратуре большинства остальных...

....а-ля остальных недокитайских фирм. Да ради бога! Пусть пичкают своё барахло в другое такое барахло.

Я же говорю про достойные товары!

«Я же говорю про достойные товары!»

Что ты подразумеваешь под достойными товарами? Во всех практически экранах - матрицы Самсунг. А в яПадах и яМобилках - вся начинка самсунговская.

«Рад за вас! То, что вас устраивает — ещё ничего не говорит»

Видать, вы незнакомы с научным подходом. А научный подход гласит - если один случай не подтверждает вашу гипотезу, то и вся ваша гипотеза не стоит яйца выеденного.

ext4

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
orion            1G    58  97 14442  18  6926  19   575  98 15994  27 183.7  38
Latency               546ms    2294ms    2539ms   39874us   48471us   63811us
Version  1.96       ------Sequential Create------ --------Random Create--------
orion               -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2429  36 +++++ +++  3765  42  2432  33 +++++ +++  4217  48
Latency             12506us    3089us    3814us     172ms     846us    2536us

f2fs

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
orion            1G   124  96 13141  12  6621  18   540  98 16934  26 590.8 117
Latency             77038us    1633ms    2382ms   35962us   53056us   58132us
Version  1.96       ------Sequential Create------ --------Random Create--------
orion               -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1115  21 +++++ +++ 10300  82  1550  29 +++++ +++  8528  92
Latency               315ms    1438us    1374us   35279us     725us    1979us

Мегапрофитов не видно на первый взгляд.

Все он правильно написал. Линуксоидам надо постоянно напоминать про убогость их поделок.

не говори - таким «линуксоидам» как ВЫ надо постоянно напоминать о том, какая-же убогая EXT2 в этой вашей венде.

Вот только _мне_ об этом не нужно, ибо _все_ вышеперечисленные глюки и косяки в Slackware Linux НЕ воспроизводятся. Т.ч. идите на винфак, и уже там обсуждайте убогость EXT2, здесь вас никто не понимает.

Фирма Apple выпускает и компьютерное железо, и программное обеспечение. Это приводит к тому, что их операционная система максимально оптимизирована для работы на конкретном железе и использует его возможности на все 100%. Очевидно, что Samsung пытается копировать эту модель.

вам промыли мозги

причём 20 лет назад.

Ты делаешь совершенно неправомерные предположения, ровно такие же, как адобовцы. Есть слои абстракции и на уровне fs уже нет никаких дорожек, есть только блочное устройство, а под этим блочным устройством может быть что угодно. Ты можешь разбить fdisk-ом блочное устройство, но никтошеньки не обязывался «начало» в fdisk размещать в начале реального устройства. Блочным устройством может быть файл через loopback, размазаный случайным порядком по всему устройству, или кусок ОЗУ или что угодно.

всё это я и без тебя прекрасно знаю. Однако, это совсем не запрещает мне знать и другое, а именно то, что /dev/sda у меня, это вовсе не сферический конь в вакууме, это вполне конкретный WD100EB-00CGH0, а вовсе не кусок памяти, или ещё какая-то НЁХ. Мало того, именно на этом WD100EB-00CGH0 «начало» диска несколько более быстрое, не взирая на то, что какой-то твой сферический вакуумный HDD может иметь более медленное «начало». Это также относится ко всем HDD, которые мне попадались, и причина этого очень проста - так исторически сложилось, и нет никакого профита это менять. К тому же и бенчмарки тестят именно «начало», и потому в «независимых тестах» побеждают именно такие диски, а не какие-то другие.

Проблема адобы совсем в иной плоскости - если вдруг я буду так размечать SSD, у которого всё равно куда писать/читать by design, то это НЕ приведёт ни к чему плохому. А вот адоба прямо нарушила документацию, используя memmove() _вместо_ memcpy(). Где в документации написано, что _нельзя_ делать систему в начале диска?

Еще раз. Никто не обязывался соблюдать твои смелые предположения о том, как и где будут размещены твои данные. Это не более, чем временная практика, которая может быть изменена в люой момент.

зачем это менять?

И ФС, которая пытается эту практику учесть в своих алгоритмах, заранее обречена.

вот создатели EXT4 с тобой не согласны. И создатели сабжа тоже. Единственная известная мне FS, которая ничего не учитывает, это FAT, и которая живая лишь из-за своей тупой простоты, из-за того, что маздай ничего больше не умеет (NTFS и ISO9660 не в счёт, ибо эти фс как раз оптимизированы, первая под HDD, вторая под оптику)

Это именно то, что говорят все быдлопрограммисты, в том числе адоба. Мы же проверили - работает!

эти быдлопрограммисты знают, что случится, если что-то пойдёт не так? Они об этом подумали? Нет. Нет. А я вот подумал и знаю.

в два раза, это уже разы. У меня скорость варьировалась от 75мб/сек до 25мб/сек

ну и что? большинство времени HDD тратит на перемещение между дорожками. Только в тестах под init 1 или MS-DOS можно линейно читать один кусок. Какая разница, что скорость чтения не 2.5мс, а 7.5мс, если тебе надо 100мс, что-бы передвинуть головки? Вот если изолировать систему в небольшой локальной области, это по любому будет быстро, и даже не потому, что там скорость чтения в разы больше, там головки далеко не нужно двигать.

Несколько фактов. Начало диска находится снаружи, а не внутри. Дорожки в начале диска длиннее, а не короче.

какая разница, где находится начало? Как из фразы, что «плотность данных в начале диска меньше, чем в конце. Потому-что дорожки в начале короче. Это тебе не FDD.» ты вывел, что я начало считаю «внутри» или «снаружи»?

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

мне глубоко поровну до этой скорости, ибо она практически не влияет на результат.

согласен, вне контекста решаемой задачи легко. ;)

я уже сказал о том, что «отмонтировать корень в линуксе» можно, и это не сложно. Что там в контексте какого-то конкретного андроида - мне неведомо.

Самсунг кроме карявых теликов ничего ещё годного не придумал, темболее не произвёл.

у самсунга вполне годные телефоны класса «только звонить», у меня есть вполне годный монитор ЭЛТ именно самсунга (уже много лет служит), именно самсунг делает годные флешки, которые все покупают (и ты тоже. Если не веришь - разбери и посмотри). Телевизоры тоже вполне годны.

Если ты в быту юзаешь холодильник с МСВС на борту - мне тебя искренне жаль...

Я же говорю про достойные товары!

холодильники с МСВС на борту? Я такие видел. Это действительно достойно.

Самсунг разработал новую файловую систему - НенужноФС

Мегапрофитов не видно на первый взгляд.

ещё-бы: мегапрофит не для тебя, а для самсунга - в теории, благодоря её ФС, будет намного меньше возвратов из-за того, что её чипы выходят из строя. А ресурс на NAND как был циклов так 100(гарантированно), так и остался, и _все_ достижения исключительно благодаря контроллерам и ФС. И ФС оптимизированная под NAND куда как лучше, чем ФС вообще не оптимизированная (*FAT*), хотя последняя и лучше, чем оптимизированная под HDD(читай все остальные). У NAND имеются два принципиальных отличия от HDD

1. Низкая скорость чтения/записи, которая ниже даже чем у HDD. Однако, хотя скорость чтения/записи и низкая, но она совершенно не зависит от того, где мы читали/писали данные в прошлый раз. HDD обеспечивает быструю запись/чтения _одного_ большого потока данных, а вот NAND так не умеет, за то может писать сразу Over9000 потоков, не хуже, чем один. Именно это обычно и нужно.
2. В HDD всё равно, читаем мы или пишем данные, он разбивается исключительно от общего времени, и от того, насколько активно мы дёргаем головками. В NAND всё наоборот - нет абсолютно никакой разницы между рандомной и линейной записью/чтением, однако, записывать в одну ячейку можно очень редко. Потому флешки появились не в 1984ом, а в 2010 примерно(достаточно большие и достаточно дешёвые), только после того, как самсунг наклепала дешёвых контроллеров, размазывающих рандомно данные по всему массиву NAND. Т.е. флешки - это совсем не теоретический прорыв, ничего нового нет тут. Тут прорыв чисто технологический - производство контроллеров сейчас уже достаточно дёшево.

Вот ещё ФС под это дело, и будет вообще классно. И я рад, что эта ФС уже есть, и уже есть патчи, которые позволят мне заюзать её в моём компе, а не где-то там в головах теоретиков и аналитегов.

И да, ещё забыл про идиотскую особенность NAND: писать-то там довольно быстро, но вот стирать можно только большими «островами», причём очень медленно. Это by-design и не лечится. И такой особенности нет и не может быть на HDD. Такое ближе скорее к оптическим дискам, которые тоже стираются «островами», причём целиком. Естественно, создатели EXT об этом даже и не задумывались...