|
2.17, пох. (?), 18:23, 30/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
В 4.11 все было ок, чо тебе еще надо-то?
(судя по пожеланиям - ты вообще-то будешь вполне счастлив с этой версией - если найдешь на чем ее запустить)
| |
|
3.30, Аноним (-), 06:48, 31/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
вопрос был по теме, а "ответ" - чисто трололо. По теме сказать нечего?
Повторяю для "детей природы":
nullfs - lockless lookup?
unionfs - починили паники?
| |
|
4.31, пох. (?), 11:25, 31/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
повторяю - паник в unionfs в production use под нехилой нагрузкой на сотне коробочек ни разу не было во времена 4.11
Пользуйся.
А, да, ее ж скачать теперь неоткуда...
lookup там на уровне vfs, ему все равно, что там ниже. Только он недописанный и выглядит стремно. Написано это все одним-единственным человеком, одобрил комит другой единственный человек - честно разбиравшийся, но он был тоже ровно один, остальным разработчикам это неинтересно.
Функциональных тестов, разумеется, писать не принято (впрочем, кому и когда они помогали).
Поэтому я бы пока этим кодом вообще не пользовался.
| |
|
|
|
1.2, Аноним (-), 10:09, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...
| |
|
2.13, анонн (ok), 12:01, 30/07/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> этот tmpfs всё равно не отдаёт нормально память системе после удаления файлов, в отличие от UFS2 поверх RAM-диска, так что толку с него...
За лет 9 использования в качестве /tmp и штатного портового WRKDIRPREFIX для сборки софта (в том числе и уже давно при сборке жрущей несколько гигов лисы) - не замечал.
"Не отдает память после удаления" оно только в случае "висящих" файлодескрипторов.
| |
|
3.29, Аноним (-), 06:45, 31/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Неправда. Поставьте последнюю из семейства 11 или 12, и посмотрите сами.
| |
|
|
|
|
|
|
5.16, Аноним (-), 15:15, 30/07/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Дыр
Блин, а зачем нам в линуксе дыры? Может и хорошо что нет? oO
| |
|
4.10, Аноним (5), 10:48, 30/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ладно, а если серьёзно, какие цифры у линукса в этом контексте будут?
| |
4.19, ann (??), 19:19, 30/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Если на то пошло то таких тормазов как в венде вообще нигде нет.
И да, в твоей божественной растишке.
| |
|
3.7, Аноним (7), 10:26, 30/07/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Срочно пишите Линусу пусть замедлит VFS в 69 раз, нет лучше в 70 раз.
Дальше я потом напишу что делать...
| |
|
4.35, bOOster (ok), 13:42, 04/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Дык тут как раз разный, показательный подход к написанию кода.
BSD шники постепенно снимают ограничения, после четкой проработки алгоритмов, и результат идет как фича.
а линуксоилы ставят ограничения после обнаружения дыры.
И результат как обычно производительность BSD растет, линукса падает.
| |
|
3.12, Кирилл (??), 11:28, 30/07/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
>Печально, что в линуксе нет даже этого.
В Линуксе уже 10 лет как это есть. LOOKUP_RCU
| |
|
|
1.18, Аноним (18), 19:09, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Во FreeBSD приняты изменения, позволяющие выполнять операции поиска в VFS без блокировок (lockless lookup).
судя по коду там не lockless lookup - а скорее использование seq lock.
| |
1.20, ann (??), 19:21, 30/07/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А что, молодцы. Приятно, и так летает а тут ещё прирост. Это вам не венда, люди о производительности думают по крайней мере. А не гамбургеры и вырвиглазный дизайн пихают.
| |
|
2.21, Онаним (?), 19:56, 30/07/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Чего молодцы-то. Изменение в 69 раз - это значит оригинал ногами писан.
А чего там ещё по ведру раскидано такого же, ну, вы поняли.
| |
|
3.22, Аноним (18), 20:04, 30/07/2020 [^] [^^] [^^^] [ответить] | +1 +/– | в новостях о Linux вы тоже говорите что там ногами писано - каждый раз когда там... большой текст свёрнут, показать | |
|
4.23, Онаним (?), 20:21, 30/07/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
С разницей в 69 раз с минорных изменений?
А вообще снова почитал я этот ваш бздшный код который вы привели, vfs_cache.c.
Как хорошо, что меня это счастье миновало.
| |
|
|
6.26, Онаним (?), 22:13, 30/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
$ 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
| |
|
7.27, ann (??), 22:32, 30/07/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну хоть не тошнатворное виндузятство.
Зато в BSD миновал ужас с systemd и в скором времени homed. Слава BSD.
| |
|
|
|
|
|
2.28, Аноним (28), 01:54, 31/07/2020 [^] [^^] [^^^] [ответить]
| +/– |
Можно подумать что у винды есть проблемы с производительностью. Разве что в чуть-чуть архаичной ntfs, но ей лет больше чем вам.
| |
|
3.32, ann (??), 16:58, 31/07/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
В винде ооооооооочень много проблем с производительностью. Про убогую файловую систему вообще лучше молчать.
| |
|
|
|