Свежие комментарии
Title | Comment |
---|---|
только метадату на них отправлю |
Метадату я стараюсь держать всю в арке и что бы она оттуда не уходила вообще. Ради интереса проверь какой объём она занимает в арке для всех твоих данных в пуле (без сжатия и с ним). Думаю не пожалеешь :-). |
Я на бэкапный пул поставил |
Я на бэкапный пул поставил запиливаться два старых OCZ Vertex. Выкинуть жалко, использовать невозможно, пусть падут смертью храбрых уж, заодно посмотрим, сколько это займет. |
наплевал на вымывание ARC |
В принципе для файлового сервера здравая мысль. Всегда в процессе возникают не очень подходящие задачи для арка, то кто-то запустит поиск на 300000 файлах, то кому-то нужно перенести большой объём в другое место... Для самба сервера при настройке арка и пула (в моём понимании) важно при запросе стараться не тратить время на чтение метаданных с дисков и максимально быстро читать нужный блок данных файла из пула. |
Я не вижу ручек для |
Я не вижу ручек для согласования без общего ухудшения всего, самба то тоже общая (как и ARC). Нужно, наверное, играть recordsize на бэкапном пуле. Но я вспоминаю, что года 2 или 3 назад я во все это уже играл - и в результате наплевал на вымывание ARC, так оказалось проще всего. |
primarycache=metadata |
Если несколько пулов на общий арк и внеший бэкап по самбе тогда конечно имеет смысл. А чтение (верификация) по самбе с primarycache=metadata думаю для приемлемой скорости нужно хорошо согласовать с чтением из пула. |
Ну меня primarycache=metadata |
Ну меня primarycache=metadata сильно спасло от вымывания ARC (ARC перестал пухнуть с первым же бэкапом - они у меня на отдельный Zpool), но общий результат получился огорчительным, backup verify стал идти в разы дольше. |
если правильно помню |
Если правильно помню :-), recordsize не соответствует размеру блока передачи по smb. На всякий случай, как-то недавно обнаружил, что primarycache=metadata (и даже none) при send/recieve не спасает от вымывания арка. |
А я опять вляпался в |
А я опять вляпался в primarycache=metadata (+, если правильно помню, prefetch и/или большой recordsize). Было опять смешно - 400Mb/s с дисков и меньше 100 уходит в сеть. |
Так ее и нет, либо @mouse, |
Так ее и нет, либо @mouse, либо "сохраняем центр пока можем" (но вовсе не левое/правое ухо) |
> Никакой "памяти" |
> Никакой "памяти" ну вот о чем собственно и писалось в самом начале |
Zoom in/out в этом случае |
Zoom in/out в этом случае сохраняют центр "пока это возможно". Т.е. если уменьшили картинку до fit to screen или меньше, то и уменьшили. Никакой "памяти" о том, что было больше одного шага назад - нету. |
спешу разочаровать... при |
спешу разочаровать... при отмене "Zoom anchor at mouse cursor" поведение ес-но меняется но не принципиально... т.е. zoom out - zoom in в общем случае не восстанавливят исходного кадрирования с которого начался zoom out |
поди ж перед носом была и не |
поди ж перед носом была и не увидел ... пора таки к окулисту |
Вроде ростелеком умеет (но |
Вроде ростелеком умеет (но наверное нужна настройка и вашего оконечного оборудования тоже) |
Вообще, стандартная настройка |
Вообще, стандартная настройка: "Zoom anchor at mouse cursor" - checked. Не в ней ли дело, например? |
а то сейчас вообще странное.. |
а то сейчас вообще странное... смотрю на свое левое иухо.. zооm out - zoom in ... смотрю на свое правое ухо... |
вброшу... при уменьшении зума |
вброшу... при уменьшении зума (zoom out) и обратном увеличении зума (zoom in до исходного состояния) позиция... как бы это на русском сказать... короче кусок кадра который был виден на экране до этого туда-сюда-обратно в общем случае не сохраняется - это не баг ес-но, а фича... а можно ли малой кровью увеличивая обратно (опционально) восстанавливать именно то что было видно при значениях зума больше того при котом вся картинка целиком видна ? |
Попробовал проверить, |
Попробовал проверить, показывает что не поддерживает у меня IPv6. Ростелеком, урал |
метаданные |
Похоже я когда-то пропустил и метаданные теперь по умолчанию жмутся на диске независимо от установок датасета. |
Я на этой коробочке сегодня, |
Я на этой коробочке сегодня, к примеру, Libraw собирал-тестировал и тп. Т.е. я хотел именно полноценный PC |
Завелось без проблем, голая |
Завелось без проблем, голая фри. Вифи нету, но есть M.2 разъем под нее (но в этом месте та проблема, что M.2 WiFi и FreeBSD - ну надо читать/искать что поддерживается). Ссылка на конкретно то что я купил вот (она же есть и в последней строчке постинга): https://ru.aliexpress.com/item/Eglobal-6-Intel-Lans-Fanless-X86-Mini-PC-... Но вообще у китайцев мульены таких. |
upd к опубликованному |
В наших деревнях выглядит так: Какой "родной" pfsense, всё готово сразу: https://www.reichelt.com/ch/de/open-source-router-turris-omnia-2-gb-wlan... 313 Куды податься? |
Есть пара вопросов |
Приветствую. Тянет-тянет мой некротик домашний сменить на что-то посовременнее, ибо что-то он гигабит не вытягивает на аплоад, и файфай несколько староват. Я писал тут в каментах про попытку построить роутер на делл оптиплекс и две 4-ёх портовых карты. Плохо оказалось. Шумно, и не на всяком железе так вот запросто. Отсель вопрос. а) Завелось? Спасибо. |
Ну не OpenGL, это WebGL со |
Ну не OpenGL, это WebGL со своими чудовищными тараканами. |
Не, нету, надо пихать в |
Не, нету, надо пихать в профайлер и смотреть где тормоза. Но evaluation - весь многотредный механизм переделывать (на, к примеру, TBB) |
Ну вот хрен пойми. Медленный |
Ну вот хрен пойми. Медленный очень между-thread-ный IPC (signal-slot, естественно). |
Если есть разговор о |
Если есть разговор о модификации, без которой работать не будет -- можно предположить, что есть evaluation. |
вообще да, WebGL же есть |
вообще да, WebGL же есть |
«которую по переписке не |
«которую по переписке не решили.» |
Я тебе больше скажу — OpenGL |
Я тебе больше скажу — OpenGL доступен из Электрона. Прямо в JS. Как ты думаешь Unity в браузере работает? |