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

"Во 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_K (??), 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 | Индекс форумов | Темы | Пред. тема | След. тема