Должен ли я использовать btrfs (с опциями discard, compress = lzo и space_cache) или Ext4 (с опцией discard) для SSD для моего корневого раздела настольного компьютера Ubuntu 11.10 (Oneiric) amd64 моего офисного компьютера?
/ home будет HDD, поэтому надежность fs влияет на ОС, а не на мои данные.
Ответы:
Согласно тестам phoronix это всегда зависит от многих факторов. В одном случае Btrfsбудет гораздо лучше, чем EXT4при чтении больших файлов на SSD. Аналогичным образом, учитывая производительность транзакций на диске, Ext4может работать лучше, чем позже.
Вы можете просмотреть эти тесты здесь , здесь и здесь (ВНИМАНИЕ: длинные статьи).
Но в целом, Btrfs сейчас не имеет количественного преимущества в производительности по сравнению с файловой системой EXT4 , даже при использовании в режиме SSD.
Таким образом, вы можете выбрать Ext4сейчас.
Для тех, кто споткнулся в этом вопросе в 2016 году ... Используйте ext4. Я пробовал btrfs и разница существенная. За 10-дневный период число операций ввода-вывода в ext4 составило 17 800 секторов. Btrfs? 490 400 секторов. Тот же SSD, идентичная файловая система, разные разделы. В основном, такая же нагрузка.
Ext4 и btrfs работают "тихо", когда на диске нет активности записи. Это хорошо.
Ext4 запишет измененные данные плюс некоторые накладные расходы. Накладные расходы относятся к записанным данным. Запись 4K (1 блок) приводит к перегрузке около 50-80 блоков при следующем коммите. (Журнал ext4 полностью включен)
Измените один блок 4K на btrfs, и вы будете загружать 4000-5000 блоков накладных расходов при следующем коммите. Я полагаю, что фиксация по умолчанию составляет 30 секунд. Я использовал 120.
Теперь все зависит от того, как вы используете SSD. От имени root обычно происходит довольно постоянный поток записи низкого уровня. Файлы журнала, файлы дрейфа ntp, перестройки man db, обновления топологии opensm и т. Д., И т. Д. Каждое событие будет забивать диск btrfs еще 4000-5000 операций записи.
Указанные выше 10-дневные номера относятся к моему SSD с ограничением записи. Большая часть этих 17 800 секторов была результатом небольшого обновления системы. Один экземпляр btrfs не пострадал. Мои авторы, в частности, ntp drift, opensm topology и man db updates (nightly). Больше ничего не попадает на этот диск, кроме активно инициируемых вещей, таких как обновление системы vim /etc/whateverи т. Д.
На самом деле твердотельные накопители сильно пострадают. Я просто не вижу смысла тратить их впустую, потому что СМИ преследуют кроликов и радугу. Если вы хотите заплатить эту цену за COW, сделайте это. Для «производительности» не так уж и много. Это твердотельный накопитель, и вы, возможно, могли бы использовать на нем худшую «файловую систему», известную человеку, и при этом получить некоторый уровень производительности - просто грубой силой. Ext4, безусловно, не самая плохая файловая система, известная человеку.
Нет ежемесячной проверки фс. Попробуйте скрипт ниже. Это 100% взлом, не будет работать для точек монтирования md,
#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
if [ "$vm" != "$vmx" ]
then
tim=`date +%s`
dif=`dc <<< "$vm $vmx - p"`
lbad=`dc <<< "$lba $lbax - p"`
timd=`dc <<< "$tim $timx - p"`
echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
vmx="$vm"
lbax="$lba"
timx="$tim"
find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
touch "$tmpnam"
fi
sleep 1
doneОн сообщит вам, сколько блоков было записано, в соответствии с самим диском и какие именно файлы были обновлены. Нужны корневые привилегии. Посмотреть на себя. Я запускаю SSD в корневой файловой системе и вызываю скрипт stat.sh. Так...sudo ./stat.sh /
В последний раз, когда я проверял это, и я еще нигде не слышал по-другому, ext4 ест твердотельные СМИ. (флэш-накопители, твердотельные накопители и т. д.) Я не рекомендую использовать его на таком устройстве. Вместо этого используйте ext3. В большинстве случаев на SSD вы все равно не заметите разницу.
BTRFS еще не совсем стабильна. Тем не менее, он достаточно стабилен для некритических приложений. Это то, что я использую для создания загрузочных флешек. Если вы используете compress = zlib и ssd в качестве параметров монтирования, сжатие будет компенсировать более низкие скорости записи большинства твердотельных носителей, а ssd изменит алгоритм распределения на тот, который работает значительно лучше на таких устройствах и восполнит любые плохое выравнивание износа оборудованием. Единственная область производительности, которая все еще остается проблемой, - это медленные вызовы синхронизации. Это не проблема для общего пользования, но dpkg вызывает синхронизацию после каждой операции, поэтому установка и обновление программного обеспечения могут быть медленными. BTRFS также предлагает снимки и другие расширенные функции, которые весьма полезны при определенных обстоятельствах.
Если вы решили использовать BTRFS, обязательно используйте дистрибутив с ядром 3.2.0-2 или новее. 3.1.x работоспособен при необходимости. Для более старых ядер вам нужно самостоятельно скомпилировать последние модули BTRFS. Встроенные из них почти стабильны, но исправление ошибок не работает в старых версиях, что может оставить вас в тупике, если что-то пойдет не так. В последних версиях есть утилита fsck, которая может исправлять наиболее распространенные неисправности.
Последнее замечание: я слышал сообщения о том, что файлы подкачки в файловой системе BTRFS повредят его. Возможно, эта проблема была исправлена, но обязательно проверьте ее перед ее внедрением.
Если вам нужна помощь, чтобы настроить BTRFS так, как вы хотите, дайте мне знать. Я сделал несколько сумасшедших, которые довольно хорошо работают для конкретных вещей.
Я бы не стал использовать ext4 на твердотельном диске, основываясь на неподтвержденных данных, и мой собственный опыт, который показывает, что ext4 может значительно сократить время жизни SSD из-за количества операций чтения и записи, связанных с файловой системой. Одна статья, которую я недавно прочитал, предполагает, что неоптимизированное (с учетом размера страницы и т. Д.) Ext4 на SSD может сократить срок службы диска вдвое. После недели устранения неполадок я пришел к выводу, что из-за этой проблемы мои собственные твердотельные накопители прослужили всего восемь месяцев. Если вы используете SSD, внимательно прочитайте о том, как оптимизировать файловую систему, исходя из таких вещей, как размер страницы флэш-памяти, который может отличаться от типичного размера цилиндра, для которого настроена файловая система.