F2FS это полезная инфа, не знал, спасибо.
На домашнем серваке второй год стоит 60гб ссд, на нем ext4 с выносом на hdd - /tmp /swap /home. В следующий раз буду знать.
Надо понимать что загрузчик не понимает эту фс и его надо выносить в отдельный раздел с ext ФС
Вот если F2FS будет поддерживаться из коробки сразу, тогда будет иметь смысл, чтобы можно при переустановке системы просто выбрать F2FS и установить ось как обычно.
А так, отвались что, и даже никак не запустить ноут с винта, который отформатирован в F2FS.
Это как в лохматые времена, купил CD привод, которые ещё с собственным контроллером поставлялись, в виде ISO карты, а драйвера на компашке.
Доступ к винту всегда можно получить на любом компьютере загрузившись с liveusb с той же кубунтой и введя одну команду для включения поддержки f2fs, modprobe f2fs а дальше делай что хочешь как и с любой другой ФС.
Спасибо. Я вообще к самсунгам не равнодушен. Долго думал Evo или Pro брать (он тысячи на 3 дороже при том же объеме) но решил, что для домашнего использования мне вполне хватит Evo. По скорости они близки, а по надежности, думаю, что он скорее морально устареет чем исчерпает свой ресурс. По использованию все супер. Ноут, кстати, тоже самсунг на i5, как многие говорят, прямо ожил после замены.
По бенчмаркам Evo как раз быстрее и контроллер у него более продвинутый, если я правильно помню.
А так-то да, за ресурс можно не волноваться, тем более 250 еще дольше будет убиваться, чем 120ка.
Ноуты у гнусмаса были самые надежные, но ноутбучное подразделение они вроде закрыли и пойдет на продажу =( А так сам на 310E5C пока что, правда не особо ждал, сразу поставил 16Gb оперативки и SSD на sandforce, который в последствии заменил на Samsung Evo. Что теперь в дальнейшем покупать даже не знаю, наверное буду выбирать по цвету и DPI монитора :)
Поскольку у меня опыта использования данной ФС только с момента написания поста, т.е. всего неделя, то делать какие либо выводы о надежности рановато. Пока никаких сбоев или проблем не заметил. Касаемо скорости работы, то тоже сравнивать не с чем, т.к. в личном пользовании это первый ССД и на других ФС не использовал.
Из того, что нагуглил сделал вывод, что по производительности по крайней мере не хуже других ФС а где то и быстрей, но при этом с учетом заточенности специально под флеш, вероятно что ресурсы ССД с этой фс будут использоваться более оптимально, что должно благоприятно сказаться в том числе и на сроке службы.
В целом же, все работает, работает шустро. Разница после HDD видна сразу "на глаз" без замеров.
За ссылки спасибо, но читал их ранее. :)
После HDD я даже забросил разные там оптимизации по загрузке, скорости запуска приложений и прочего.
Тем не менее спасибо за статью. :)
Power_On_Hours == 648
Т.е. 27 дней. Как-то не густо для хорошего теста.
Но при этом было записано 1025 Gb данных. Как-то многовато имхо за 27 дней. Если конечно торренты не гонять на этом SSD.
И не вижу атрибута "Remaining Life". В первую очередь было бы интересно на него посмотреть.
Данные с ID 235 - это число Unsafe Shutdown Count и равно 44. Тоже как-то многовато для 27 дней использования.
С другой стороны, стоит ли из-за этого переживать?
Посчитаем: чуть больше 1-го террабайта записанных данных набралось где-то за 4-ре месяца использования. Следовательно за год получится около 3-х террабайт. 840 EVO выдержал запись в 900Tb следовательно, при таком режиме использования он выйдет из строя через 900 / 3 = 300 лет!. Через 300 лет!!! Даже если эту цифру в 10 раз уменьшить, то все равно получается очень приличное время. Так что беспокоится за него думаю не стоит.
Правильно, диски, чтобы ими пользоваться. Бэкапы всё равно надо делать регулярно с любого носителя. А если их делать, то какая разница, умрёт ли диск через 10 лет или 110 ;)
Интерсено как быть в случае если надо какие-то манипуляции с ФС произвести. Ну типа файл удаленный восстановить или еще чего? Если вдруг ошибки файловой системы - лечатся ли fsck или надо шаманить? Конечно хотелось бы чтоб такого вообще не было, но как правило в самый неудачный момент вылазит и тут начинаются танцы с бубном.
Практики восстановления удаленных файлов с f2fs пока не было, но думаю что с флеша даже проще теоретически должно быть восстановить. Для проверок и исправления ошибок есть fsck.f2fs
Если вдруг по какой либо причине, система грузиться перестанет, то доступ к данным можно получить загрузившись с liveusb с кубунтой.
Дык на флеше вроде реально данные затираются только при необходимости, а до этого момента просто помечаются как удаленные. Много шума еще было, что на проданных б.у. смартфонах легко восстанавливается личная информация бывших владельцев которая была удалена стандартными средствами без перезаписи.
Главное, чтобы эта проверка ошибок не ломала ФС, как btrfsная.
Про это ничего сказать не могу. Пока проблем не было.
Данные то остаются, но насколько я понимаю - в виде каши из блоков разных файлов ибо дефрагментация не делается, потому как на кристаллах она без надобности. И выделить из них что-то путное весьма проблематично.
Немного погуглил на эту тему и да, вероятно вы правы.
Понравилась цитата одного из комментариев к статье на хабре:
«Почему вы называете это путаницей? Здесь всё прозрачно и понятно. Если вы хотите восстановить удалённые данные, то сделать этого вы не можете. Если вы хотите их уничтожить, то и этого сделать вы не можете. Это такой Закон Мёрфи для хранения данных на SSD».
Так что с надежностью хранения у SSD концептуально все очень не радужно. Стоит сбиться какой-то внутренней таблице, которая тримом например рулит или еще каки-то "фирменным" внутренним процессом и данные навсегда утерянны. Другое дело что пока оно все четко работает, но помоему потенциальный риск достаточно велик.
Trim вот уже полгода каждый день срабатывает и ничего
*** Fri, 27 Mar 2015 07:40:29 +0300 ***
/: 4067536896 bytes were trimmed
/home: 7790718976 bytes were trimmed
*** Sat, 28 Mar 2015 08:10:33 +0300 ***
/: 4082016256 bytes were trimmed
/home: 7786733568 bytes were trimmed
*** Sun, 29 Mar 2015 09:15:14 +0300 ***
/: 4076851200 bytes were trimmed
/home: 7788699648 bytes were trimmed
*** Mon, 30 Mar 2015 04:43:11 +0300 ***
/: 4066721792 bytes were trimmed
/home: 7791136768 bytes were trimmed
*** Tue, 31 Mar 2015 08:50:18 +0300 ***
/: 4066332672 bytes were trimmed
/home: 7788511232 bytes were trimmed
Я не думаю, что его реализацией занимались те же чайники, которые писали инсталлятор для кубунты :)
Как минимум, это отложенное действие. Т.е. прошивка девайса не кидается сразу помечать блоки, на которые показала пальцем ОСь. Накопится определенное количество / пройдет определенное время - вперед. Практически не сомневаюсь, что приоритет подобных операций заведомо ниже, чем у главных задач. Даже если контроллер занимался пометкой и тут прилетело несколько пачек данных на запись, и, тут же, резко пришел запрос на чтение гигабайтного файла плюс пары сотен мелких - полагаю, discard подвинется. Даже, скорее всего, данные по отмеченным к обнулению блокам запишутся в nand, чтобы не занимать кэш.
А Вы уверены, что Ваш метод действительно активирует TRIM? У меня, например, TRIM не работает с f2fs. sudo mount | grep discard /dev/sdb6 on / type f2fs (rw,relatime,discard) /dev/sdb8 on /home type f2fs (rw,relatime,discard)
и sudo fstrim / fstrim: /: discard operation not supported. sudo fstrim /home fstrim: /home: discard operation not supported.
но sudo fstrim -v /boot /boot: 0 B (0 bytes) trimmed
Now f2fs has not yet supported batch mode discard through ioctl as the way
fstrim used.
Still you could use real-time mode discard by adding a '-o discard' option when
mount, meanwhile /sys/fs/f2fs/≤devname>/max_small_discards could be used for
controlling the real-time mode.
Сейчас f2fs пока еще не поддерживает пакетный режим очистки через ioctl, который использует fstrim.
Тем не менее, вы можете использовать реалтайм (режим реального времени) режим добавляя опцию -o discard при монтировании, в то время как /sys/fs/f2fs/≤devname>/max_small_discards может быть использован для контроля реалтайм режима.
Не могли бы Вы пояснить, как именно контролировать реалтайм режим. /sys/fs/f2fs/≤devname>/max_small_discards содержат 0, что означает, что дискард по умолчанию выключен.
Работоспособность TRIM можно проверить методом, описанным здесь. Нужно записать в файл случайные данные, удалить файл и после двухминутного ожидания сравнить блок из удалённого файла с блоком записанных данных. У меня результат одинаков, что означает, что TRIM не удаляет блоки.
http://lxr.free-electrons.com/source/Documentation/filesystems/f2fs.txt max_small_discards This parameter controls the number of discard
commands that consist small blocks less than 2MB.
The candidates to be discarded are cached until
checkpoint is triggered, and issued during the
checkpoint. By default, it is disabled with 0. Этот параметр контролирует число discard-команд, которые содержат маленькие блоки, меньше 2МБ. Кандидаты на очистку кэшируются до срабатывания триггера, накапливаясь. По умолчанию отключено со значением 0.
Полагаю, что изменение данного показателя приведет к более агрессивному использованию очистки и будут вызовы даже при малых размерах блоков. На мой взгляд, в этом нет необходимости.
Сам пока не использую f2fs, просто перевел пару кусков документации.
Что до метода - когда я проверял им работу discard на ext4, результат проявился только через 20-30 минут. Думаю, что на f2fs метод реализован еще более грамотно, поэтому чтобы удостовериться, попробуйте при проверке еще посоздавать/поудалять множество дополнительных файлов среднего-большого размера - это должно ускорить результат вашей проверки.
Спасибо за пояснения. Похоже, что TRIM действительно не работает. После удаления файла считывал значение блока сразу, через 2, 10, 30, 60 минут и через 5 часов. При этом создавал и удалял файлы размером 500МБ и 5ГБ. Результат - блок занят тем же значением, что и удалённый файл. Не подскажете другие варианты проверки.
Вы бы начали с того, что у вас за девайс/модель и версия ядра.
У товарища dm, ведь, самсунг. И ему грех некорректно работать на файловой системе разработанной и реализованной самсунгом же. Возможно, у вас другой девайс и там какие-то "недопонимания" в протоколе, при общении девайса с ОС. Могу посоветовать самостоятельно погуглить в сети удачные/неудачные примеры использования discard на f2fs на таком же девайсе.
Ну, а проверить еще можно на ext4. Уменьшите размер раздела (одного из разделов) под livecd/flash, если не осталось неразмеченного пространства, сделайте раздел ext4 на 1-2 гига и проверьте на нем.
Похоже что метод записи случайных данных не подходит для пустых накопителей. TRIM в этом случае помечает блок на удаление, а удаляет как-нибудь потом. В случае когда SSD физически забит, TRIM сразу забивает помеченный блок нулями. Так с другим SSD INTEL SSDSA1M160G2LE после удаления файла появляются нули. А с новым 480 гиговым пустым Кингстоном нулей нет на разделах ни с f2fs ни с ext4.
Здравствуйте, дорогой DM!
Успешно использовал Ваш мануал для переноса установки свежей Xubuntu 15.10 на mSATA SSD с GPT и поддержкой UEFI.
Однако для актуализации материала, предлагаю сообщить читателю, что в случае если у него а) только 1 ОС , б) UEFI BIOS, то следует заблаговременно создать в начале диска раздел под efi, формата fat32, размером 50 мб и во время chroot и установки grub не забыть его примонтировать.
Также, вместо ручного редактирования grub.cfg, можно заюзать grub-mkconfig -o /boot/grub/grub.cfg.new и после ручной проверки его использовать.
Довелось тут проверить f2fs на жизнеспособность.
После попытки доступа к /root разделу с загрузочной флешки с kali linux без установленного модуля f2fs система перестала загружаться. Стандартная проверка диска при загрузке если и включалась, то длилась бесконечно и ничего не происходило. Получилось зайти в консоль через recovery. При некоторых коммандах на пример apt update, все висло и на экране сыпались различные ошибки. После продолжительных танцев с бубном думал уже всё, придется переустанавливать.
Потом загрузился с загрузочной флешки с kali linux, подключил модуль f2fs (modprobe f2fs) установил f2fstool и запустил проверку /root раздела с исправлением ошибок (fsck.f2fs -f). После этого система успешно запустилась.
Считаю, что тест на ремонтопригодность успешно пройден.
Люто! может, этот коммент стоит продублировать в заглавном сообщении в дополнении? все-таки там больше шансом, что прочтут, нежели в дебрях комментов =)
Не очень понял про греп, но атрибут 194 это однозначно температура.
В моем гудраме накосячили что то со смартом и у них вместо тега здоровья возле атрибута 173 пишется про температуру. Смотреть надо по номеру атрибута. Кстати, некоторые атрибуты у разных производителей сильно отличаются - поэтому надо смотреть даташиты.
Некоторые в один атрибут засовывают несколько параметров - старших два байта одно, младших два байта другое. И мы видим сырые цифры огромные в смарте.
При обновлении с 16.04 до 17.04 на стадии 16.10 машина с f2fs перестала грузится.
При внимательном изучении данной темы получил готовый ответ за что еще раз огромное спасибо уважаемому dm
Ребенок познает мир, очень просил переносную кали на флешке.
Просто образ диска запилить на флешку - не интересно по причине сложностей в конфигурации. Система ридонли и, например, доставить драйвер нвидия сопряжен с большим сексом.
Проинсталлировали на ext4 - загружается очень долго (минут пять) и отзывчивость системы просто никакая.
Вспомнил про f2fs. Для инсталляции флешка разбита на два раздела (boot-ext2 и /-ext4)
После инсталляции подключил драйвера как выше по мануалу, проверил как грузятся.
Затем перенес корень на комп, жпартом переформатировал корневой раздел в f2fs и вернул сохраненное назад. Все это достаточно долго происходит, но того стоит :)
В итоге: загрузка до запроса логина 60 секунд, полностью рабочее состояние после ввода логин/пароль 13 секунд.
Система очень отзывчивая, практически фризов нет, можно комфортно работать.
Еще раз спасибо уважаемому dm за топик.
Сегодня в при переходе с 17.10 на 18.04 столкнулся с неприятными граблями.
В процессе обновления стали сыпаться разнообразные ошибки dpkg, очень много вопросов про конфигурационные файлы (оставить старый или тот что идет в дистре) - короче, поведение весьма подозрительное. Дотянул обновление до конца - сообщило что обновлено с ошибками.
Система после загрузки не поднялась куча ошибок в логах, практически по всем важным демонам.
Короче говоря - корневой раздел (f2fs) был с ошибками файловой системы.
fsck вроде чинил, но если его еще раз запустить опять сообщал про ошибку.
Пришлось форматировать раздел.
Сейчас ставлю 18.04 с нуля на ext4.
Все это с диском, о котором я выше писал в этой ветке.
Диск по смарту в отличном состоянии, как то не верится что он физически помер за два года.
Стоит ли в случае успешной установки опять переходить на f2fs пока для себя не решил...
До перезагрузки sudo apt dist-upgrade -f для дообновления запускал?
нет Не думаю, что виновата f2fs
Посмотрим как поставится на ext4
Пока выводы делать рано.
На ext4 система стала без проблем.
fsck чистый для всех разделов.
"На глаз" производительность не поменялась, хотя точно утверждать не берусь - я за этим ноутом не работаю...
А теперь вопрос - стоит заморочиться и опять перейти на f2fs или посидеть на ext4 с включенным discard?
Есть ли какие-то сравнительные данные про здоровье SSD с использованием ext4 и f2fs?
Еще настораживает отсутствие возможности инсталляции кубунты на f2fs по дфолту без бубна. Почему дистростроители игнорируют эту файловую систему?
Тяжело решить без такой информации ...
Есть тесты производительности. (там странички полистать с графиками)
По здоровью - сегодня не актуально, как мне кажется - современные SSD накопители имеют хорошие встроенные контроллеры, для слежения за здоровьем. Имхо.
Да и самсунг своё изобретение F2FS как-то не особо жалует, на планшеты с андроидом и смартфоны дефолтом ставят ext4, вроде как.
На хакер.ру есть ещё такая статейка.
Да вроде бы очевидно все...
Чем сильнее файловая система использует механизм отложенной записи, тем выше отзывчивость работы на медленных устройствах хранения.
Это справедливо для перехода с ext4 на f2fs и так же справедливо для перехода с ext3 на ext4.
Чем сильнее файловая система использует механизм отложенной записи, тем выше вероятность потери данных при резком отключении питания (на ноутах и компах с UPS она снижается).
Чем быстрее устройство хранения, тем менее заметна разница при использовании отложенной записи. Там где на юсб-флешках она будет в разы и даже загрузка системы будет в разы замедляться за счет ожиданий записи, на SSD на глаз найти отличия можно будет только в очень специфических задачах.
Для перевода корневого раздела (если /home отделен) смысла я не вижу. Работа с кучей мелких файлов обычно происходит в хомяке, для СУБД можно отделить и перевести /var.
На ноуте аккум не в очень хорошем состоянии. Думаю таки было отключение, которое и привело к косяку. С этой точки зрения наверное ext4 все таки понадежнее будет.
Кстати вот тут есть документация по настройке https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
Добавьте пожалуйста в статью а то я как-то по не знанию долго искал как тюнить F2FS
Комментарии (72)
F2FS это полезная инфа, не знал, спасибо.
На домашнем серваке второй год стоит 60гб ссд, на нем ext4 с выносом на hdd - /tmp /swap /home. В следующий раз буду знать.
Надо понимать что загрузчик не понимает эту фс и его надо выносить в отдельный раздел с ext ФС
Вот если F2FS будет поддерживаться из коробки сразу, тогда будет иметь смысл, чтобы можно при переустановке системы просто выбрать F2FS и установить ось как обычно.
А так, отвались что, и даже никак не запустить ноут с винта, который отформатирован в F2FS.
Это как в лохматые времена, купил CD привод, которые ещё с собственным контроллером поставлялись, в виде ISO карты, а драйвера на компашке.
Доступ к винту всегда можно получить на любом компьютере загрузившись с liveusb с той же кубунтой и введя одну команду для включения поддержки f2fs, modprobe f2fs а дальше делай что хочешь как и с любой другой ФС.
Хороший выбор модели, поздравляю =)
Посмотрел тут бенчмарки - пожалуй да, F2FS для десктопа вырывается вперед.
Спасибо. Я вообще к самсунгам не равнодушен. Долго думал Evo или Pro брать (он тысячи на 3 дороже при том же объеме) но решил, что для домашнего использования мне вполне хватит Evo. По скорости они близки, а по надежности, думаю, что он скорее морально устареет чем исчерпает свой ресурс. По использованию все супер. Ноут, кстати, тоже самсунг на i5, как многие говорят, прямо ожил после замены.
С F2FS тоже пока никаких проблем не заметил.
По бенчмаркам Evo как раз быстрее и контроллер у него более продвинутый, если я правильно помню.
А так-то да, за ресурс можно не волноваться, тем более 250 еще дольше будет убиваться, чем 120ка.
Ноуты у гнусмаса были самые надежные, но ноутбучное подразделение они вроде закрыли и пойдет на продажу =( А так сам на 310E5C пока что, правда не особо ждал, сразу поставил 16Gb оперативки и SSD на sandforce, который в последствии заменил на Samsung Evo. Что теперь в дальнейшем покупать даже не знаю, наверное буду выбирать по цвету и DPI монитора :)
Только собираюсь сделать переход на SSD. И хоть использую генту, но буду использовать Вашу информацию для настройки. Спасибо.
А как в целом то впечатления от F2FS?
Я, помнится, одно время тестировал btrfs(года 2 назад). Была достаточно тормозной в сравнении с той же ext4.
Поскольку у меня опыта использования данной ФС только с момента написания поста, т.е. всего неделя, то делать какие либо выводы о надежности рановато. Пока никаких сбоев или проблем не заметил. Касаемо скорости работы, то тоже сравнивать не с чем, т.к. в личном пользовании это первый ССД и на других ФС не использовал.
Из того, что нагуглил сделал вывод, что по производительности по крайней мере не хуже других ФС а где то и быстрей, но при этом с учетом заточенности специально под флеш, вероятно что ресурсы ССД с этой фс будут использоваться более оптимально, что должно благоприятно сказаться в том числе и на сроке службы.
В целом же, все работает, работает шустро. Разница после HDD видна сразу "на глаз" без замеров.
Тут немного о преимуществах F2FS
Оценка производительности файловой системы F2FS,
За ссылки спасибо, но читал их ранее. :)
После HDD я даже забросил разные там оптимизации по загрузке, скорости запуска приложений и прочего.
Тем не менее спасибо за статью. :)
Лучше бы Samsung Pro взяли. В EVO обнаружен серьёзный баг:
http://forums.overclockers.ru/viewtopic.php?f=24&t=519436
Samsung выпустила обновление прошивки SSD 840 Evo для решения проблемы «медленных» данных
При этом, на моем ссд уже стояла эта прошивка "из коробки" так что даже прошивать ничего не пришлось.
Как впечатления после нескольких месяцев использования ?
Все работает как и должно. Сбоев, глюков и торможений замечено не было. Сказать особо нечего, так как все работает и работает.
А SMART посмотреть можно ?
Можно
Power_On_Hours == 648
Т.е. 27 дней. Как-то не густо для хорошего теста.
Но при этом было записано 1025 Gb данных. Как-то многовато имхо за 27 дней. Если конечно торренты не гонять на этом SSD.
И не вижу атрибута "Remaining Life". В первую очередь было бы интересно на него посмотреть.
Данные с ID 235 - это число Unsafe Shutdown Count и равно 44. Тоже как-то многовато для 27 дней использования.
Если где-то ошибся, поправьте)
С другой стороны, стоит ли из-за этого переживать?
Посчитаем: чуть больше 1-го террабайта записанных данных набралось где-то за 4-ре месяца использования. Следовательно за год получится около 3-х террабайт. 840 EVO выдержал запись в 900Tb следовательно, при таком режиме использования он выйдет из строя через 900 / 3 = 300 лет!. Через 300 лет!!! Даже если эту цифру в 10 раз уменьшить, то все равно получается очень приличное время. Так что беспокоится за него думаю не стоит.
Правильно, диски, чтобы ими пользоваться. Бэкапы всё равно надо делать регулярно с любого носителя. А если их делать, то какая разница, умрёт ли диск через 10 лет или 110 ;)
Интерсено как быть в случае если надо какие-то манипуляции с ФС произвести. Ну типа файл удаленный восстановить или еще чего? Если вдруг ошибки файловой системы - лечатся ли fsck или надо шаманить? Конечно хотелось бы чтоб такого вообще не было, но как правило в самый неудачный момент вылазит и тут начинаются танцы с бубном.
Практики восстановления удаленных файлов с f2fs пока не было, но думаю что с флеша даже проще теоретически должно быть восстановить. Для проверок и исправления ошибок есть fsck.f2fs
Если вдруг по какой либо причине, система грузиться перестанет, то доступ к данным можно получить загрузившись с liveusb с кубунтой.
Наоборот, с флеша вроде сложнее восстанавливать.
Главное, чтобы эта проверка ошибок не ломала ФС, как btrfsная.
Дык на флеше вроде реально данные затираются только при необходимости, а до этого момента просто помечаются как удаленные. Много шума еще было, что на проданных б.у. смартфонах легко восстанавливается личная информация бывших владельцев которая была удалена стандартными средствами без перезаписи.
Про это ничего сказать не могу. Пока проблем не было.
Данные то остаются, но насколько я понимаю - в виде каши из блоков разных файлов ибо дефрагментация не делается, потому как на кристаллах она без надобности. И выделить из них что-то путное весьма проблематично.
Немного погуглил на эту тему и да, вероятно вы правы.
Понравилась цитата одного из комментариев к статье на хабре:
Так что с надежностью хранения у SSD концептуально все очень не радужно. Стоит сбиться какой-то внутренней таблице, которая тримом например рулит или еще каки-то "фирменным" внутренним процессом и данные навсегда утерянны. Другое дело что пока оно все четко работает, но помоему потенциальный риск достаточно велик.
Первый же trim всё похерит.
Trim вот уже полгода каждый день срабатывает и ничего
*** Fri, 27 Mar 2015 07:40:29 +0300 ***
/: 4067536896 bytes were trimmed
/home: 7790718976 bytes were trimmed
*** Sat, 28 Mar 2015 08:10:33 +0300 ***
/: 4082016256 bytes were trimmed
/home: 7786733568 bytes were trimmed
*** Sun, 29 Mar 2015 09:15:14 +0300 ***
/: 4076851200 bytes were trimmed
/home: 7788699648 bytes were trimmed
*** Mon, 30 Mar 2015 04:43:11 +0300 ***
/: 4066721792 bytes were trimmed
/home: 7791136768 bytes were trimmed
*** Tue, 31 Mar 2015 08:50:18 +0300 ***
/: 4066332672 bytes were trimmed
/home: 7788511232 bytes were trimmed
А зачем так-то? discard не работает?
Дискард срабатывает на каждом удалении, кажется. Типа слишком часто, типа замедляет работу. Сам им пользуюсь :)
Я не думаю, что его реализацией занимались те же чайники, которые писали инсталлятор для кубунты :)
Как минимум, это отложенное действие. Т.е. прошивка девайса не кидается сразу помечать блоки, на которые показала пальцем ОСь. Накопится определенное количество / пройдет определенное время - вперед. Практически не сомневаюсь, что приоритет подобных операций заведомо ниже, чем у главных задач. Даже если контроллер занимался пометкой и тут прилетело несколько пачек данных на запись, и, тут же, резко пришел запрос на чтение гигабайтного файла плюс пары сотен мелких - полагаю, discard подвинется. Даже, скорее всего, данные по отмеченным к обнулению блокам запишутся в nand, чтобы не занимать кэш.
А Вы уверены, что Ваш метод действительно активирует TRIM? У меня, например, TRIM не работает с f2fs.
sudo mount | grep discard/dev/sdb6 on / type f2fs (rw,relatime,discard)
/dev/sdb8 on /home type f2fs (rw,relatime,discard)
и
sudo fstrim /fstrim: /: discard operation not supported.
sudo fstrim /homefstrim: /home: discard operation not supported.
но
sudo fstrim -v /boot/boot: 0 B (0 bytes) trimmed
Сейчас f2fs пока еще не поддерживает пакетный режим очистки через ioctl, который использует fstrim.
Тем не менее, вы можете использовать реалтайм (режим реального времени) режим добавляя опцию -o discard при монтировании, в то время как /sys/fs/f2fs/≤devname>/max_small_discards может быть использован для контроля реалтайм режима.
Не могли бы Вы пояснить, как именно контролировать реалтайм режим. /sys/fs/f2fs/≤devname>/max_small_discards содержат 0, что означает, что дискард по умолчанию выключен.
Работоспособность TRIM можно проверить методом, описанным здесь. Нужно записать в файл случайные данные, удалить файл и после двухминутного ожидания сравнить блок из удалённого файла с блоком записанных данных. У меня результат одинаков, что означает, что TRIM не удаляет блоки.
http://lxr.free-electrons.com/source/Documentation/filesystems/f2fs.txt
Полагаю, что изменение данного показателя приведет к более агрессивному использованию очистки и будут вызовы даже при малых размерах блоков. На мой взгляд, в этом нет необходимости.
Сам пока не использую f2fs, просто перевел пару кусков документации.
Что до метода - когда я проверял им работу discard на ext4, результат проявился только через 20-30 минут. Думаю, что на f2fs метод реализован еще более грамотно, поэтому чтобы удостовериться, попробуйте при проверке еще посоздавать/поудалять множество дополнительных файлов среднего-большого размера - это должно ускорить результат вашей проверки.
Спасибо за пояснения. Похоже, что TRIM действительно не работает. После удаления файла считывал значение блока сразу, через 2, 10, 30, 60 минут и через 5 часов. При этом создавал и удалял файлы размером 500МБ и 5ГБ. Результат - блок занят тем же значением, что и удалённый файл. Не подскажете другие варианты проверки.
Вы бы начали с того, что у вас за девайс/модель и версия ядра.
У товарища dm, ведь, самсунг. И ему грех некорректно работать на файловой системе разработанной и реализованной самсунгом же. Возможно, у вас другой девайс и там какие-то "недопонимания" в протоколе, при общении девайса с ОС. Могу посоветовать самостоятельно погуглить в сети удачные/неудачные примеры использования discard на f2fs на таком же девайсе.
Ну, а проверить еще можно на ext4. Уменьшите размер раздела (одного из разделов) под livecd/flash, если не осталось неразмеченного пространства, сделайте раздел ext4 на 1-2 гига и проверьте на нем.
SSD KINGSTON SH103S3480G, ядро 3.16.0-34-generic.
Похоже что метод записи случайных данных не подходит для пустых накопителей. TRIM в этом случае помечает блок на удаление, а удаляет как-нибудь потом. В случае когда SSD физически забит, TRIM сразу забивает помеченный блок нулями. Так с другим SSD INTEL SSDSA1M160G2LE после удаления файла появляются нули. А с новым 480 гиговым пустым Кингстоном нулей нет на разделах ни с f2fs ни с ext4.
В SSD-накопителях Samsung серии 8xx выявлена проблема, которая может привести к потере данных при выполнении асинхронных операций TRIM.
Спасибо, приму к сведению.
Здравствуйте, дорогой DM!
Успешно использовал Ваш мануал для переноса установки свежей Xubuntu 15.10 на mSATA SSD с GPT и поддержкой UEFI.
Однако для актуализации материала, предлагаю сообщить читателю, что в случае если у него а) только 1 ОС , б) UEFI BIOS, то следует заблаговременно создать в начале диска раздел под efi, формата fat32, размером 50 мб и во время chroot и установки grub не забыть его примонтировать.
Также, вместо ручного редактирования grub.cfg, можно заюзать grub-mkconfig -o /boot/grub/grub.cfg.new и после ручной проверки его использовать.
Копируем /root из HDD на SSD
sudo cp -ar /media/kubuntu/root /media/f2fs_root
Команда неверно копирует.
Надо так: sudo cp -ar /media/kubuntu/root/* /media/f2fs_root
иначе получается лишний каталог /root/root... /root/boot...
Довелось тут проверить f2fs на жизнеспособность.
После попытки доступа к /root разделу с загрузочной флешки с kali linux без установленного модуля f2fs система перестала загружаться. Стандартная проверка диска при загрузке если и включалась, то длилась бесконечно и ничего не происходило. Получилось зайти в консоль через recovery. При некоторых коммандах на пример apt update, все висло и на экране сыпались различные ошибки. После продолжительных танцев с бубном думал уже всё, придется переустанавливать.
Потом загрузился с загрузочной флешки с kali linux, подключил модуль f2fs (modprobe f2fs) установил f2fstool и запустил проверку /root раздела с исправлением ошибок (fsck.f2fs -f). После этого система успешно запустилась.
Считаю, что тест на ремонтопригодность успешно пройден.
Люто! может, этот коммент стоит продублировать в заглавном сообщении в дополнении? все-таки там больше шансом, что прочтут, нежели в дебрях комментов =)
Добавил ссылку на коммент в конец топика.
У меня сейчас так:
------------------------------SSD Status: /dev/sda
------------------------------
On time: 2,405 hr
------------------------------
Data written:
MB: 3,268,255.021
GB: 3,191.655
TB: 3.116
------------------------------
Mean write rate:
MB/hr: 1,358.941
------------------------------
Drive health: 98 %
------------------------------
Не очень понял про греп, но атрибут 194 это однозначно температура.
В моем гудраме накосячили что то со смартом и у них вместо тега здоровья возле атрибута 173 пишется про температуру. Смотреть надо по номеру атрибута. Кстати, некоторые атрибуты у разных производителей сильно отличаются - поэтому надо смотреть даташиты.
Некоторые в один атрибут засовывают несколько параметров - старших два байта одно, младших два байта другое. И мы видим сырые цифры огромные в смарте.
Тогда грепу стоит отдавать только числа.
Эх нет у меня здоровья =)
Низя, ибо такое число может попасться среди данных.
Мона.
grep '^194 '(паттерн: начало строки, 194, пробел)
Обновился до 16.10 и система отказалась загружаться с новым ядром 4.8. Загрузка останавливалась на строке:
Решается добавлением модуля crc32 в /etc/initramfs-tools/modules и обновлением initramfs
sudo -iecho crc32 >> /etc/initramfs-tools/modules
update-initramfs -u
После чего система загружается и работает нормально.
А с нуля никто не ставил *buntu на F2FS? Подводные камни есть?
p.s. хотя торопиться, видимо, не стоит... https://xakep.ru/2016/10/10/f2fs-mythology/
Ставил уже где то на 3 новых компа с SSD дисками. Проблем никаких. Технология та же что и в статье за исключением переноса /home раздела.
При обновлении с 16.04 до 17.04 на стадии 16.10 машина с f2fs перестала грузится.
При внимательном изучении данной темы получил готовый ответ за что еще раз огромное спасибо уважаемому dm
Рад, что эта информация оказалась полезной и помогла решить проблему.
Ребенок познает мир, очень просил переносную кали на флешке.
Просто образ диска запилить на флешку - не интересно по причине сложностей в конфигурации. Система ридонли и, например, доставить драйвер нвидия сопряжен с большим сексом.
Проинсталлировали на ext4 - загружается очень долго (минут пять) и отзывчивость системы просто никакая.
Вспомнил про f2fs. Для инсталляции флешка разбита на два раздела (boot-ext2 и /-ext4)
После инсталляции подключил драйвера как выше по мануалу, проверил как грузятся.
Затем перенес корень на комп, жпартом переформатировал корневой раздел в f2fs и вернул сохраненное назад. Все это достаточно долго происходит, но того стоит :)
В итоге: загрузка до запроса логина 60 секунд, полностью рабочее состояние после ввода логин/пароль 13 секунд.
Система очень отзывчивая, практически фризов нет, можно комфортно работать.
Еще раз спасибо уважаемому dm за топик.
Сегодня в при переходе с 17.10 на 18.04 столкнулся с неприятными граблями.
В процессе обновления стали сыпаться разнообразные ошибки dpkg, очень много вопросов про конфигурационные файлы (оставить старый или тот что идет в дистре) - короче, поведение весьма подозрительное. Дотянул обновление до конца - сообщило что обновлено с ошибками.
Система после загрузки не поднялась куча ошибок в логах, практически по всем важным демонам.
Короче говоря - корневой раздел (f2fs) был с ошибками файловой системы.
fsck вроде чинил, но если его еще раз запустить опять сообщал про ошибку.
Пришлось форматировать раздел.
Сейчас ставлю 18.04 с нуля на ext4.
Все это с диском, о котором я выше писал в этой ветке.
Диск по смарту в отличном состоянии, как то не верится что он физически помер за два года.
Стоит ли в случае успешной установки опять переходить на f2fs пока для себя не решил...
Не думаю, что виновата f2fs. Успешно обновил уже 2 компьютера с f2fs на 18.04. Один с 16.04 другой с 17.10. Проблем не возникло.
До перезагрузки sudo apt dist-upgrade -f для дообновления запускал?
нет
Посмотрим как поставится на ext4
Пока выводы делать рано.
На ext4 система стала без проблем.
fsck чистый для всех разделов.
"На глаз" производительность не поменялась, хотя точно утверждать не берусь - я за этим ноутом не работаю...
А теперь вопрос - стоит заморочиться и опять перейти на f2fs или посидеть на ext4 с включенным discard?
Тут каждый сам решает, нужно ему это или нет.
Есть ли какие-то сравнительные данные про здоровье SSD с использованием ext4 и f2fs?
Еще настораживает отсутствие возможности инсталляции кубунты на f2fs по дфолту без бубна. Почему дистростроители игнорируют эту файловую систему?
Тяжело решить без такой информации ...
Есть тесты производительности. (там странички полистать с графиками)
По здоровью - сегодня не актуально, как мне кажется - современные SSD накопители имеют хорошие встроенные контроллеры, для слежения за здоровьем. Имхо.
Да и самсунг своё изобретение F2FS как-то не особо жалует, на планшеты с андроидом и смартфоны дефолтом ставят ext4, вроде как.
На хакер.ру есть ещё такая статейка.
Да вроде бы очевидно все...
Чем сильнее файловая система использует механизм отложенной записи, тем выше отзывчивость работы на медленных устройствах хранения.
Это справедливо для перехода с ext4 на f2fs и так же справедливо для перехода с ext3 на ext4.
Чем сильнее файловая система использует механизм отложенной записи, тем выше вероятность потери данных при резком отключении питания (на ноутах и компах с UPS она снижается).
Чем быстрее устройство хранения, тем менее заметна разница при использовании отложенной записи. Там где на юсб-флешках она будет в разы и даже загрузка системы будет в разы замедляться за счет ожиданий записи, на SSD на глаз найти отличия можно будет только в очень специфических задачах.
Для перевода корневого раздела (если /home отделен) смысла я не вижу. Работа с кучей мелких файлов обычно происходит в хомяке, для СУБД можно отделить и перевести /var.
На ноуте аккум не в очень хорошем состоянии. Думаю таки было отключение, которое и привело к косяку. С этой точки зрения наверное ext4 все таки понадежнее будет.
Ценную инфу-то вытащил? Она целая?
Инфа не пострадала. Поломался только корневой раздел. Хомяк (другой раздел, но тоже в f2fs) в порядке.
Грузится с F2FS уже по идее можно начиная с GRUB 2.04 релизнутого 5 Jul 2019
https://www.opennet.ru/opennews/art.shtml?num=51038
Кстати вот тут есть документация по настройке https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
Добавьте пожалуйста в статью а то я как-то по не знанию долго искал как тюнить F2FS
Отправить комментарий