f2fs-tools 1.8.0

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

F2FS не журналируемая что ли?

При чем тут fuse?

ext2

слетела при жёстком ребуте

Удивительно.jpg

А чего там? Используется оно в ведроидах или еще не готово?

ЗЫ: Всякие линейно цыганские прошивки от пионеров не интересуют.

А я читал что microsd (а тем более SSD) сами равномерно распределяют то, что ты в них пишешь. Зачем тогда еще раз распределять с помощью ФС?

Не все. Не сами. Они сами не знают, какие ячейки уже свободны, ибо инфа об этом не записывается с целью экономии ресурса перезаписи. Она узнается по желанию ОС командой TRIM (это если в общих чертах), которая может и не использоваться.

Лучше эту инфу хранить в таблице в оперативной памяти, что f2fs и делает.

А чего там? Используется оно в ведроидах или еще не готово?

Нет. И дело не в ведроиде. Дело в u-boot, который не может f2fs. Это шота типа Grub для бедных. Варианта два - как и на стационарном ПеКа, размещать ведро на нормальном разделе, но для этого надо приложить усилия, либо перепилить u-boot, но для этого надо приложить усилия.

Впрочем на мобильниках оно не нужно.

А замена exFAT на SD флешках в нищебродных моделях?

Наверняка оно уже реализовано в прошивке от Васяна.

Чем оно лучше ext2/ext3, когда на флешках и SSD свой контроллер, следящий за износом?

Поверх dm-crypt она нормально работает?

zfsonlinux
reiserfs 4

на форониксе сравнивали f2fs и ext4 на ssd. Последняя была быстрее.
Это к вопросу как.

F2FS is log-structured file system

Ни одна ФС не даёт никаких гарантий сохранности твоих данных при внезапном отключении. Журналируемость нужна только для гарантии сохранности структур самой ФС в консистентном состоянии.

Есть разные режимы журналирования.

Посмотри на bcachefs, может понравится.

Дело вот в чем, данные сначала отправляются в кеш, а потом уже фон записывает - и если напряжение пропадет,- то данные будут потеряны. И sync из-за этого выполняется очень долго. В фс где запись идет сразу, есть вероятность, что хоть что то успеет записаться.

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

распределяет запись в разные блоки

Это же вотчина контроллера, а не ФС.

Пробовал в второй малине делать раздел для данный yacy (активная запись почти всё время). За месяц флешка ушла в RO.

Можно для эксперимента купить еще одну флешку и потыкать ext4, но как-то денег жалко.

КПД у нее низкое, это не очень моему 60-гиговому винту...

Ни разу на моей памяти у меня не летела ext2

Отличный аргумент, ага. У целого одного тебя никогда не летела ext2.

Давай ты просто послушаешь взрослых дядей, которые администрировали больше, чем один комп. Ext2 летит. Летит быстро, надёжно, качественно.

А с mtd этот пакет утилит работает?

если ты считаешь, что fsck после обесточивания - не нормально, а «слетела» - считай на здоровье. Вот только после проверки все обычно на своих местах (привет, xfs!) и правильной длинны (экстенты! Еее!)

Ни одна ФС не даёт никаких гарантий сохранности твоих данных при внезапном отключении. Журналируемость нужна только для гарантии сохранности структур самой ФС в консистентном состоянии.

Ну гонишь же:

mount -o sync <what> <where>

Я dont_load_bitmap однажды протестировал с txmod=wa и долго ржал. 1МБ/с rsync - это очень хорошо! Хоть и через пару секунд прошло...

Ышшо одын свидетель zfs? Зачем нам такого монстра городить, и так без поллитры в алгоритме рейзера не разобраться.

Все основанное на последовательной структуре (log-based) медленнее, чем in-place альтернативы, если конечно не извращаться (хотя идея в zfs интересна, но того же самого можно добится банальным сжатием структуры свободных блоков). Так что особо смысла не вижу, разве чтоб было.

если ты считаешь, что fsck после обесточивания - не нормально, а «слетела» - считай на здоровье.

Я считаю, что когда у меня после работы fsck в lost+found два десятка файлов, которые должны были быть в других местах — это не нормально.

А для тебя ФС целостная — значит не слетела? А что там за файлы, да господь с ними, были файлы, нет файлов, кого волнуют эти файлы.

