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

Title Comment
Это больше не ZoL, это

Это больше не ZoL, это OpenZFS теперь, и он будет в FreeBSD через пол-года. А тогда будет поздно.

Я правда не понимаю, в чём проблема.

Ну и я не буду. Потому что у

Ну и я не буду. Потому что у меня нет issue ZoL

В переписке про compressed

В переписке про compressed arc, от Алана Джуда, который как раз может иметь большой вес в решении таких вопросов:

> I am not sure we want to maintain that extra code complexity just to
> support people running ZFS on Atom CPUs. If you actually have such a use
> case, please provide the details, but if your only reference to such a
> use case is one single paragraph post in russian on a random blog, it
> won't have as much weight, since it lacks all of the detail required to
> actually determine what the bottleneck is.

Как я и говорил — нужны точные подробности. Видимо, сами они тебе писать не будут (и я могу их понять, если честно).

Я пользы как фотограф не вижу

Я пользы как фотограф не вижу ;)
А как "разработчик" - не сильно люблю говорить "это экспериментальная фича" в ответ на вопрос, почему Nikon View показывает одно, а FastRawViewer - другое.
Никакой помощи от пользователей в этом месте не будет, тут надо формат знать - примеры, "где не работает", пойдут тоннами, пользы от них мало. Реальная помощь "от пользователей" - написать модуль к LibRaw и сопровождать его хотя бы лет 10. Я вот лично на такое не рассчитываю.
Я просто объясняю свою позицию, ни в коем случае не стремясь поддеть или обидеть.

Илья, мне кажется всегда

Илья, мне кажется всегда можно расписать функцию как "экспериментальную", но дать возможность ей пользоваться там, где это возможно. программы тоже не пишутся без багов, тем не менее они правятся и бывает правятся по отзывам самих пользователей.

по поводу полезности информации: возможно вы как разработчик не видите пользы от этого, но мне было бы интересно увидеть что цветок выпал из "грип" по причине, например фокуса на мдф. как разработчику я могу конечно вам доверять что эта функция потребует у вас N-ого кол-ча человека дней, но готов поспорить с малополезностью "оной". может есть где голосовалка за "хотелки от народа"?

тем не менее, за продукт - спасибо

большое спасибо за надежду.

большое спасибо за надежду. будем ждать :)

А давайте проверим! Лёгкий же

А давайте проверим! Лёгкий же эксперимент. Вот сейчас:

Mem: 30M Active, 380M Inact, 64M Laundry, 30G Wired, 445M Free
ARC: 13G Total, 4305M MFU, 7933M MRU, 2180K Anon, 53M Header, 1143M Other
11G Compressed, 12G Uncompressed, 1.06:1 Ratio

Читаем файл на G который не в торрентах:

# dd if=Paris-Roubaix\ 2016\ \[FULL\ RACE]_720.mp4 of=/dev/null bs=128k
92952+1 records in
92952+1 records out
12183471924 bytes transferred in 21.152020 secs (575995657 bytes/sec)
#

Смотрим в top:

Mem: 28M Active, 380M Inact, 67M Laundry, 30G Wired, 441M Free
ARC: 13G Total, 4288M MFU, 7956M MRU, 2108K Anon, 54M Header, 1142M Other
11G Compressed, 12G Uncompressed, 1.05:1 Ratio

читаем ещё раз:

# dd if=Paris-Roubaix\ 2016\ \[FULL\ RACE]_720.mp4 of=/dev/null bs=128k
92952+1 records in
92952+1 records out
12183471924 bytes transferred in 19.810496 secs (615000861 bytes/sec)
#

И снова в top:

Mem: 28M Active, 380M Inact, 66M Laundry, 30G Wired, 441M Free
ARC: 13G Total, 4290M MFU, 7965M MRU, 2784K Anon, 54M Header, 1142M Other
11G Compressed, 12G Uncompressed, 1.05:1 Ratio

Не-а, нифига.

По поводу "здутия" и Вашей

По поводу "здутия" и Вашей статистики мне подумалось, а будет ли увеличиваться arc после сдутия, если прочитать в null/zero какой-то объём гарантированно ранее не читаемый?

Ну, было 98.9% когда-то. В 11

Ну, было 98.9% когда-то. В 11.0 :-)

Всю мою метадату можно прочесть на старте сервера в память

Когда-то я пытался это делать. Хотел проверить идею и узнать какой объем у метадаты на реальном сервере. Сейчас уже точно не помню и могу ошибаться. Где-то у миллиона файлов (каталогов не считал, но много, общий объём был около 4TB) помнится видел 9GB сжатых (сжатие было до 25 раз). Не уверен, что мне удалось тогда прочитать/удержать всю метадату и наверняка в каждом конкретном случае будут свои результаты. Удержание оказалось самой большой проблемой и из коробки её не решить (по крайней мере мне не удалось и пришлось лезть внутрь).
У Вас же очень хорошая статистика (даже если чуть и подвирает) или хотите ещё лучше :-) ?

Всю мою метадату можно

Всю мою метадату можно прочесть на старте сервера в память по хорошему. Там немного по отношению к объёмы самой даты.

К сожалению, данные о точках

К сожалению, данные о точках фокусировки
- различаются от вендора к вендору
- различаются от камеры к камере
- могут, вероятно, меняться с версией firmware
- и не документированы толком.

Поскольку мы заявляем поддержку большого количества камер - нам надо разобраться в этом месте у заметной их части.

Мы работаем над этим, но быстрого результата не ждите.

У Никона есть информация о

