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)

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

И да и нет. В свое время пришлось повозиться с SSD-шниками. В том числе подключенными по UART в режиме дебага. Все что выполняет прошивка - выводилось на экран.

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

А по поводу механизма релокации - он будет таким до тех пор, пока SSD-шники используют дешевые слабенькие контроллеры. Следить за тем, что куда пишется и держать это в базе - не дешевое удовольствие ни по цене, ни по скорости. ФС используют порядка 15% емкости диска под эти таблицы. Допустим для контроллера это можно будет сократить до 5%. Вот и считайте, в довесок к 120 гигабайтному NAND-пулу, придется добавить еще 6 гиг, и только ради того чтобы ОС могла не посылать раз в день команду TRIM. И это не считая софта, не считая обвязки. В общем производители считают что оптимальнее это переложить на плечи ОС.

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

Попробуй. Ты хочешь сказать, что контроллеры SSD не делают wear leveling, если им не помогать TRIM'ом? Тогда почему у меня на SSD всё ещё жив /boot с FAT32, если учесть, что на этом разделе суперблок и собственно FAT были перезаписаны по меньшей мере несколько тысяч раз?

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

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

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

Я-то знаю.

Но ты сам говорил:

Контроллер умеет такое делать. Но он не делает этого по умолчанию

Так, получается, всё же делает (хоть и хуже)?

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

если учесть, что на этом разделе суперблок и собственно FAT были перезаписаны по меньшей мере несколько тысяч раз?

Cовременные NAND держат порядка нескольких миллионов циклов.

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

В данном топике, всё же, речь об обычных ssd.

В лучшем случае mlc, а то и tlc. И очень редко slc.

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

Хммм ... Попахивает циклом Read-Modify-Write, но никогда недумал что результаты могут быть настолько печальны ...

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

Где ты только такую чушь про миллион циклов вытащил? Даже у толстых техпроцессов slc-эпохи больше сотен тысяч я не видел.

Разводилово про новые типы памяти одымают каждый год, а воз и по ныне катится на дно...

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

Это печально разве что для хайлоад серверов СУБД каких-нибудь, а на десктопе исчерпать ресурс памяти не представляется возможным при типичном использовании.

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

Где ты только такую чушь про миллион циклов вытащил?

А непомню. Я отошел от темы лет 5 назад.

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

Так, получается, всё же делает (хоть и хуже)?

Суть проблемы в том, что для того, чтобы что-то записать на flash, надо сначала стереть то, что там было записано ранее. В NAND flash размер блока для стирания (сотни килобайт) существенно превышает размер блока для записи (единицы килобайт). Если SSD ничего не знает про файловую систему, то он предполагает, что все блоки используются и износ может регулироваться только обменом блоков _для стирания_ (поскольку иначе невозможно) из разных физических мест, а это приводит к тому, что появляется дополнительный износ, если реально один из обмениваемых блоков в файловой системе не используется (за счёт того, что он всё равно перезаписывается). Из-за того, что блоки для стирания большие, это может быть проблемой (то есть драйвер ФС всё время долбится в одни и те же 4 килобайта, а по SSD гоняется порция 512 килобайт для равномерного износа). Поэтому специализированная ФС для SSD способна снизить его износ, даже если там уже есть встроенная регулировка износа.

TRIM — это способ сообщить SSD список неиспользуемых файловой системой блоков, чтобы контроллер SSD просто стёр их и не пытался при физической релокации блоков сохранить их содержимое.

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

Я прекрасно это знаю. То был наводящий вопрос vblats'у.

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

И что, что sync? От этого пропадание питание посередине записи файла перестаёт оставлять файл в полузаписанном состоянии?

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

И что, что sync? От этого пропадание питание посередине записи файла перестаёт оставлять файл в полузаписанном состоянии?

Оно оставит файл в четко детерминированном состоянии. У тебя pwrite() не вернется, пока данные на диске не окажутся. Не говоря уже о том, что у ФС нет понятия «полузаписанный файл».

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

У тебя pwrite() не вернется

И в этот момент питание и пропадёт.

Не говоря уже о том, что у ФС нет понятия «полузаписанный файл».

Есть. Блоки распределены, из таблиц свободных удалены, а в таблицы занятых конкретного inode записаться не успели.

