forum.opennet.ru - "Во FreeBSD существенно оптимизированы операции поиска в VFS" (35)

"Во 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ообщить модератору

Оглавление

nullfs unionfs в ядре когда починят , Аноним (-), 10:07 , 30-Июл-20, (1) –5

В 4 11 все было ок, чо тебе еще надо-то судя по пожеланиям - ты вообще-то будеш, пох. (?), 18:23 , 30-Июл-20, (17)

вопрос был по теме, а ответ - чисто трололо По теме сказать нечего Повторяю д, Аноним (-), 06:48 , 31-Июл-20, (30)

повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне короб, пох. (?), 11:25 , 31-Июл-20, (31)

этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в, Аноним (-), 10:09 , 30-Июл-20, (2)

Proof , Alex_K (??), 11:27 , 30-Июл-20, (11) –1
За лет 9 использования в качестве tmp и штатного портового WRKDIRPREFIX для сбо, анонн (ok), 12:01 , 30-Июл-20, (13) +2
Как раз tmpfs отдаёт, а ufs2 поверх md нет , Аноним (14), 14:28 , 30-Июл-20, (14) +2

Неправда Поставьте последнюю из семейства 11 или 12, и посмотрите сами , Аноним (-), 06:45 , 31-Июл-20, (29)

Прочитал как lockless lockup Годное название для фичи D, Аноним (3), 10:14 , 30-Июл-20, (3)
Шёл 2020 год , Fracta1L (ok), 10:15 , 30-Июл-20, (4) –7

Печально, что в линуксе нет даже этого , Аноним (5), 10:19 , 30-Июл-20, (5)

Таких тормозов Да, очень печально нет , Fracta1L (ok), 10:23 , 30-Июл-20, (6) +1

Дыр, Аноним (8), 10:42 , 30-Июл-20, (8)

Блин, а зачем нам в линуксе дыры Может и хорошо что нет oO, Аноним (-), 15:15 , 30-Июл-20, (16) –1

Ладно, а если серьёзно, какие цифры у линукса в этом контексте будут , Аноним (5), 10:48 , 30-Июл-20, (10) +1
Если на то пошло то таких тормазов как в венде вообще нигде нет И да, в твоей бо, ann (??), 19:19 , 30-Июл-20, (19)

Срочно пишите Линусу пусть замедлит VFS в 69 раз, нет лучше в 70 раз Дальше я по, Аноним (7), 10:26 , 30-Июл-20, (7) –3

Виновата Нвидиа , Аноним (8), 10:42 , 30-Июл-20, (9) +1
Дык тут как раз разный, показательный подход к написанию кода BSD шники постепен, bOOster (ok), 13:42 , 04-Авг-20, (35)

В Линуксе уже 10 лет как это есть LOOKUP_RCU, Кирилл (??), 11:28 , 30-Июл-20, (12) –2

https www kernel org doc Documentation filesystems LockingТолько почему-то воз, Dmitry (??), 15:03 , 30-Июл-20, (15) +4

Это потому что буквы читать ты научился, а понимать - нет , Аноним (33), 22:21 , 31-Июл-20, (33)

Поясни, просвящённый , Аноним (5), 11:59 , 01-Авг-20, (34)

судя по коду там не lockless lookup - а скорее использование seq lock , Аноним (18), 19:09 , 30-Июл-20, (18)
А что, молодцы Приятно, и так летает а тут ещё прирост Это вам не венда, люди , ann (??), 19:21 , 30-Июл-20, (20) –1

Чего молодцы-то Изменение в 69 раз - это значит оригинал ногами писан А чего та, Онаним (?), 19:56 , 30-Июл-20, (21) +1

в новостях о Linux вы тоже говорите что там ногами писано - каждый раз когда там, Аноним (18), 20:04 , 30-Июл-20, (22) +1

С разницей в 69 раз с минорных изменений А вообще снова почитал я этот ваш бздшн, Онаним (?), 20:21 , 30-Июл-20, (23) –1

А какое-же счастье тебя не миновало , ann (??), 20:48 , 30-Июл-20, (25)

ansible all -a uname -srvmpio 124 grep Linux 124 sort 124 uniq -c , Онаним (?), 22:13 , 30-Июл-20, (26)

Ну хоть не тошнатворное виндузятство Зато в BSD миновал ужас с systemd и в скоро, ann (??), 22:32 , 30-Июл-20, (27) –1

И где же у тебя не ногапи писано , ann (??), 20:48 , 30-Июл-20, (24)

Можно подумать что у винды есть проблемы с производительностью Разве что в чуть, Аноним (28), 01:54 , 31-Июл-20, (28)

В винде ооооооооочень много проблем с производительностью Про убогую файловую с, ann (??), 16:58 , 31-Июл-20, (32) –2

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

1. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –5 +/–

Сообщение от Аноним (-), 30-Июл-20, 10:07

nullfs?
unionfs в ядре когда починят?

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

17. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от пох. (?), 30-Июл-20, 18:23