У Никона есть информация о том, как интерпретировать соответствующую метадату. У нас есть только догадки. Отсюда возникает неприятная возможность неверной индикации. Неверная индикация, в свою очередь, может привести к реальным проблемам - например, к тому, что человек сочтет, что его камера сфокусировалась не на ту точку из-за какой-то неисправности.

Кроме того, по моему скромному мнению, информация о точке фокусировки малополезна и не стоит затраченного труда. То, что хотелось иметь в резкости - или в ней, или вне нее.

а можно ли добавить точку фокусировки

можно ли показывать (опционально) точку фокусировки для камер где это возможно? например viewnx-i такое делает на никонах.

запускать его все равно

запускать его все равно всегда - ибо CaptureOne.exe должен получить raw из FRV ...

Как мне кажется так универсальнее

@ECHO OFF
Set ProcessName=CaptureOne.exe

TaskList /FI "ImageName EQ %ProcessName%" | Find /I "%ProcessName%">nul

IF %ERRORLEVEL% NEQ 0 (
rem ECHO %ProcessName% is not running
******************************* Запускаем....
)
) else (
rem ECHO %ProcessName% is running
******************************* Активирум...
)
)

снижает время отклика.

увеличивает :-)

IOPSы тоже ж волнуют?

По умолчанию сейчас indirect block pointers 128k. Любой промах в arc-е влечёт за собой обращение к дискам. indirect block pointers по умолчанию имеет по 2-3 разнесённые копии. Если во время чтения будет выбран далекостоящий, то получим ещё и дополнительное перемещение головок. Соотношение запросов 2:1 (довольно малое соотношение, наверно преобладает recordsize=1M, у меня соотношение значительно больше, да и статистика показывает что arc хорошо справляется с данным патерном) всё равно говорит, что желательно чтобы как можно больше метаданных читалось из arc-а (в идеале все :-)). Например для самба сервера, если клиенты имеют на своей стороне много оперативной памяти, то лучше не увлекаться кешированием данных с двух сторон, а больше внимания уделить кешированию метаданных. О которых клиент ничего не знает и дисковое обращение к которым снижает время отклика.

IOPSы тоже ж волнуют?

IOPSы тоже ж волнуют?

На размеры запросов домножьте.

А как это влияет на хитрейт arc-а о котором Вы говорили?

На размеры запросов домножьте

На размеры запросов домножьте.

Меня волнует трансфер с блинов а не штуки, конечно же.

Сколько метаданных у 100 файлов по сравнению с 20 гигабайтами са

Ваш arc получил по данным 2.10b + 24.01m + 95.41m + 120.25m запросов, а по метаданным 4.19b + 14.16m + 76.04m + 2.87m запросов. Получается в два раза больше по метаданным. Так причём здесь размер файлов?

Сколько метаданных у 100

Сколько метаданных у 100 файлов по сравнению с 20 гигабайтами самих файлов?

# zfs-stats -E

------------------------------------------------------------------------
ZFS Subsystem Report Sun May 12 19:27:24 2019
------------------------------------------------------------------------

ARC Efficiency: 6.62b
Cache Hit Ratio: 95.55% 6.33b
Cache Miss Ratio: 4.45% 294.58m
Actual Hit Ratio: 95.24% 6.31b

Data Demand Efficiency: 95.65% 2.19b
Data Prefetch Efficiency: 16.64% 144.26m

CACHE HITS BY CACHE LIST:
Most Recently Used: 16.17% 1.02b
Most Frequently Used: 83.50% 5.28b
Most Recently Used Ghost: 0.09% 5.71m
Most Frequently Used Ghost: 0.32% 20.43m

CACHE HITS BY DATA TYPE:
Demand Data: 33.13% 2.10b
Prefetch Data: 0.38% 24.01m
Demand Metadata: 66.27% 4.19b
Prefetch Metadata: 0.22% 14.16m

CACHE MISSES BY DATA TYPE:
Demand Data: 32.39% 95.41m
Prefetch Data: 40.82% 120.25m
Demand Metadata: 25.81% 76.04m
Prefetch Metadata: 0.98% 2.87m

------------------------------------------------------------------------

#

Покажите zfs-stats -E

Покажите zfs-stats -E

где нет файлов меньше 500 мегабайт?

При чём здесь размер файла? На том сервере с которого я показывал статистику тоже нет мелких файлов. Сидят операторы с дизайнерами и ежедневно ворочают приходящие большие файлы для цифровой печати. Сжимаются не файлы, а блоки. zfs это дерево и данные находятся в его листьях (на самом нижнем уровне), а чтобы получить к ним доступ нужно пройти все блоки по пути вниз.

или вот даже универсальнее

или вот даже универсальнее

nircmd.exe" win activate process "CaptureOne.exe"
nircmd.exe" win max process "CaptureOne.exe"

чтобы искало по имени executable

Много ли у меня в кэше

Много ли у меня в кэше метаданных при том, что 95% нагрузки на сервер — 50 активных торрент-раздач, где нет файлов меньше 500 мегабайт? Т.е. 95% ARC'а — это данные условно 30-50 файлов которые сейчас активно раздаются.

А, ну тогда это моей статистики точно не касается

Вам это только кажется ;-). В основном так жмутся только метаданные, а они жмутся всегда и независимо от установок пользователя.

А, ну тогда это моей

А, ну тогда это моей статистики точно не касается, у меня там нет ничего сжимаемого и ничего мелкого.

нагуглил https://www.nirsoft

нагуглил https://www.nirsoft.net/utils/nircmd.html , буду теперь командный фай запускать с

nircmd.exe win activate title "Untitled Session"
nircmd.exe win max title "Untitled Session"
C:\Program Files\Phase One\Capture One 12\CaptureOne.exe %1

Pages

Subscribe to comments_recent_new