ожидаемый коммент от аплфана. причем тут самсунг то вообще?

вот меня всё интересует почему на лоре анонимусов не отключат?! Человек боится высказать своё мнение и прячется за анонимом,что бы его не поругали. Как дети малые.

«Человек боится высказать своё мнение и прячется за анонимом,что бы его не поругали. Как дети малые.»

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

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

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

на этом предлагаю закончить бесполезный флуд не то теме.

Этим анонимусом был я

всё это я и без тебя прекрасно знаю. Однако, это совсем не запрещает мне знать и другое, а именно то, что /dev/sda у меня, это вовсе не сферический конь в вакууме, это вполне конкретный WD100EB-00CGH0,

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

Проблема адобы совсем в иной плоскости - если вдруг я буду так размечать SSD, у которого всё равно куда писать/читать by design, то это НЕ приведёт ни к чему плохому.

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

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

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

вот создатели EXT4 с тобой не согласны.

создатели ext4 как раз делают правомерные оптимизации. Например, можно удалить журнал. Это понятная оптимизация, не нарушающая уровни абстракции.

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

ну так логично изолировать систему в самой быстрой области?

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

Потому что дорожки в начале длиннее, а не короче. Это внешний край край пластины. длинна дорожки 2PR. А плотность данных по всему диску примерно одинакова.

вот меня всё интересует почему на лоре анонимусов не отключат?! Человек боится высказать своё мнение и прячется за анонимом,что бы его не поругали. Как дети малые.

отключали. Не помогает. Я другого не пойму, почему школьники не свалят на свой уютный фконтакт, где смогут обсудить свои мыслишки с себе подобными?

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

4.2

Своё мнение можно высказывать и регистранту. Я - высказываю. Ты тоже можешь, и никто тебя не забанит и не заблокирует. Просто это ЛОР, а не Православный Собор и Радио Радонеж, и твоё мнение за геев и Ъ Православие тут тупо НЕ НУЖНО. Причём не зависимо от мнения модератора на туже самую тему.

А теперь, пожалуйста, расскажи нам о своём видении F2FS?

Поверх которого может быть создан lvm и оппа...

э... Читать умеем, да? Это МОЙ диск, и на нём нет, и никогда не было LVM! Можешь подъехать и проверить. Пива не забудь, ибо ты проспорил.

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

всё дело в том, что существующие сейчас ФС заточены именно под HDD, и профит от более высокой скорости в начале - это лишь одна из Over9000 особенностей, далеко не самая важная. Есть и другие, см. выше. Насколько я знаю, в других FS поддержка NAND реализована исключительно костылями, и не даёт эффекта. Вот взгляни на EXT4 без журнала: оно конечно жить-то дольше будет, но где, как не в сменных дешёвых девайсах нужен журнал? Если ты вырвешь HDD - это аварийная ситуация, а вытащить флешку - обычное дело. Потому именно на флешке должен быть хороший журнал, что-бы сохранить те файлы, которые ты успел туда скопировать. Только журнал должен быть какой-то особый, не тот, что оптимизирован для HDD.

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

как-бы не менялись HDD, их особенности остаются. И что-бы добиться профитов, эти особенности _надо_ учитывать. К примеру есть смысл резервировать в конце нового файла 8 блоков, что-бы файлы были не сильно фрагментированны, как это делает EXT4. Иначе, при чтении таких файлов, головкам придётся скакать по всему диску, что будет очень медленно. В SSD тоже фрагментация мешает, но совсем по другим причинам - если большой файл лежит в двух областях годных для стирания (такие области занимают сотни К), то придётся стирать обе эти области, что очевидно вдвое дольше. Однако, что касается чтения, то нет почти никакой разницы, как фрагментирован файл на SSD (без учёта упреждающего блочного чтения).

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

создатели ext4 как раз делают правомерные оптимизации. Например, можно удалить журнал. Это понятная оптимизация, не нарушающая уровни абстракции.

Это лечение насморка путём удаления головы. Как я уже говорил, на сменном носителе типа флешки журнал необходим. Да и вообще, NAND это ненадёжная технология by design, ты конечно всегда можешь сделать ремап битого блока, но что станет с теми данными, что ты туда записал? Журнала-то нет! Прощай не только данные, но и даже структура ФС, а следовательно - и сама ФС. Что ты можешь говорить о надёжности системы, в которой любой кусок в 100К может ВНЕЗАПНО взять, и отъехать в мир иной? Да, тебе сразу дадут другой, новый, а тебе от этого легче, если твоя EXT4 без журнала порушится нафиг? Знаешь, куда чаще всего пишется данные? В суперблок. Вот он-то у тебя и гавкнется с вероятность 50/50. И похоронит всю ФС нафиг. Впрочем, ты всегда можешь сказать FORMAT C: и winnt -b или как там венду переставляют?