В 4.11 все было ок, чо тебе еще надо-то?
(судя по пожеланиям - ты вообще-то будешь вполне счастлив с этой версией - если найдешь на чем ее запустить)

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

30. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (-), 31-Июл-20, 06:48

вопрос был по теме, а "ответ" - чисто трололо. По теме сказать нечего?
Повторяю для "детей природы":
nullfs - lockless lookup?
unionfs - починили паники?

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

31. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от пох. (?), 31-Июл-20, 11:25

повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне коробочек ни разу не было во времена 4.11
Пользуйся.
А, да, ее ж скачать теперь неоткуда...
lookup там на уровне vfs, ему все равно, что там ниже. Только он недописанный и выглядит стремно. Написано это все одним-единственным человеком, одобрил комит другой единственный человек - честно разбиравшийся, но он был тоже ровно один, остальным разработчикам это неинтересно.
Функциональных тестов, разумеется, писать не принято (впрочем, кому и когда они помогали).
Поэтому я бы пока этим кодом вообще не пользовался.

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

2. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (-), 30-Июл-20, 10:09

этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...

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

11. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –1 +/–

Сообщение от Alex_K (??), 30-Июл-20, 11:27

Proof?

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

13. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +2 +/–

Сообщение от анонн (ok), 30-Июл-20, 12:01

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

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

14. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +2 +/–

Сообщение от Аноним (14), 30-Июл-20, 14:28

Как раз tmpfs отдаёт, а ufs2 поверх md нет.

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

29. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (-), 31-Июл-20, 06:45

Неправда. Поставьте последнюю из семейства 11 или 12, и посмотрите сами.

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

3. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (3), 30-Июл-20, 10:14

Прочитал как lockless lockup. Годное название для фичи :D

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

4. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –7 +/–

Сообщение от Fracta1L (ok), 30-Июл-20, 10:15

Шёл 2020 год...

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

5. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (5), 30-Июл-20, 10:19

Печально, что в линуксе нет даже этого.

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

6. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +1 +/–

Сообщение от Fracta1L (ok), 30-Июл-20, 10:23

Таких тормозов? Да, очень печально (нет)

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

8. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (8), 30-Июл-20, 10:42

Дыр

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

16. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –1 +/–

Сообщение от Аноним (-), 30-Июл-20, 15:15

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

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

10. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +1 +/–

Сообщение от Аноним (5), 30-Июл-20, 10:48

Ладно, а если серьёзно, какие цифры у линукса в этом контексте будут?

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

19. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от ann (??), 30-Июл-20, 19:19

Если на то пошло то таких тормазов как в венде вообще нигде нет.
И да, в твоей божественной растишке.

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

7. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –3 +/–

Сообщение от Аноним (7), 30-Июл-20, 10:26

Срочно пишите Линусу пусть замедлит VFS в 69 раз, нет лучше в 70 раз.
Дальше я потом напишу что делать...

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

9. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +1 +/–

Сообщение от Аноним (8), 30-Июл-20, 10:42

Виновата Нвидиа.

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

35. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от bOOster (ok), 04-Авг-20, 13:42

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

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

12. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –2 +/–

Сообщение от Кирилл (??), 30-Июл-20, 11:28

>Печально, что в линуксе нет даже этого.
В Линуксе уже 10 лет как это есть. LOOKUP_RCU

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

15. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +4 +/–

Сообщение от Dmitry (??), 30-Июл-20, 15:03

>>Печально, что в линуксе нет даже этого.
>В Линуксе уже 10 лет как это есть. LOOKUP_RCU
https://www.kernel.org/doc/Documentation/filesystems/Locking
Только почему-то возле операции "lookup:" стоит флажок "shared", а не "no", как, например, у "readlink:"

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

33. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (33), 31-Июл-20, 22:21

Это потому что буквы читать ты научился, а понимать - нет.

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

34. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (5), 01-Авг-20, 11:59

Поясни, просвящённый?

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

18. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (18), 30-Июл-20, 19:09

> Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup).
судя по коду там не lockless lookup - а скорее использование seq lock.

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

20. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –1 +/–

Сообщение от ann (??), 30-Июл-20, 19:21

А что, молодцы. Приятно, и так летает а тут ещё прирост. Это вам не венда, люди о производительности думают по крайней мере. А не гамбургеры и вырвиглазный дизайн пихают.

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

21. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +1 +/–

Сообщение от Онаним (?), 30-Июл-20, 19:56

Чего молодцы-то. Изменение в 69 раз - это значит оригинал ногами писан.
А чего там ещё по ведру раскидано такого же, ну, вы поняли.

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

22. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +1 +/–

Сообщение от Аноним (18), 30-Июл-20, 20:04

в новостях о 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ообщить модератору

23. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –1 +/–

Сообщение от Онаним (?), 30-Июл-20, 20:21

С разницей в 69 раз с минорных изменений?
А вообще снова почитал я этот ваш бздшный код который вы привели, vfs_cache.c.
Как хорошо, что меня это счастье миновало.

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

25. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от ann (??), 30-Июл-20, 20:48

А какое-же счастье тебя не миновало?

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

26. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Онаним (?), 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ообщить модератору

27. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –1 +/–

Сообщение от ann (??), 30-Июл-20, 22:32

Ну хоть не тошнатворное виндузятство.
Зато в BSD миновал ужас с systemd и в скором времени homed. Слава BSD.

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

24. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от ann (??), 30-Июл-20, 20:48

И где же у тебя не ногапи писано?

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

28. "Во FreeBSD существенно оптимизированы операции поиска в VFS" +/–

Сообщение от Аноним (28), 31-Июл-20, 01:54

Можно подумать что у винды есть проблемы с производительностью. Разве что в чуть-чуть архаичной ntfs, но ей лет больше чем вам.

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

32. "Во FreeBSD существенно оптимизированы операции поиска в VFS" –2 +/–

Сообщение от ann (??), 31-Июл-20, 16:58

В винде ооооооооочень много проблем с производительностью. Про убогую файловую систему вообще лучше молчать.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


	31. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от пох. (?), 31-Июл-20, 11:25
	повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне коробочек ни разу не было во времена 4.11 Пользуйся. А, да, ее ж скачать теперь неоткуда... lookup там на уровне vfs, ему все равно, что там ниже. Только он недописанный и выглядит стремно. Написано это все одним-единственным человеком, одобрил комит другой единственный человек - честно разбиравшийся, но он был тоже ровно один, остальным разработчикам это неинтересно. Функциональных тестов, разумеется, писать не принято (впрочем, кому и когда они помогали). Поэтому я бы пока этим кодом вообще не пользовался.
	Ответить \| Правка \| Наверх \| Cообщить модератору

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


	11. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	–1 +/–
	Сообщение от Alex_K (??), 30-Июл-20, 11:27
	Proof?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+2 +/–
	Сообщение от анонн (ok), 30-Июл-20, 12:01
	> этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него... За лет 9 использования в качестве /tmp и штатного портового WRKDIRPREFIX для сборки софта (в том числе и уже давно при сборке жрущей несколько гигов лисы) - не замечал. "Не отдает память после удаления" оно только в случае "висящих" файлодескрипторов.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


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


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

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

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


	5. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от Аноним (5), 30-Июл-20, 10:19
	Печально, что в линуксе нет даже этого.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+1 +/–
	Сообщение от Fracta1L (ok), 30-Июл-20, 10:23
	Таких тормозов? Да, очень печально (нет)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от Аноним (8), 30-Июл-20, 10:42
	Дыр
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	–1 +/–
	Сообщение от Аноним (-), 30-Июл-20, 15:15
	> Дыр Блин, а зачем нам в линуксе дыры? Может и хорошо что нет? oO
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	19. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от ann (??), 30-Июл-20, 19:19
	Если на то пошло то таких тормазов как в венде вообще нигде нет. И да, в твоей божественной растишке.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


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


	9. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+1 +/–
	Сообщение от Аноним (8), 30-Июл-20, 10:42
	Виновата Нвидиа.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от bOOster (ok), 04-Авг-20, 13:42
	Дык тут как раз разный, показательный подход к написанию кода. BSD шники постепенно снимают ограничения, после четкой проработки алгоритмов, и результат идет как фича. а линуксоилы ставят ограничения после обнаружения дыры. И результат как обычно производительность BSD растет, линукса падает.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	12. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	–2 +/–
	Сообщение от Кирилл (??), 30-Июл-20, 11:28
	>Печально, что в линуксе нет даже этого. В Линуксе уже 10 лет как это есть. LOOKUP_RCU
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	15. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+4 +/–
	Сообщение от Dmitry (??), 30-Июл-20, 15:03
	>>Печально, что в линуксе нет даже этого. >В Линуксе уже 10 лет как это есть. LOOKUP_RCU https://www.kernel.org/doc/Documentation/filesystems/Locking Только почему-то возле операции "lookup:" стоит флажок "shared", а не "no", как, например, у "readlink:"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от Аноним (33), 31-Июл-20, 22:21
	Это потому что буквы читать ты научился, а понимать - нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от Аноним (5), 01-Авг-20, 11:59
	Поясни, просвящённый?
	Ответить \| Правка \| Наверх \| Cообщить модератору

18. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
Сообщение от Аноним (18), 30-Июл-20, 19:09
> Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup). судя по коду там не lockless lookup - а скорее использование seq lock.
Ответить \| Правка \| Наверх \| Cообщить модератору

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


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


	22. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+1 +/–
	Сообщение от Аноним (18), 30-Июл-20, 20:04
	в новостях о 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ообщить модератору


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


	25. "Во FreeBSD существенно оптимизированы операции поиска в VFS"	+/–
	Сообщение от ann (??), 30-Июл-20, 20:48
	А какое-же счастье тебя не миновало?
	Ответить \| Правка \| Наверх \| Cообщить модератору