f2fs-tools 1.8.0

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

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

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

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

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

Я-то знаю.

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

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

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

TRIM же в первую очередь для garbage collection?

И без TRIM контроллер должен разбираться в файловой системе, разве не так?

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

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

Ну вот Samsung 850 Pro (MLC):

128/256GB : 150 Terabytes Written(TBW)

Получается как раз 1000 перезаписей (при идеальном wear leveling'е).

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

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

При чём тут garbage collection? Что ты пытаешься мне доказать?

Доказать? Зачем? Я просто спросил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ммм, ты всетаки попробуй...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На случай если контроллер сам не справится.

циклы чтения ... убивают

WAT

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

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

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

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

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

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

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

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

а чем ты его так нагружаешь, что чувствуешь разницу?

Например

$ git grep

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

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

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

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

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

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

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

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

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

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

А как лучше: f2fs с discard или без?

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

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

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

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