И вообще, всё это ерунда по сравнению с тем, что приложений, работающих по принципу: записали флаг: «транзакция началась», сделали sync, начали писать туда и сюда, сделали sync, удалили флаг транзакция началась, сделали sync - по пальцам пересчитать. Ну разве что большие СУБД.

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

И в этот момент питание и пропадёт.

Запись атомарна. Она либо есть, либо её нет.

Есть. Блоки распределены, из таблиц свободных удалены, а в таблицы занятых конкретного inode записаться не успели.

Для этого нужен журнал.

И вообще, всё это ерунда по сравнению с тем, что приложений, работающих по принципу: записали флаг: «транзакция началась», сделали sync, начали писать туда и сюда, сделали sync, удалили флаг транзакция началась, сделали sync - по пальцам пересчитать. Ну разве что большие СУБД.

Ага. Потому что это чаще всего никому не нужно. Хотя есть rsync, который сперва пишет в .file, а потом делает атомарный move в file.

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

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

cvv ★★★★★
()

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

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

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

Эта штука в первую очередь нужна для SSD.

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

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

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

Запись атомарна. Она либо есть, либо её нет.

Как и питание. И эти два события не коррелируемы без UPS.

Потому что это чаще всего никому не нужно. Хотя есть rsync, который сперва пишет в .file, а потом делает атомарный move в file.

Это нужно всем, когда некое одно действие предполагает более одной записи, да хоть в один файл. Но гимор на ровном месте. И ваша атомарность совсем не по делу, вы собираетесь всегда гигабайты перезаписывать?

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

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

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

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

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

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

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

Так никто не предлагает покупать. Просто попроси у когото посмотреть свою гугль почту через веб-морду под гостевым аккаунтом.

Да, я согласен что это лоторея, но - полгода - это ты загнула.

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

гуголь почту я проверяю раз в день. особой скорости тут не нужно. на стареньком слабом ноуте с внешним винтом на USB2 всё работает превосходно.

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

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

Кроме скорости еще есть латенси. Уменьшение латенси на десктопе радикально улучшает отзывчивость всего монстрообразного: Хрома, Файрфокса и офисов.

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

ЛПП, на самом деле.

Зачем винтам (повторюсь - винтам, не твердотельникам!) какой-то накопитель, если у них есть синхронный мотор и очень большая масса на оси? Во всех современных винтах головки и схема питаются от двигателя до момента завершения всех операций. А некоторые винты умудряются полностью скинуть кэш записи (серверные 10 и 15к) в спец. область, что-бы потом закончить при появлении питания.

А вот на ssd нужны ионисторы и иже с ними.

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

Вау, оказывается я отстал от прогресса ... Тем не менее раньше такое решение было популярным ...

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

Как и питание. И эти два события не коррелируемы без UPS.

Упоролся? Блок либо пишется, либо нет. Если он не успел записаться, он не считается записанным. То же самое с диском — туда либо пишется, либо нет.

Это нужно всем, когда некое одно действие предполагает более одной записи, да хоть в один файл. Но гимор на ровном месте. И ваша атомарность совсем не по делу, вы собираетесь всегда гигабайты перезаписывать?

Я очень хочу увидеть сценарий атомарной записи файла в гипотетической ФС. Чтобы не было «полфайла недописано».

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

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

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

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

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

Ты знаешь, разница между 300 iops и 300k iops чувствуется даже на ляптопе.

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

$ cd ~/dev/linux
$ git checkout <tag1>
$ git checkout <tag2>
$ git checkout <tag3>

Вот сделай эти операции на hdd, потом на ssd и сравни скорость :)

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

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

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

у меня lxr поднят на сервере для крупнокалиберного кода типа кернела или gcc. он шустрее и удобнее. а по мелким проектам у меня и IDEшечка неплохо шарится.

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

у меня lxr поднят на сервере для крупнокалиберного кода типа кернела или gcc. он шустрее и удобнее. а по мелким проектам у меня и IDEшечка неплохо шарится.

Гм... Я тоже думал такое сделать. Но потом вспомнил, что у меня есть подружка, и трахаться с ней как-то веселее, чем с сервером.

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

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

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

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

Это потому что у тебя члена нет.

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

Знаешь, это как почтовый сервер. Он тоже вроде поднимается, его тоже можно настроить... но есть fastmail. Тут примерно то же самое.

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

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

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

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

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

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

Блок либо пишется, либо нет.
Я очень хочу увидеть сценарий атомарной записи файла в гипотетической ФС.

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

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

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.