Вопросы Теги

Какова самая высокоэффективная файловая система Linux для хранения большого количества маленьких файлов (жесткий диск, не SSD)?

:set list

Это покажет Вам пробельные символы как вкладки и EoLs. Это не покажет пробелы, однако; к моему знанию это не возможно (за исключением неразрывных и конечных пробелов), хотя в моноширинном шрифте любое "пространство" это не вкладка, очевидно, было бы пространство.

Можно изменить использование энергии символов с listchars опция; ввести :help listchars узнать больше, как использовать это и каковы Ваши опции.

Это - то, что я использую в своем .vimrc файле:

" Set some nice character listings, then activate list
execute 'set listchars+=tab:\ ' . nr2char(187)
execute 'set listchars+=eol:' . nr2char(183)
set list
44
13.01.2012, 16:36
4 ответа

Производительность

Я записал маленький Сравнительный тест (источник), для обнаружения, что файловая система выполняет лучше всего с сотней тысячами маленьких файлов:

  • создайте 300 000 файлов (512B к 1536B) с данными из/dev/urandom
  • перепишите 30 000 случайных файлов и измените размер
  • считайте 30 000 последовательных файлов
  • считайте 30 000 случайных файлов

  • удалите все файлы

  • синхронизация и кэш отбрасывания после каждого шага

Результаты (среднее время в секундах, понизьтесь = лучше):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Результат:
В то время как Ext4 имел хорошую общую производительность, ReiserFS был экстремальным значением быстро при чтении последовательных файлов. Оказалось, что XFS является медленным со многими маленькими файлами - Вы не должны использовать его для этого варианта использования.

Проблема фрагментации

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

Дальнейшее чтение

Дуга Wiki имеет некоторые большие статьи, имеющие дело с производительностью файловой системы:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

48
27.01.2020, 19:34
  • 1
    Необходимо указать, из какой версии ядра Вы основываете то сравнение прочь. XFS добралась, некоторая очень значительная скорость imporovments в одном из недавних ядер (думайте, что это было 2.6.31, но не заключайте мне в кавычки на этом). –  Patrick 11.01.2012, 03:47
  • 2
    btrfs внутренне делает Ваш прием lvm. Это выделяет меньшие блоки диска и помещает файлы в те блоки, затем только выделяет другой блок диска, когда существующие блоки заполниться. –  psusi 11.01.2012, 21:38
  • 3
    , верный для любой файловой системы. Именно поэтому приложения используют вещи как fsync (). –  psusi 12.01.2012, 20:49
  • 4
    @taffer, это. Транзакции имеют тот же эффект, как журнал делает в других файловых системах: они защищают метаданные фс. В теории они могут использоваться приложениями в способе, которым Вы описываете, но в настоящее время нет никакого API, чтобы позволить приложениям открывать и заключать сделки. человек –  psusi 12.01.2012, 22:31

Я использую ReiserFS для этой задачи, это особенно сделано для обработки большого количества маленьких файлов. Существует легкое для чтения текста об этом в funtoo Wiki.

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

7
27.01.2020, 19:34
  • 1
    Существуют проблемы устойчивости также с ReiserFS - таким образом, RH и SuSE отбросили тот FS. От принципа (BTree-based-FS) BTRFS должно быть сопоставимым. –  Nils 10.01.2012, 22:59

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

Кроме того, XFS поддерживает дефрагментацию онлайн. Хотя это действительно использует отложенный метод выделения, который приводит к меньшему количеству фрагментации (по сравнению с другими файловыми системами) для начала.

0
27.01.2020, 19:34
  • 1
    XFS известен выполнением очень хорошо в таких ситуациях. [необходима цитата] прохладный –  taffer 14.01.2012, 18:13
  • 2
    Ehm, xfs особенно известен противоположным: работа действительно хорошо с большими файлами, но не, что хорошо на маленьких! Посмотрите на этот исчерпывающий сравнительный тест, например (или право перехода на заключение на странице 10 ^^): ilsistemista.net/index.php/linux-a-unix / … –  Levite 02.07.2014, 15:51
  • 3
    @Levit, я думаю, что Вы неправильно читаете тот отчет. Отчет очень ясно показывает, что XFS работает очень хорошо для случайного IO. Но это в стороне, отчет не обращается к типу сценария в этом вопросе, большом количестве файлов. Случайный IO является одной вещью, большие количества файлов то, где расширение* терпит фиаско. –  Patrick 02.07.2014, 16:26
  • 4
    Единственное место XFS действительно лучше, существует случайные операции чтения-записи (все еще кажется странным, который действительно случайный шаблон чтения на механическом диске может получить, 10MB/s - кажется мне как некоторая оптимизация, которая не летит в реальном мире (по моему скромному мнению)), тогда как на странице 7 это показывает, что я сказал ранее, XFS действительно хорош в обработке больших файлов! Взгляд разбивает на страницы 3&5, особенно на 3 Вы видите, что он обрабатывает маленькие файлы ясно не, а также расширение! У меня действительно ничего нет против XFS, хотя, но от того, что Вы находите примерно везде, это не лучшая опция для многих маленьких файлов, все, что я говорю! –  Levite 03.07.2014, 09:22
  • 5
    XFS также может быть чрезвычайно медленным когда дело доходит до больших файлов, если эти файлы расширяются случайным образом/медленно с маленькими блоками за долгое время. (Типичное syslogd шаблон.), Например, рядом в XFS по установке MD я просто наблюдал, то удаление файла на 1,5 ГБ заняло 4,75 минуты (!), в то время как дисковод был ограничен в 100 пределах транзакций/с на уровне записи больше чем 2 МБ/с. Это также влияет на производительность другой параллели, идущей операции IO на том же диске плохо, как диск уже истрачен. Никогда не видел ничего как этот в другом FS (или протестированный в сравнительных тестах). –  Tino 13.06.2015, 15:40

Производительность ext4 падает после 1-2 миллионов файлов в каталоге. См. эту страницу http://genomewiki.ucsc.edu/index.php/File_system_performance, созданную Хирамом Клоусоном из UCSC

.
8
27.01.2020, 19:34

Теги

Похожие вопросы