Свежие комментарии
| Title | Comment |
|---|---|
| (я понимаю, ты получил это от |
(я понимаю, ты получил это от гитхаба, но для протокола) issue похоже repeatable: просто при повторном пере-чтении 32GB файлов (влезают в ARC) - я вижу ~460MB/sec. А не пару гигабайт, как ожидал бы. Надо заводить freebsd issue. Ну то есть я завтра обновлюсь до 12-stable свежей и повторю еще раз-другой. |
| Ну, гм. |
Ну, гм. Я, надо сказать, разнеся файлер и "остальной сервер" - всерьез подумываю а не посмотреть ли на Windows Server в качестве файлера. Когда изведу дома совсем старые макоси (которые не умеют тайм машину на SMB) - задумаюсь еще серьезнее. |
| Спасибо в любом случае! |
Спасибо в любом случае! Make ZFS on FreeBSD great again! |
| Блин. Ну я же сам - |
Блин. Ну я же сам - разработчик и понимаю как писать issue. issue должна быть repeatable. А пока я имею "у меня тут в подполе застучало, я сделал вот так, продолжаю наблюдения". https://github.com/zfsonlinux/zfs/issues/7896#issuecomment-491919238 Если оно повторится (с выключенной компрессией) - одна история. Не повторится - другая. |
| Давай заведём issue во |
Давай заведём issue во FreeBSD (в багзилле) и просто я дам ссылку там на него. И, главное, дам ссылку Алану Джуду, который один из рулителей и идеологов OpenZFS и при этом во FreeBSD, а не где-то ещё. |
| Ну хорошо, у тебя нет проблем |
Ну хорошо, у тебя нет проблем с ZoL, но у тебя есть явно паталогичский случай с FreeBSD ZFS, который достоин что бы быть багрепортом. Давай заведём багрепорт во FreeBSD'шной багзилле. (и зачем я в эту политику ввязался, вечно хочешь как лучша, а....) |
| Ну, ок. Ну то есть я не вижу |
Ну, ок. Ну то есть я не вижу как бы я мог создать issue на то, чем не пользуюсь. Но я уж как минимум напишу что это не вполне low end CPU |
| Будет общая code base для |
Будет общая code base для всех систем. И она живёт вот в этом репозитории, который исторически называется ZoL. Раньше такая общая codebase жила в Illumos'е, но теперь — здесь. Для Linux, для BSD, для MacOS X, для Windows (да, для Windows) — для всех. |
| Это больше не ZoL, это |
Это больше не ZoL, это OpenZFS теперь, и он будет в FreeBSD через пол-года. А тогда будет поздно. Я правда не понимаю, в чём проблема. |
| Ну и я не буду. Потому что у |
Ну и я не буду. Потому что у меня нет issue ZoL |
| В переписке про compressed |
В переписке про compressed arc, от Алана Джуда, который как раз может иметь большой вес в решении таких вопросов: > I am not sure we want to maintain that extra code complexity just to Как я и говорил — нужны точные подробности. Видимо, сами они тебе писать не будут (и я могу их понять, если честно). |
| Я пользы как фотограф не вижу |
Я пользы как фотограф не вижу ;) |
| Илья, мне кажется всегда |
Илья, мне кажется всегда можно расписать функцию как "экспериментальную", но дать возможность ей пользоваться там, где это возможно. программы тоже не пишутся без багов, тем не менее они правятся и бывает правятся по отзывам самих пользователей. по поводу полезности информации: возможно вы как разработчик не видите пользы от этого, но мне было бы интересно увидеть что цветок выпал из "грип" по причине, например фокуса на мдф. как разработчику я могу конечно вам доверять что эта функция потребует у вас N-ого кол-ча человека дней, но готов поспорить с малополезностью "оной". может есть где голосовалка за "хотелки от народа"? тем не менее, за продукт - спасибо |
| большое спасибо за надежду. |
большое спасибо за надежду. будем ждать :) |
| А давайте проверим! Лёгкий же |
А давайте проверим! Лёгкий же эксперимент. Вот сейчас: Mem: 30M Active, 380M Inact, 64M Laundry, 30G Wired, 445M Free Читаем файл на G который не в торрентах: # dd if=Paris-Roubaix\ 2016\ \[FULL\ RACE]_720.mp4 of=/dev/null bs=128k Смотрим в top: Mem: 28M Active, 380M Inact, 67M Laundry, 30G Wired, 441M Free читаем ещё раз: # dd if=Paris-Roubaix\ 2016\ \[FULL\ RACE]_720.mp4 of=/dev/null bs=128k И снова в top: Mem: 28M Active, 380M Inact, 66M Laundry, 30G Wired, 441M Free Не-а, нифига. |
| По поводу "здутия" и Вашей |
По поводу "здутия" и Вашей статистики мне подумалось, а будет ли увеличиваться arc после сдутия, если прочитать в null/zero какой-то объём гарантированно ранее не читаемый? |
| Ну, было 98.9% когда-то. В 11 |
Ну, было 98.9% когда-то. В 11.0 :-) |
| Всю мою метадату можно прочесть на старте сервера в память |
Когда-то я пытался это делать. Хотел проверить идею и узнать какой объем у метадаты на реальном сервере. Сейчас уже точно не помню и могу ошибаться. Где-то у миллиона файлов (каталогов не считал, но много, общий объём был около 4TB) помнится видел 9GB сжатых (сжатие было до 25 раз). Не уверен, что мне удалось тогда прочитать/удержать всю метадату и наверняка в каждом конкретном случае будут свои результаты. Удержание оказалось самой большой проблемой и из коробки её не решить (по крайней мере мне не удалось и пришлось лезть внутрь). |
| Всю мою метадату можно |
Всю мою метадату можно прочесть на старте сервера в память по хорошему. Там немного по отношению к объёмы самой даты. |
| К сожалению, данные о точках |
К сожалению, данные о точках фокусировки Поскольку мы заявляем поддержку большого количества камер - нам надо разобраться в этом месте у заметной их части. Мы работаем над этим, но быстрого результата не ждите. |
| У Никона есть информация о |
У Никона есть информация о том, как интерпретировать соответствующую метадату. У нас есть только догадки. Отсюда возникает неприятная возможность неверной индикации. Неверная индикация, в свою очередь, может привести к реальным проблемам - например, к тому, что человек сочтет, что его камера сфокусировалась не на ту точку из-за какой-то неисправности. Кроме того, по моему скромному мнению, информация о точке фокусировки малополезна и не стоит затраченного труда. То, что хотелось иметь в резкости - или в ней, или вне нее. |
| а можно ли добавить точку фокусировки |
можно ли показывать (опционально) точку фокусировки для камер где это возможно? например viewnx-i такое делает на никонах. |
| запускать его все равно |
запускать его все равно всегда - ибо CaptureOne.exe должен получить raw из FRV ... |
| Как мне кажется так универсальнее |
@ECHO OFF TaskList /FI "ImageName EQ %ProcessName%" | Find /I "%ProcessName%">nul IF %ERRORLEVEL% NEQ 0 ( |
| снижает время отклика. |
увеличивает :-) |
| 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 запросов. Получается в два раза больше по метаданным. Так причём здесь размер файлов? |
Pages