ну так логично изолировать систему в самой быстрой области?

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

Потому что дорожки в начале длиннее, а не короче. Это внешний край край пластины. длинна дорожки 2PR. А плотность данных по всему диску примерно одинакова.

ты разве не понял, что «началом» я считаю дорожку №0. Она самая быстрая со времён FDD и до сего дня, причём мне всё равно, где именно она находится физически. Мало того, даже если дорожка №0 самая медленная, доступ к ней всё равно самый быстрый, ибо именно там моя система, там рядышком TMPDIR, и именно там с большой вероятностью обитает головка HDD. На другие области головка путешествует исключительно за громадными мультимедиафайлами, читая их большими и жирными кусками, получая 100500 профитов от высокой линейной скорости. Профит от высокой скорости на дорожке №0 получить очевидно не получится, ибо в системе практически нет больших файлов. (ну кроме образа ядра, который НЕ читается при работе системы, только на загрузке).

«НЕ НУЖНО»

А где еще можно обсудить эти проблемы, кроме как на ЛОР? Тут самая большая концентрация анонимных экспертов. Да и feofilы водятся непуганные.

«А теперь, пожалуйста, расскажи нам о своём видении F2FS?»

Радует, что будет хотя бы одна ФС для флеш-памяти. Доволен?

А где еще можно обсудить эти проблемы, кроме как на ЛОР? Тут самая большая концентрация анонимных экспертов. Да и feofilы водятся непуганные.

ну не знаю. Лично я предпочёл бы обсудить проблемы геев и ПГМнутых в другом месте. На ЛОРе я как раз потому, что лично меня не волнуют проблемы тех и других. Мало того, я не являюсь их сторонником и их противником, я к ним вообще никак не отношусь.

Потому личная просьба к геям, ПГМнутым и модераторам - об этих проблемах пожалуйста просто не нужно.

Радует, что будет хотя бы одна ФС для флеш-памяти. Доволен?

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

Что ты можешь говорить о надёжности системы, в которой любой кусок в 100К может ВНЕЗАПНО взять, и отъехать в мир иной?

Здесь я не совсем уверен, но доступ на чтение вроде остается.

Знаешь, куда чаще всего пишется данные? В суперблок. Вот он-то у тебя и гавкнется с вероятность 50/50.

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

Здесь я не совсем уверен, но доступ на чтение вроде остается.

да, конечно! Сейчас тебе «доступ»... Это выглядит так:

1. пишешь файлы - всё хорошо
2. проверяешь - ОК
3. umount/mount - OK
4. вынимаешь/вставляешь - MD5 не сходится. Где именно? В СЛУЧАЙНОМ месте.

ИЧСХ, если попадёт на суперблок, то всё, ппц котёночку - оно тупо не смонтируется. Правда для EXT4 можно попробовать fsck, mkfs, или testdisk. Иногда помогает, если с образом. Ну а если это системный диск, и если запустить fsck -y, то скорее всего оно убьёт полностью FS.

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

не буду смеяться. Я в курсе, как восстановить суперблок. У тебя ещё не потерялась бумажечка с координатами резервных суперблоков? Нет такой бумажечки? Ой... Беда... Ну тогда быстрей беги делай mke2fs -n, и записывай для EXT, если конечно ты ТОЧНО помнишь ВСЕ опции создания этой ФС.

Если бумажечка есть, то конечно fsck.ext4 -b тебе поможет. Если конечно ты перед этим не убил всё, что только можно, командой fsck -y.

не буду смеяться. Я в курсе, как восстановить суперблок. У тебя ещё не потерялась бумажечка с координатами резервных суперблоков? Нет такой бумажечки? Ой... Беда... Ну тогда быстрей беги делай mke2fs -n, и записывай для EXT, если конечно ты ТОЧНО помнишь ВСЕ опции создания этой ФС.

на ext признаюсь, не восстанавливал. А на xfs пришлось недавно. xfs_repair долго сканировал весь образ, но нашел и сам восстановил.

вынимаешь/вставляешь - MD5 не сходится. Где именно? В СЛУЧАЙНОМ месте.

