The OpenNET Project / Index page

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



"Во FreeBSD существенно оптимизированы операции поиска в VFS"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Во FreeBSD существенно оптимизированы операции поиска в VFS"  +/
Сообщение от opennews (??), 30-Июл-20, 10:07 
Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup). Оптимизации реализованы для файловых систем TmpFS, UFS и ZFS, но пока не распространяется на ACL, Capsicum, доступ к  файловым дескрипторам, символические ссылки и ".."  в путях. Для указанных возможностей осуществляется откат на старый механизм определения файлов...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53442

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (-), 30-Июл-20, 10:07   –5 +/
nullfs?
unionfs в ядре когда починят?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17

2. Сообщение от Аноним (-), 30-Июл-20, 10:09   +/
этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #13, #14

3. Сообщение от Аноним (3), 30-Июл-20, 10:14   +/
Прочитал как lockless lockup. Годное название для фичи :D
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Fracta1L (ok), 30-Июл-20, 10:15   –7 +/
Шёл 2020 год...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

5. Сообщение от Аноним (5), 30-Июл-20, 10:19   +/
Печально, что в линуксе нет даже этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6, #7, #12

6. Сообщение от Fracta1L (ok), 30-Июл-20, 10:23   +1 +/
Таких тормозов? Да, очень печально (нет)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8, #10, #19

7. Сообщение от Аноним (7), 30-Июл-20, 10:26   –3 +/
Срочно пишите Линусу пусть замедлит VFS в 69 раз, нет лучше в 70 раз.
Дальше я потом напишу что делать...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9, #35

8. Сообщение от Аноним (8), 30-Июл-20, 10:42   +/
Дыр
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #16

9. Сообщение от Аноним (8), 30-Июл-20, 10:42   +1 +/
Виновата Нвидиа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

10. Сообщение от Аноним (5), 30-Июл-20, 10:48   +1 +/
Ладно, а если серьёзно, какие цифры у линукса в этом контексте будут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

11. Сообщение от Alex_Kemail (??), 30-Июл-20, 11:27   –1 +/
Proof?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

12. Сообщение от Кирилл (??), 30-Июл-20, 11:28   –2 +/
>Печально, что в линуксе нет даже этого.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #15

13. Сообщение от анонн (ok), 30-Июл-20, 12:01   +2 +/
> этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

14. Сообщение от Аноним (14), 30-Июл-20, 14:28   +2 +/
Как раз tmpfs отдаёт, а ufs2 поверх md нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #29

15. Сообщение от Dmitry (??), 30-Июл-20, 15:03   +4 +/
>>Печально, что в линуксе нет даже этого.
>В Линуксе уже 10 лет как это есть. LOOKUP_RCU

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #33

16. Сообщение от Аноним (-), 30-Июл-20, 15:15   –1 +/
> Дыр

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

17. Сообщение от пох. (?), 30-Июл-20, 18:23   +/
В 4.11 все было ок, чо тебе еще надо-то?
(судя по пожеланиям - ты вообще-то будешь вполне счастлив с этой версией - если найдешь на чем ее запустить)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #30

18. Сообщение от Аноним (18), 30-Июл-20, 19:09   +/
> Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup).

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

Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от ann (??), 30-Июл-20, 19:19   +/
Если на то пошло то таких тормазов как в венде вообще нигде нет.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

20. Сообщение от ann (??), 30-Июл-20, 19:21   –1 +/
А что, молодцы. Приятно, и так летает а тут ещё прирост. Это вам не венда, люди о производительности думают по крайней мере. А не гамбургеры и вырвиглазный дизайн пихают.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #28

21. Сообщение от Онаним (?), 30-Июл-20, 19:56   +1 +/
Чего молодцы-то. Изменение в 69 раз - это значит оригинал ногами писан.
А чего там ещё по ведру раскидано такого же, ну, вы поняли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #22, #24

