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




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

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