Да, было такое. Я по правде говоря, относил это на счет хреновости конкретной флешки.

раунд 2

ext4

readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio 1.59
Starting 2 processes
readtest: Laying out IO file(s) (1 file(s) / 200MB)
writetest: Laying out IO file(s) (1 file(s) / 200MB)
Jobs: 1 (f=1): [r_] [99.0% done] [3255K/0K /s] [794 /0  iops] [eta 00m:07s]  
readtest: (groupid=0, jobs=1): err= 0: pid=11195
  read : io=204800KB, bw=294929 B/s, iops=72 , runt=711069msec
    slat (usec): min=629 , max=7445.5K, avg=13825.72, stdev=159742.42
    clat (usec): min=264 , max=74838K, avg=430535.89, stdev=2570197.05
     lat (msec): min=1 , max=74841 , avg=444.37, stdev=2632.30
    bw (KB/s) : min=    0, max= 4712, per=199.02%, avg=573.19, stdev=1125.27
  cpu          : usr=0.36%, sys=1.52%, ctx=53318, majf=0, minf=95
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w/d: total=51200/0/0, short=0/0/0
     lat (usec): 500=0.01%
     lat (msec): 2=0.01%, 4=0.01%, 10=0.01%, 20=0.02%, 50=68.62%
     lat (msec): 100=9.89%, 250=2.31%, 500=5.21%, 750=4.04%, 1000=3.24%
     lat (msec): 2000=3.44%, >=2000=3.21%
writetest: (groupid=0, jobs=1): err= 0: pid=11196
  write: io=204800KB, bw=363428 B/s, iops=88 , runt=577046msec
    slat (usec): min=41 , max=87253K, avg=11228.58, stdev=440651.74
    clat (usec): min=127 , max=87262K, avg=349390.91, stdev=2566155.64
     lat (usec): min=175 , max=87262K, avg=360626.78, stdev=2609047.74
    bw (KB/s) : min=    1, max=38152, per=147.10%, avg=520.74, stdev=2713.89
  cpu          : usr=0.32%, sys=1.36%, ctx=13721, majf=0, minf=15
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w/d: total=0/51200/0, short=0/0/0
     lat (usec): 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
     lat (msec): 2=2.33%, 4=64.97%, 10=4.46%, 20=0.51%, 50=0.22%
     lat (msec): 100=0.70%, 250=6.19%, 500=6.70%, 750=5.63%, 1000=3.13%
     lat (msec): 2000=2.13%, >=2000=3.02%

Run status group 0 (all jobs):
   READ: io=204800KB, aggrb=288KB/s, minb=294KB/s, maxb=294KB/s, mint=711069msec, maxt=711069msec
  WRITE: io=204800KB, aggrb=354KB/s, minb=363KB/s, maxb=363KB/s, mint=577046msec, maxt=577046msec

Disk stats (read/write):
  mmcblk0: ios=55891/44622, merge=2310/9316, ticks=1033920/50734840, in_queue=51768320, util=98.94%

f2fs

readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio 1.59
Starting 2 processes
readtest: Laying out IO file(s) (1 file(s) / 200MB)
writetest: Laying out IO file(s) (1 file(s) / 200MB)
Jobs: 1 (f=1): [r_] [99.0% done] [2473K/0K /s] [603 /0  iops] [eta 00m:01s]  
readtest: (groupid=0, jobs=1): err= 0: pid=11144
  read : io=204800KB, bw=2077.6KB/s, iops=519 , runt= 98579msec
    slat (usec): min=624 , max=2859.6K, avg=1812.74, stdev=23828.17
    clat (usec): min=814 , max=17002K, avg=59700.23, stdev=374453.22
     lat (msec): min=2 , max=17014 , avg=61.55, stdev=382.12
    bw (KB/s) : min=    1, max= 4344, per=116.36%, avg=2416.71, stdev=783.43
  cpu          : usr=3.00%, sys=16.06%, ctx=54977, majf=0, minf=76
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w/d: total=51200/0/0, short=0/0/0
     lat (usec): 1000=0.01%
     lat (msec): 4=0.01%, 10=0.01%, 20=0.01%, 50=89.09%, 100=9.86%
     lat (msec): 250=0.53%, 500=0.22%, 750=0.06%, 1000=0.03%, 2000=0.04%
     lat (msec): >=2000=0.15%