22. Сообщение от Аноним (18), 30-Июл-20, 20:04   +1 +/
в новостях о Linux вы тоже говорите что там ногами писано - каждый раз когда там что-то улучшили?
* Fast path lookup protected with SMR and sequence counters.
3564           *
3565           * Note: all VOP_FPLOOKUP_VEXEC routines have a comment referencing this one.
3566           *
3567           * Filesystems can opt in by setting the MNTK_FPLOOKUP flag and meeting criteria
3568           * outlined below.
3569           *
3570           * Traditional vnode lookup conceptually looks like this:
3571           *
3572           * vn_lock(current);
3573           * for (;;) {
3574           *      next = find();
3575           *      vn_lock(next);
3576           *      vn_unlock(current);
3577           *      current = next;
3578           *      if (last)
3579           *          break;
3580           * }
3581           * return (current);
3582           *
3583           * Each jump to the next vnode is safe memory-wise and atomic with respect to
3584           * any modifications thanks to holding respective locks.
3585           *
3586           * The same guarantee can be provided with a combination of safe memory
3587           * reclamation and sequence counters instead. If all operations which affect
3588           * the relationship between the current vnode and the one we are looking for
3589           * also modify the counter, we can verify whether all the conditions held as
3590           * we made the jump. This includes things like permissions, mount points etc.
3591           * Counter modification is provided by enclosing relevant places in
3592           * vn_seqc_write_begin()/end() calls.
3593           *
3594           * Thus this translates to:
3595           *
3596           * vfs_smr_enter();
3597           * dvp_seqc = seqc_read_any(dvp);
3598           * if (seqc_in_modify(dvp_seqc)) // someone is altering the vnode
3599           *     abort();
3600           * for (;;) {
3601           *      tvp = find();
3602           *      tvp_seqc = seqc_read_any(tvp);
3603           *      if (seqc_in_modify(tvp_seqc)) // someone is altering the target vnode
3604           *          abort();
3605           *      if (!seqc_consistent(dvp, dvp_seqc) // someone is altering the vnode
3606           *          abort();
3607           *      dvp = tvp; // we know nothing of importance has changed
3608           *      dvp_seqc = tvp_seqc; // store the counter for the tvp iteration
3609           *      if (last)
3610           *          break;
3611           * }
3612           * vget(); // secure the vnode
3613           * if (!seqc_consistent(tvp, tvp_seqc) // final check
3614           *          abort();
3615           * // at this point we know nothing has changed for any parent<->child pair
3616           * // as they were crossed during the lookup, meaning we matched the guarantee
3617           * // of the locked variant
3618           * return (tvp);
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #23

23. Сообщение от Онаним (?), 30-Июл-20, 20:21   –1 +/
С разницей в 69 раз с минорных изменений?
А вообще снова почитал я этот ваш бздшный код который вы привели, vfs_cache.c.
Как хорошо, что меня это счастье миновало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #25

24. Сообщение от ann (??), 30-Июл-20, 20:48   +/
И где же у тебя не ногапи писано?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от ann (??), 30-Июл-20, 20:48   +/
А какое-же счастье тебя не миновало?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #26

26. Сообщение от Онаним (?), 30-Июл-20, 22:13   +/
$ 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #27

27. Сообщение от ann (??), 30-Июл-20, 22:32   –1 +/
Ну хоть не тошнатворное виндузятство.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

28. Сообщение от Аноним (28), 31-Июл-20, 01:54   +/
Можно подумать что у винды есть проблемы с производительностью. Разве что в чуть-чуть архаичной ntfs, но ей лет больше чем вам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #32

29. Сообщение от Аноним (-), 31-Июл-20, 06:45   +/
Неправда. Поставьте последнюю из семейства 11 или 12, и посмотрите сами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

30. Сообщение от Аноним (-), 31-Июл-20, 06:48   +/
вопрос был по теме, а "ответ" - чисто трололо. По теме сказать нечего?
Повторяю для "детей природы":
nullfs - lockless lookup?
unionfs - починили паники?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #31

31. Сообщение от пох. (?), 31-Июл-20, 11:25   +/
повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне коробочек ни разу не было во времена 4.11
Пользуйся.

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от ann (??), 31-Июл-20, 16:58   –2 +/
В винде ооооооооочень много проблем с производительностью. Про убогую файловую систему вообще лучше молчать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от Аноним (33), 31-Июл-20, 22:21   +/
Это потому что буквы читать ты научился, а понимать - нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #34

34. Сообщение от Аноним (5), 01-Авг-20, 11:59   +/
Поясни, просвящённый?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

35. Сообщение от bOOster (ok), 04-Авг-20, 13:42   +/
Дык тут как раз разный, показательный подход к написанию кода.
BSD шники постепенно снимают ограничения, после четкой проработки алгоритмов, и результат идет как фича.
а линуксоилы ставят ограничения после обнаружения дыры.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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