Свежие комментарии

Понаблюдай за ARC. У меня на свежем 11.2-STABLE что-то ARC занимает 4.5 гига из 16, при том что Wired-памяти — 15 гигов.
Я как-то на более ранних версиях привык видеть 13-14 гигов ARC'а на той же машине.

Что там wired не ясно :-(

$ time make -j5 buildworld
World build completed on Tue Nov 20 09:45:18 MSK 2018
--------------------------------------------------------------

real    134m7.049s
user    621m27.899s
sys     29m30.579s

134/89 = 1.5

8/5 = 1.6

Короче, если и не ядрами ограничено, то близко к этому.

На снапшоте если только.
У меня только одна система с zfs. Хотя от разнесения и другим fs должно полегчать, и выбирать имена для "этажей" лучше с конца хеша, там "разброс" больше. А любой файл, который не на нужном уровне, передвигать на нужный (вот кстати и upgrade/downgrade path)

Кстати интересно, при наличии снапшота будет такой же эффект, или это только unlink "навсегда" приводит к таким веселым эффектам.

Ну относительно несложно.
Надо только про upgrade path подумать, если я хочу это в апстрим продвигать.

Собственно есть у меня каталог на zfs dataset -- в нем примерно 5 миллионов файлов с именами в виде хешей (такой дедупликатор для бедных) -- мы по нему идем, и вычищаем файлы у которых st.nlinks == 1, занимает это часы, а не минуты -- я пошел смотреть strace и разбираться как умею.

strace понятно частичный, от двухминутного пробега
Partial `strace -w -c` for process which do readdir/lstat/unlink loop on 5M files in one dir
file names is a base58(sha256(file_content)).

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 66,36   65,516804     1559923        42           getdents
 22,83   22,535192        1178     19118           lstat
 10,80   10,658754       18440       578           unlink
  0,01    0,012003          20       578           write
------ ----------- ----------- --------- --------- ----------------
100.00 98,722753 20316 total

Просто getdents на том же каталоге отрабатывает за 4 минуты (${coreutils}/bin/ls -f /nix/store/.links >/dev/nill).

Потом я запустил очистку повторно, и увидел следующее: (опять же двухминутная выдержка пока оно по "чистому" колупалось)
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99,84  115,540901        6728     17172           lstat
  0,16    0,187311        5062        37           getdents
------ ----------- ----------- --------- --------- ----------------
100.00 115,728212 17209 total

Собственно вопрос -- что вызывает такое патологическое поведение, и как лечить.
Сам код -- здесь, https://github.com/NixOS/nix/blob/master/src/libstore/gc.cc#L693

У меня скромные идеи запилить fstatat/unlinkat (и то я не уверен, а можно ли unlinkat(dirfd(dir), file) внутри цикла с readdir, и не сломается ли от этого OSX -- там это тоже используют)

Может ли помочь leveling (или как это правильно называется -- когда "abcde..." разносится по каталогам как a/bc/de...")? Могут ли влиять имена файлов (хеши -- там base58(sha256(content))) -- все имена начинаются с "0" или "1" -- может ли это какой-то corner case триггерить? (или я уже на воду дую)

Хочется идей и советов, потому что свои идеи кончились.

А вопрос - конечно давайте.

Этот ящик пустой-ненагруженный, пусть поработает.

Запустил, часа через два будет результат, напишу.

Я так понимаю надо делать amalgamation там, где конструкция позволяет (тупо united.c с инклюдами всех файлов в каталоге) -- всякие браузеры так собираются, и дает оно 20-30% времени сборки)

PS я думал у вас / тоже на zfs. (у меня тут вопрос есть, на #zfsonlinux я с ним уже ходил и тут спрошу, если позволите)

Описанным способом kgdb используется на живой системе, он не останавливает исполнение. Это такой удобный тул для чтения памяти.

По идее ARС тоже должен влиять, и скорее в лучшую сторону (все includes с первого вызова компилятора оказываются там)

C точки зрения FreeBSD:
WD: ada1: 1907729MB (3907029168 512 byte sectors)
OCZ: ada0: 228936MB (468862128 512 byte sectors)
Да, смешно кстати, они оба SATA-2, я уже и забыл что такие бывают :)

Более того, WD меньше 2Tb т.е. какие-то приколы "диск больше 2Tb - только UEFI" ну тоже маловероятны.

Да впроде прав. Я могу только скопипастить модный смайлик пожатия плечами.

Про CSM по счастью известно что это такое. Это поддержка старой загрузки (эмуляция BIOS).

Но почему это место влияет на UEFI boot - не пойму. Почему при выключенном CSM можно включить Legacy загрузку (которая гарантированно НЕ будет работать) - как раз пойму (от лени разработчиков, конечно ж)

Ну мне вот в каком-то смысле повезло: собственно инсталлятор FreeBSD с флешки грузится без вопросов и на ура (memstick который). Если бы этого не было - уж не знаю что я бы делал, потому что "ну вот, не грузится", а покупал я через форвардера, возврат - дело непонятное в такой ситуации (с точки зрения ebay - все приехало и ок).

В форумах я наоборот начитался, что на этих матерях pfsense (freebsd) грузится нормально, а вот Linux - не очень.

Похоже, намутили с этим secure boot лишнего, говорю же "custom" тронуть боюсь.