The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Во FreeBSD существенно оптимизированы операции поиска в VFS

30.07.2020 10:04

Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup). Оптимизации реализованы для файловых систем TmpFS, UFS и ZFS, но пока не распространяется на ACL, Capsicum, доступ к файловым дескрипторам, символические ссылки и ".." в путях. Для указанных возможностей осуществляется откат на старый механизм определения файлов.

Проведённый на TmpFS тест, измеряющий время доступа к разным файлам, показал увеличение производительности с 2165816 до 151216530 операций в секунду (прирост в 69 раз). Другой тест показал снижение времени выполнения задания с 23 до 14 секунд.

  1. Главная ссылка к новости (https://twitter.com/FreeBSDHel...)
  2. OpenNews: Релиз FreeBSD 11.4
  3. OpenNews: Проект FreeBSD принял новый кодекс поведения разработчиков
  4. OpenNews: Уязвимость во FreeBSD, эксплуатируемая через вредоносное USB-устройство
  5. OpenNews: В ZFS on Linux добавлена поддержка FreeBSD
  6. OpenNews: Отчёт о развитии FreeBSD за первый квартал 2020 года
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53442-freebsd
Ключевые слова: freebsd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:07, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    nullfs?
    unionfs в ядре когда починят?
     
     
  • 2.17, пох. (?), 18:23, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В 4.11 все было ок, чо тебе еще надо-то?
    (судя по пожеланиям - ты вообще-то будешь вполне счастлив с этой версией - если найдешь на чем ее запустить)

     
     
  • 3.30, Аноним (-), 06:48, 31/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вопрос был по теме, а "ответ" - чисто трололо. По теме сказать нечего?
    Повторяю для "детей природы":
    nullfs - lockless lookup?
    unionfs - починили паники?
     
     
  • 4.31, пох. (?), 11:25, 31/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне коробочек ни разу не было во времена 4.11
    Пользуйся.

    А, да, ее ж скачать теперь неоткуда...

    lookup там на уровне vfs, ему все равно, что там ниже. Только он недописанный и выглядит стремно. Написано это все одним-единственным человеком, одобрил комит другой единственный человек - честно разбиравшийся, но он был тоже ровно один, остальным разработчикам это неинтересно.

    Функциональных тестов, разумеется, писать не принято (впрочем, кому и когда они помогали).

    Поэтому я бы пока этим кодом вообще не пользовался.

     

  • 1.2, Аноним (-), 10:09, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...
     
     
  • 2.11, Alex_K (??), 11:27, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Proof?
     
  • 2.13, анонн (ok), 12:01, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...

    За лет 9 использования в качестве /tmp и штатного портового WRKDIRPREFIX для сборки софта (в том числе и уже давно при сборке жрущей несколько гигов лисы) - не замечал.
    "Не отдает память после удаления" оно только в случае "висящих" файлодескрипторов.


     
  • 2.14, Аноним (14), 14:28, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как раз tmpfs отдаёт, а ufs2 поверх md нет.
     
     
  • 3.29, Аноним (-), 06:45, 31/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Неправда. Поставьте последнюю из семейства 11 или 12, и посмотрите сами.
     

  • 1.3, Аноним (3), 10:14, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прочитал как lockless lockup. Годное название для фичи :D
     
  • 1.4, Fracta1L (ok), 10:15, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Шёл 2020 год...
     
     
  • 2.5, Аноним (5), 10:19, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Печально, что в линуксе нет даже этого.
     
     
  • 3.6, Fracta1L (ok), 10:23, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Таких тормозов? Да, очень печально (нет)
     
     
  • 4.8, Аноним (8), 10:42, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дыр
     
     
  • 5.16, Аноним (-), 15:15, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Дыр

    Блин, а зачем нам в линуксе дыры? Может и хорошо что нет? oO

     
  • 4.10, Аноним (5), 10:48, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ладно, а если серьёзно, какие цифры у линукса в этом контексте будут?
     
  • 4.19, ann (??), 19:19, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если на то пошло то таких тормазов как в венде вообще нигде нет.

    И да, в твоей божественной растишке.

     
  • 3.7, Аноним (7), 10:26, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Срочно пишите Линусу пусть замедлит VFS в 69 раз, нет лучше в 70 раз.
    Дальше я потом напишу что делать...
     
     
  • 4.9, Аноним (8), 10:42, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Виновата Нвидиа.
     
  • 4.35, bOOster (ok), 13:42, 04/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дык тут как раз разный, показательный подход к написанию кода.
    BSD шники постепенно снимают ограничения, после четкой проработки алгоритмов, и результат идет как фича.
    а линуксоилы ставят ограничения после обнаружения дыры.

    И результат как обычно производительность BSD растет, линукса падает.

     
  • 3.12, Кирилл (??), 11:28, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Печально, что в линуксе нет даже этого.

    В Линуксе уже 10 лет как это есть. LOOKUP_RCU

     
     
  • 4.15, Dmitry (??), 15:03, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >>Печально, что в линуксе нет даже этого.
    >В Линуксе уже 10 лет как это есть. LOOKUP_RCU

    https://www.kernel.org/doc/Documentation/filesystems/Locking

    Только почему-то возле операции "lookup:" стоит флажок "shared", а не "no", как, например, у "readlink:"

     
     
  • 5.33, Аноним (33), 22:21, 31/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это потому что буквы читать ты научился, а понимать - нет.
     
     
  • 6.34, Аноним (5), 11:59, 01/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поясни, просвящённый?
     

  • 1.18, Аноним (18), 19:09, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup).

    судя по коду там не lockless lookup - а скорее использование seq lock.

     
  • 1.20, ann (??), 19:21, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что, молодцы. Приятно, и так летает а тут ещё прирост. Это вам не венда, люди о производительности думают по крайней мере. А не гамбургеры и вырвиглазный дизайн пихают.
     
     
  • 2.21, Онаним (?), 19:56, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чего молодцы-то. Изменение в 69 раз - это значит оригинал ногами писан.
    А чего там ещё по ведру раскидано такого же, ну, вы поняли.
     
     
  • 3.22, Аноним (18), 20:04, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в новостях о Linux вы тоже говорите что там ногами писано - каждый раз когда там... большой текст свёрнут, показать
     
     
  • 4.23, Онаним (?), 20:21, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С разницей в 69 раз с минорных изменений?
    А вообще снова почитал я этот ваш бздшный код который вы привели, vfs_cache.c.
    Как хорошо, что меня это счастье миновало.
     
     
  • 5.25, ann (??), 20:48, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А какое-же счастье тебя не миновало?
     
     
  • 6.26, Онаним (?), 22:13, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    $ ansible all -a 'uname -srvmpio' | grep Linux | sort | uniq -c | sort -bgr
        188 Linux 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
         47 Linux 5.4.17-2011.0.7.el7uek.x86_64 #2 SMP Mon Mar 16 20:48:30 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
         24 Linux 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
         12 Linux 5.4.17-2011.3.2.1.el7uek.x86_64 #2 SMP Sun May 24 13:37:14 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
          8 Linux 5.4.17-2011.0.7.el8uek.x86_64 #2 SMP Mon Mar 16 20:47:59 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
          4 Linux 5.4.17-2011.2.2.el7uek.x86_64 #2 SMP Sun May 3 23:07:48 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
          3 Linux 5.4.17-2011.3.2.1.el8uek.x86_64 #2 SMP Sun May 24 13:36:59 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux
     
     
  • 7.27, ann (??), 22:32, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну хоть не тошнатворное виндузятство.

    Зато в BSD миновал ужас с systemd и в скором времени homed. Слава BSD.

     
  • 3.24, ann (??), 20:48, 30/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И где же у тебя не ногапи писано?
     
  • 2.28, Аноним (28), 01:54, 31/07/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать что у винды есть проблемы с производительностью. Разве что в чуть-чуть архаичной ntfs, но ей лет больше чем вам.
     
     
  • 3.32, ann (??), 16:58, 31/07/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В винде ооооооооочень много проблем с производительностью. Про убогую файловую систему вообще лучше молчать.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру