Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup). Оптимизации реализованы для файловых систем TmpFS, UFS и ZFS, но пока не распространяется на ACL, Capsicum, доступ к файловым дескрипторам, символические ссылки и ".." в путях. Для указанных возможностей осуществляется откат на старый механизм определения файлов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53442
nullfs?
unionfs в ядре когда починят?
В 4.11 все было ок, чо тебе еще надо-то?
(судя по пожеланиям - ты вообще-то будешь вполне счастлив с этой версией - если найдешь на чем ее запустить)
вопрос был по теме, а "ответ" - чисто трололо. По теме сказать нечего?
Повторяю для "детей природы":
nullfs - lockless lookup?
unionfs - починили паники?
повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне коробочек ни разу не было во времена 4.11
Пользуйся.А, да, ее ж скачать теперь неоткуда...
lookup там на уровне vfs, ему все равно, что там ниже. Только он недописанный и выглядит стремно. Написано это все одним-единственным человеком, одобрил комит другой единственный человек - честно разбиравшийся, но он был тоже ровно один, остальным разработчикам это неинтересно.
Функциональных тестов, разумеется, писать не принято (впрочем, кому и когда они помогали).
Поэтому я бы пока этим кодом вообще не пользовался.
этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...
Proof?
> этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...За лет 9 использования в качестве /tmp и штатного портового WRKDIRPREFIX для сборки софта (в том числе и уже давно при сборке жрущей несколько гигов лисы) - не замечал.
"Не отдает память после удаления" оно только в случае "висящих" файлодескрипторов.
Как раз tmpfs отдаёт, а ufs2 поверх md нет.
Неправда. Поставьте последнюю из семейства 11 или 12, и посмотрите сами.
Прочитал как lockless lockup. Годное название для фичи :D
Шёл 2020 год...
Печально, что в линуксе нет даже этого.
Таких тормозов? Да, очень печально (нет)
Дыр
> ДырБлин, а зачем нам в линуксе дыры? Может и хорошо что нет? oO
Ладно, а если серьёзно, какие цифры у линукса в этом контексте будут?
Если на то пошло то таких тормазов как в венде вообще нигде нет.И да, в твоей божественной растишке.
Срочно пишите Линусу пусть замедлит VFS в 69 раз, нет лучше в 70 раз.
Дальше я потом напишу что делать...
Виновата Нвидиа.
Дык тут как раз разный, показательный подход к написанию кода.
BSD шники постепенно снимают ограничения, после четкой проработки алгоритмов, и результат идет как фича.
а линуксоилы ставят ограничения после обнаружения дыры.И результат как обычно производительность BSD растет, линукса падает.
>Печально, что в линуксе нет даже этого.В Линуксе уже 10 лет как это есть. LOOKUP_RCU
>>Печально, что в линуксе нет даже этого.
>В Линуксе уже 10 лет как это есть. LOOKUP_RCUhttps://www.kernel.org/doc/Documentation/filesystems/Locking
Только почему-то возле операции "lookup:" стоит флажок "shared", а не "no", как, например, у "readlink:"
Это потому что буквы читать ты научился, а понимать - нет.
Поясни, просвящённый?
> Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup).судя по коду там не lockless lookup - а скорее использование seq lock.
А что, молодцы. Приятно, и так летает а тут ещё прирост. Это вам не венда, люди о производительности думают по крайней мере. А не гамбургеры и вырвиглазный дизайн пихают.
Чего молодцы-то. Изменение в 69 раз - это значит оригинал ногами писан.
А чего там ещё по ведру раскидано такого же, ну, вы поняли.
в новостях о 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);
С разницей в 69 раз с минорных изменений?
А вообще снова почитал я этот ваш бздшный код который вы привели, vfs_cache.c.
Как хорошо, что меня это счастье миновало.
А какое-же счастье тебя не миновало?
$ 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
Ну хоть не тошнатворное виндузятство.Зато в BSD миновал ужас с systemd и в скором времени homed. Слава BSD.
И где же у тебя не ногапи писано?
Можно подумать что у винды есть проблемы с производительностью. Разве что в чуть-чуть архаичной ntfs, но ей лет больше чем вам.
В винде ооооооооочень много проблем с производительностью. Про убогую файловую систему вообще лучше молчать.