LINUX.ORG.RU

f2fs-tools 1.8.0

 , ,


6

4

Состоялся релиз f2fs-tools 1.8.0 — набора инструментов для F2FS. Данная ФС оптимизирована для работы на Flash-накопителях (в том числе и SSD).

Изменения в новой версии:

  • Улучшена работа fsck.f2fs.
  • Добавлена возможность восстановления потеряных файлов из dump.f2fs.
  • Добавлена поддержка зонированных (zoned) устройств и нескольких устройств.

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: anonymous_incognito (всего исправлений: 3)

Ответ на: комментарий от Silerus

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

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

dikiy ★★☆☆☆
()
Ответ на: комментарий от vblats

ext2

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

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

intelfx ★★★★★
()

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

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

fornlr ★★★★★
()
Ответ на: комментарий от makoven

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

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

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

vblats
()
Ответ на: комментарий от fornlr

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

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

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

vblats
()
Ответ на: комментарий от fornlr

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

vblats
()

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

Quasar ★★★★★
()

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

Deleted
()
Ответ на: комментарий от Silerus

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

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

h31 ★★★★
()
Ответ на: комментарий от dikiy

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

Silerus ★★★★
()
Ответ на: комментарий от unC0Rr

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

Silerus ★★★★
()
Ответ на: комментарий от Skullnet

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

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

Radjah ★★★★★
()
Ответ на: комментарий от h31

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

timdorohin ★★★★
()
Ответ на: комментарий от timdorohin

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

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

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

Aceler ★★★★★
()

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

charly_one
()
Ответ на: комментарий от Aceler

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

timdorohin ★★★★
()
Ответ на: комментарий от unC0Rr

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

Ну гонишь же:

mount -o sync <what> <where>
kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

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

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

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

timdorohin ★★★★
()
Ответ на: комментарий от timdorohin

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

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

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

Aceler ★★★★★
()
Ответ на: комментарий от timdorohin

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

timdorohin ★★★★
()
Ответ на: комментарий от Aceler

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

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

timdorohin ★★★★
()
Ответ на: комментарий от timdorohin

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

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

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

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

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

timdorohin ★★★★
()
Последнее исправление: timdorohin (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

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

timdorohin ★★★★
()
Ответ на: комментарий от timdorohin

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от sasha1024

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

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

timdorohin ★★★★
()
Последнее исправление: timdorohin (всего исправлений: 1)
Ответ на: комментарий от Necrogrinder

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

timdorohin ★★★★
()
Ответ на: комментарий от Necrogrinder

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

anonymous
()
Ответ на: комментарий от Radjah

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

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

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

vblats
()
Ответ на: комментарий от vblats

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

Щито?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

vblats
()
Ответ на: комментарий от vblats

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

cvv ★★★★★
()
Ответ на: комментарий от cvv

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

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

vblats
()
Ответ на: комментарий от vblats

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

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

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

cvv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.