writetest: (groupid=0, jobs=1): err= 0: pid=11145
  write: io=204800KB, bw=13209KB/s, iops=3302 , runt= 15504msec
    slat (usec): min=35 , max=1792.1K, avg=236.35, stdev=13420.35
    clat (usec): min=153 , max=2394.7K, avg=9390.95, stdev=95067.03
     lat (usec): min=197 , max=2394.8K, avg=9676.61, stdev=96589.02
    bw (KB/s) : min=  683, max=53528, per=159.33%, avg=21045.25, stdev=19687.23
  cpu          : usr=5.22%, sys=18.06%, ctx=2675, majf=2, minf=39
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued r/w/d: total=0/51200/0, short=0/0/0
     lat (usec): 250=0.01%, 500=0.01%, 750=0.01%
     lat (msec): 2=44.34%, 4=49.90%, 10=3.96%, 20=0.58%, 100=0.06%
     lat (msec): 250=0.50%, 500=0.29%, 1000=0.06%, 2000=0.24%, >=2000=0.06%

Run status group 0 (all jobs):
   READ: io=204800KB, aggrb=2077KB/s, minb=2127KB/s, maxb=2127KB/s, mint=98579msec, maxt=98579msec
  WRITE: io=204800KB, aggrb=13209KB/s, minb=13526KB/s, maxb=13526KB/s, mint=15504msec, maxt=15504msec

Disk stats (read/write):
  mmcblk0: ios=52934/773, merge=1114/2349, ticks=348530/946730, in_queue=1294810, util=85.03%

Итого - в этом тесте ext4 ЭПИЧНО медленнее.

ext4 с отключенным журналированием

какая из существующих уже давно FS лучше подходит для разделов на SSD? ext4, как я понимаю, пишет кучу избыточной инфы...

Ответ: ext4 с отключенным журналированием. Тогда она становится практически как ext2, только лучше. Почему? Потому что ext4 умеет рапределять блоки данных в разные места SSD, чем продлевает его срок службы до возможного для железа максимума.

Надо только уметь готовить ext4 для SSD. Все избыточные записи на диск - отключаемы. Например, как рабочий вариант:

1. tune2fs -o journal_data_writeback /dev/sda1 tune2fs -m2 /dev/sda1 2. vi /etc/fstab UUID=e787dd33-1f58-456b-afc3-c9943c8a8912 / ext4 errors=remount-ro,noatime,barrier=0 0 1 tmpfs /tmp tmpfs defaults 0 0 tmpfs /var/tmp tmpfs defaults 0 0 tmpfs /var/lock tmpfs defaults 0 0 tmpfs /var/spool/postfix tmpfs defaults 0 0 3. Добавляем параметр в /etc/sysctl.conf vm.laptop_mode=5 vm.dirty_writeback_centisecs = 15000 vm.swappiness=10 (если стоит kpowersaved, то все чуть сложнее, гугл) 4. комментируем все журналы в /etc/rsyslog.conf (просто mv /etc/rsyslog.d/* /etc/rsyslog.old/ ) 5. ln -sf /dev/null ~/.xsession-errors

Есть и другие оптимизации, но и так уже хорошо работает. 3 года SSD на ext4 - полет нормальный.

Вопрос, кстати, может не в тему, но все же:

У меня есть полусломанная USB флешка на 64 GB (Jet Flash). Проблема вот в чем - я форматирую ее под NTFS или FAT, операция проходит. Беру, скажем, мувиков на гигов 30-60, и говорю копировать. Где-то гигов 20 записывается, а потом выдается ошибка записи, и больше ничего уже нельзя записать. Как я понимаю, какая-то микросхема флешпамяти сдохла. А нет ли под линукс каких-то утилиты, которые бы позволяли отформатировать рабочие микросхемы, а неработающие области исключили бы из объема флешки?

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

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

Таскать код для разных архитектур не нужно. Достаточно x86, чтобы можно было запускать Windows.

Это спорно и не поддержано цифрами.

http://cyberempire.ru/6516831.php

{Ъ mode on}

X25-M: …

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

{Ъ mode off}

... в результате MS сделает свою закрытую реализацию, а все остальные пойдут на юг

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

http://cyberempire.ru/6516831.php

Но это сравнение разных FTL, а не FTL с ФС на сыром флеше, причем выводы сводятся к «разные SSD имеют разные характеристики».

Ничего не мешает MS сделать свою закрытую реализацию обычной файловой системы

Им нет необходимости, и они не делают. А ты предлагаешь сделать реализацию необходимой.

ext3fs dosfs