Ну вот я и говорю, давай запилим туда что-нибудь вместо битмапов. А идея log-structured списка занятых экстентов — просто первое, что пришло в голову (потому что недавно читал про zfs). Но и вообще, почему ты думаешь, что оно медленнее? Напротив, хранить на диске только лог, а дерево реконструировать в памяти — это вроде как очень красивая и хорошая идея.

Оно бессмысленно, лучше просто пожать чем-то вроде deflate/lzma. Результат тот же, гемора - меньше

Да и алгоритмы уже есть в ядре...

если тебе надо, что бы не было кусков файлов, используй опцию sync.

А так тебя и журналирование не спасет... просто не будет нужных кусков, а то и файлов целиком (энтерпрайз xfs)

А так тебя и журналирование не спасет... просто не будет нужных кусков, а то и файлов целиком (энтерпрайз xfs)

Не подменяй тему разговора, мы обсуждаем не XFS, а ext4 с журналированием. На ext4 у меня не будет сиротливых файлов из-за журналирования.

А то я тебе с JFS могу предложить сравнить, которая переживает, как оказалось по моему печальному опыту, взрыв контроллера жёсктого диска без потерь данных :-)

ext4 и без журнала тебе сирот не оставит. А вот дырки в файлах - за милую душу. И разве в lost+found не попадают только те файлы, которым после создания, до краша, sync не была сделана? Тогда тебе и журналирование не поможет, файлов просто не останется!

Там, оказалось, сделано хитрее!

https://blogs.oracle.com/bonwick/entry/space_maps

Вообще, задумка крутая, может и стоит прикрутить. Должна увеличится скорость выделения. За одно можно допилить и fallocate (его же не запилили до сих пор?)

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

Там, оказалось, сделано хитрее!

Так а я тебе о чём?

За одно можно допилить и fallocate (его же не запилили до сих пор?)

Нет. Я хотел, но учёба съедает всё время (даже precise discard не доделал ещё).

А LZO/LZ4/snappy?

LZO - шустрое,используестся много где, степень сжатия меньше, чем у deflate

LZ4 & snappy - бесполезное нинужно с очень хреновым сжатием в блочном режиме... Для ФС не подходят совсем никак...

LZ4 почти не грузит проц и жмёт нормально, то что жмётся. Для ФС и слабых тачек самое то.

БЛОКИ, КАРЛ! БЛОКИ! lz4 относительно неплохо жмет 4+ МиБ куски. Меньше - степень сжатия пробивает днище...

https://habrahabr.ru/post/183230/

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

на форониксе сравнивали f2fs и ext4 на ssd. Последняя была быстрее. Это к вопросу как.

Нет. В большинстве - почти наравне. В некоторых тестах - уделала ext4 c большим отрывом.

http://www.phoronix.com/scan.php?page=article&item=linux-44-47-fs&num=3

Это же вотчина контроллера, а не ФС.

Уже писал по этому поводу. Контроллер умеет такое делать. Но он не делает этого по умолчанию, потому что сам не знает какие блоки свободны. Эта фича активируется явной командой TRIM, но слишком часто ее тоже нельзя использовать.

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

Спасибо!

Уже писал по этому поводу. Контроллер умеет такое делать. Но он не делает этого по умолчанию, потому что сам не знает какие блоки свободны. Эта фича активируется явной командой TRIM, но слишком часто ее тоже нельзя использовать.

Щито?

потому что сам не знает какие блоки свободны.

Все он знает ...

Я в общих чертах написал, но могу и технически разжевать, если интересно что происходит в недрах например Sandforce :)

В таком случае это обьясняет их никудышнюю репутацию.

Нет не знает. Хотя бы потому, что с его точки зрения и «ноль» и «единица» - это информация. Когда ты удаляешь файл в ФС, ты чаще всего удаляешь только его заголовок. Информация об этом контроллеру НЕ ПЕРЕДАЕТСЯ, и контроллер, действительно имея возможность распределять нагрузку между блоками, не может делать это в широких пределах.

Вы удалили 30-ти гигабайтный фильм с 32-гигабайтного диска, но контроллер при записи новых файлов будет распределять их в двух гигабайтах, а не 32-х. Если сама ФС не подскажет.

Если так делает Sandforce, это не значит что другие делают также.

Если сама ФС не подскажет.

Как мед так и ложкой.