Я на сублайм перешел с notepad++ и в нем, хотя и кривой и не особо стабильный, но был плагин functionlist. Да, первое время и довольно продолжительное, без списка функций в боковой панельке в сублайме было очень тяжело.
Но однажды я привык, а поиск (ctrl/command + R) стал казаться удобным, и я уже несколько лет не испытываю дискомфорта в этой области или неудобств.
Опять же — никто не мешает написать плагин, который будет это все делать. Меня все еще удивляет, что его не написали, но, на сколько я понимаю, написать его — легко.
По ссылке http://forum.vseoglazah.ru/showthread.php?t=16015 и дальше в обсуждениях есть упоминания статей и конкретных случаев, из которых вроде как следует, что у смайла есть проблемы с центровкой и это реально приводит к проблемам, причем не так, чтобы совсем в единичных случаях.
В частности,
Исходя из анализа данных FDA, обе методики демонстрируют сравнимый высокий уровень эффективности, однако методика LASIK T-CAT Contoura Vision™ демонстрирует больший процент остроты зрения ≥ 1.00, при этом крайне важно отметить, что более половины прооперированных глаз методикой LASIK T-CAT Contoura Vision™ имели астигматизм более -0.5 дптр, а в 15% величина астигматизма превышала даже более -2,00 дптр. Астигматизм является явным осложняющим фактором при проведении кераторефракционной хирургии, и только его практически полное отсутствие в группе исследования позволило методике ReLEx SMILE показать сравнимые по эффективности результаты лечения по сравнению с методикой LASIK T-CAT Contoura Vision™. Отмечена также более высокая острота зрения при коррекции миопии высокой степени методикой LASIK T-CAT Contoura Vision™, хотя именно этот фактор позиционируется разработчиками, как преимущество методики ReLEx SMILE, что, как видно из данных материалов FDA, не соответствует действительности.
Понятно, что результаты слегка зависят от прямых рук опыта конкретного врача и нельзя упомянутые там исследования просто так отмасштабировать на весь мир, но все же — на сколько это действительно так в России в хороших клиниках (это, из известных в интернете — ваша, 3з и МНТК «Микрохирургия глаза») ?
Не появилось ли уже сейчас способов контролировать центровку при смайле?
Нет ли причин выбрать фемтоласик, если хочется гарантированно минимизировать вероятность проблем?
Вот этот абзац очень сильно заставляет задуматься. При этом (я посмотрел в оригинал) статья свежая — написана в 2016.
Результаты: Через 3 месяца 86,4% группы LASIK и 68,2% группы SMILE имели UDVA 1,00 (P <0,002) и 59,1% и 31,8%, соответственно, имели UDVA 1,25 (P <. 002) [Различие в зоне значимости, иначе говоря – различие статистически достоверно]. Сфероэквивалент рефракции в ± 0,50 D [т.н. «золотой коридор» послеоперационной рефракции] составил 95,5% для группы LASIK и 77,3% для группы SMILE (P <0,002) [Различие в зоне значимости, иначе говоря – различие статистически достоверно]. Остаточный астигматизм ≤ 0,25 дптр составлял 81,8% для группы LASIK и 50% для группы SMILE (P <0,001) [Удобнее эту мысль можно было бы сформулировать так: Остаточный астигматизм > 0,50 дптр составлял 18,2% для группы LASIK и 50% для группы SMILE. И здесь также мы видим различие в зоне значимости, иначе говоря – различие статистически достоверно]. Контрастная чувствительность (6 цикл / град) составляла 7,2 ± 1,01 в группе LASIK и 6,20 ± 1,52 в группе SMILE [Различие в зоне незначимости]. Измерения индекса объективного рассеяния OSI через 3 месяца составляли 1,35 в группе LASIK и 1,42 в группе SMILE [Различие в зоне незначимости]. Выводы: топографически-ориентированный LASIK, продемонстрировал более высокие показатели во всех изученных параметрах характеристик зрения, как субъективных, так и объективных. Основное различие между этими двумя методами, вероятно, происходит от наличия системы трекинга, контроля циклоторсии и активного контроля центрации в технологии LASIK, в отличие от их отсутствия в существующей технологии SMILE. Это различие влияет на конечные результаты лечения, как в рефракционном плане, так и в плане зрительных функций.
Тогда придется делать еще bcache/flashcache. Но это, возможно, и лучше — кеш будет оставаться между ребутами. Вот только их новые версии с OpenVZ не совместимы :(
насколько я знаю, такая схема невозможна (ZFS у вас на стороне NAS).
Идея была — на NAS сделать ZVOL, его отдать по iSCSI, на клиенте это будет блочное устройство, на которое можно сделать ZFS со стороны клиента, и тогда, вроде бы, к ZFS должно быть можно сделать l2arc и ZIL. Или я неправильно думаю?
Тут критично, каким блоком будет записывать эти файлы ext4, плюс сжатие поможет компенсировать эту проблему.
Миллионы мелких файлов делятся на два типа — часть из них создается одномоментно — в момент разворачивания дистрибутива Битрикса. Если писать их на диск не сразу, то — наверное запись как-то агрегируется и они будут писаться блоками по 16к? Я ведь правильно думаю, что в одном блоке может быть больше одного файла?
Второй тип мелких файлов — кеш битрикса. Он не дедуплицируем, но сжимаем. Но многие файлы вообще по 200 байт. Вот тут мы сможем, видимо, получить большой выигрыш, если откажемся от ext4 — на чистом зфс вроде бы можно для отдельных каталогов дедупликацию отключить и поэкономить память.
И еще вопрос про iSCSI (btw, спасибо вам огромное, что отвечаете здесь на вопросы)
Сценарий — очень много мелких файлов, которые постоянно используются + много больших архивов, которые один раз пишутся (скорость, с которой они пишутся, не имеет значения) и часто больше даже не читаются. Хочется скорость (SSD) и сэкономить денег. Таких серверов много.
Будет ли хорошим такое решение:
Сделать один отдельный NAS с обычными 3.5 дисками (+ arc побольше и l2arc какой-то), подцеплять его по iSCSI на рабочий сервер по гигабитной(!) сети (помним — хочется сэкономить, а скорость работы с большими файлами не важна), а на рабочих серверах поставить SSD под l2arc, размером как все мелкие файлы для этого сервера + какой-то запас?
Правильно ли я думаю, что в этом случае все данные будут в локальном l2arc и скорость работы с ними будет такая же, как если бы они были на локальном диске?
Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?
Вопрос был про является ли рекордсайз блоксайзом, но я увидел
# zfs get all | grep -i size
vzpool recordsize 128K default
vzpool/vz3 volsize 423G local
vzpool/vz3 volblocksize 16K -
Т.е. правильно ли я понимаю, что это разные вещи, и если у меня маленький средний размер файла, то мне лучше уменьшать именно recordsize ?
А на что тогда влияет volblocksize? Т.е. я понимаю, что это минимальная перезаписываемая порция данных и помню, что COW, но теперь не понимаю как вообще надо выбирать volblocksize и в зависимости от чего.
И заодним, если SSD и я очень хочу иметь много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска, чем данных — можно ли как-то управлять количеством старых копий, чтобы их было поменьше? И, например, если мне не нужны снапшоты совсем — можно ли их отключить и что-нибудь сэкономить на этом?
если ext4 на 480гб SSD диске, то доступно 440 гигабайт (16к на иноду)
если ext4 на 480гб SSD диске, то доступно 419 гигабайт (4к на иноду)
если просто ZFS то 430 гигабайт
если ext4 на ZVOL — 398 гигабайт (blocksize=4k)
если ext4 на ZVOL — 417 гигабайт (blocksize=16k)
Но — размер блока ext4 и размер инода — разные вещи.
В тесте у ext4 везде размер блока оставлен по умолчанию ( -b 4096 ). В случае с ZVOL при блоксайзе 4к это 398 гигабайт вместо 440.
А вот если сделать блоксайз равный размеру инода (16к) — тогда да, получаем 417 гигабайт ext4 на zvol против 440 у ext4 без zfs, что лучше, но все равно — вы выше утверждали
место не должно съедаться больше, чем без zfs
а судя по тестам — это не так и без ZFS места намного больше.
Учитывая, что у меня SSD — вряд ли можно получить какую-то разницу в скорости работы при разных размерах чего угодно, по крайней мере на чтение. По этому, помня, что я хочу дефрагментацию и у 65% файлов размер менее 1 килобайта — разве не логичнее использовать более маленький volblocksize?
Да, я уже увидел. Я больше про то, что в начале это кажется проблемой, но на самом деле нет, хотя в это сложно поверить.
Не смог пройти мимо и не прокомментировать.
Я на сублайм перешел с notepad++ и в нем, хотя и кривой и не особо стабильный, но был плагин functionlist. Да, первое время и довольно продолжительное, без списка функций в боковой панельке в сублайме было очень тяжело.
Но однажды я привык, а поиск (ctrl/command + R) стал казаться удобным, и я уже несколько лет не испытываю дискомфорта в этой области или неудобств.
Опять же — никто не мешает написать плагин, который будет это все делать. Меня все еще удивляет, что его не написали, но, на сколько я понимаю, написать его — легко.
2017 год.
Чтобы tig показывал utf нужны какие-то невероятные танцы с бубнами, причем применить несколько первых ответов из гугла оказалось недостаточно...
а почему все вешается на tcp сокеты? Как быть тем, кто очень хочет экономить и использовать unix сокеты?
Написано то написано, да не работает :(
(по состоянию на месяца 3-4 назад)
А расскажите, вы смогли заставить rclone работать с B2 под линукс?
Кроме B2 есть тарифы для дома, а Amazon Glacier по факту — много дороже. И, кстати, был заметно медленнее, когда я проверял.
Backblaze очень хороши, кроме того, что нет бизнес плана для серверов на линуксе (и вообще, кажется, ничего реально работающего под линукс).
Но при этом она сейчас не контролируется в процессе, но с хорошим опытом и прямыми руками это статистически не проблема, я правильно понимаю?
ок, это понятно. Но главный вопрос — есть ли сейчас возможность инструментального контроля точности центровки при захвате глаза?
По ссылке http://forum.vseoglazah.ru/showthread.php?t=16015 и дальше в обсуждениях есть упоминания статей и конкретных случаев, из которых вроде как следует, что у смайла есть проблемы с центровкой и это реально приводит к проблемам, причем не так, чтобы совсем в единичных случаях.
В частности,
Понятно, что результаты слегка зависят от
прямых рукопыта конкретного врача и нельзя упомянутые там исследования просто так отмасштабировать на весь мир, но все же — на сколько это действительно так в России в хороших клиниках (это, из известных в интернете — ваша, 3з и МНТК «Микрохирургия глаза») ?Не появилось ли уже сейчас способов контролировать центровку при смайле?
Нет ли причин выбрать фемтоласик, если хочется гарантированно минимизировать вероятность проблем?
Вот этот абзац очень сильно заставляет задуматься. При этом (я посмотрел в оригинал) статья свежая — написана в 2016.
Чуть менее 10 лет использую мультимастер между разными ДЦ. Никогда не испытывал проблем.
not true.
1) если он учредитель, при этом единственный — с ним можно не заключать трудового договора.
2) директором может быть другое юр.лицо или ИП.
Тогда придется делать еще bcache/flashcache. Но это, возможно, и лучше — кеш будет оставаться между ребутами. Вот только их новые версии с OpenVZ не совместимы :(
Да с радостью бы, но у нас еще и OpenVZ, который жестко привязан...
У нас на каждом диске их несколько сотен.
Мы сейчас используем бекапы с LZ4 и дедупликацией (borgbackup) — там просто фантастические цифры по сжатию, очень впечатляет.
Идея была — на NAS сделать ZVOL, его отдать по iSCSI, на клиенте это будет блочное устройство, на которое можно сделать ZFS со стороны клиента, и тогда, вроде бы, к ZFS должно быть можно сделать l2arc и ZIL. Или я неправильно думаю?
Миллионы мелких файлов делятся на два типа — часть из них создается одномоментно — в момент разворачивания дистрибутива Битрикса. Если писать их на диск не сразу, то — наверное запись как-то агрегируется и они будут писаться блоками по 16к? Я ведь правильно думаю, что в одном блоке может быть больше одного файла?
Второй тип мелких файлов — кеш битрикса. Он не дедуплицируем, но сжимаем. Но многие файлы вообще по 200 байт. Вот тут мы сможем, видимо, получить большой выигрыш, если откажемся от ext4 — на чистом зфс вроде бы можно для отдельных каталогов дедупликацию отключить и поэкономить память.
И еще вопрос про iSCSI (btw, спасибо вам огромное, что отвечаете здесь на вопросы)
Сценарий — очень много мелких файлов, которые постоянно используются + много больших архивов, которые один раз пишутся (скорость, с которой они пишутся, не имеет значения) и часто больше даже не читаются. Хочется скорость (SSD) и сэкономить денег. Таких серверов много.
Будет ли хорошим такое решение:
Сделать один отдельный NAS с обычными 3.5 дисками (+ arc побольше и l2arc какой-то), подцеплять его по iSCSI на рабочий сервер по гигабитной(!) сети (помним — хочется сэкономить, а скорость работы с большими файлами не важна), а на рабочих серверах поставить SSD под l2arc, размером как все мелкие файлы для этого сервера + какой-то запас?
Правильно ли я думаю, что в этом случае все данные будут в локальном l2arc и скорость работы с ними будет такая же, как если бы они были на локальном диске?
Будет ли оставаться l2arc кеш между рестартами сервера? ZOL последней версии. Если не будет, то будет ли в следующей 0.7 ?
Вопрос был про является ли рекордсайз блоксайзом, но я увидел
Т.е. правильно ли я понимаю, что это разные вещи, и если у меня маленький средний размер файла, то мне лучше уменьшать именно recordsize ?
А на что тогда влияет volblocksize? Т.е. я понимаю, что это минимальная перезаписываемая порция данных и помню, что COW, но теперь не понимаю как вообще надо выбирать volblocksize и в зависимости от чего.
И заодним, если SSD и я очень хочу иметь много заранее очищенных блоков (и часто запускаю fstrim), а из-за COW у меня будет занято сильно больше блоков диска, чем данных — можно ли как-то управлять количеством старых копий, чтобы их было поменьше? И, например, если мне не нужны снапшоты совсем — можно ли их отключить и что-нибудь сэкономить на этом?
Если я не указываю ashift (ashift=0) то zfs сам выбирает ashift=9.
Да, с размером блока недоработка была, поправил https://gist.github.com/knutov/453fa860e4f574ac01413273cf79392f
Но — размер блока ext4 и размер инода — разные вещи.
В тесте у ext4 везде размер блока оставлен по умолчанию ( -b 4096 ). В случае с ZVOL при блоксайзе 4к это 398 гигабайт вместо 440.
А вот если сделать блоксайз равный размеру инода (16к) — тогда да, получаем 417 гигабайт ext4 на zvol против 440 у ext4 без zfs, что лучше, но все равно — вы выше утверждали
а судя по тестам — это не так и без ZFS места намного больше.
Учитывая, что у меня SSD — вряд ли можно получить какую-то разницу в скорости работы при разных размерах чего угодно, по крайней мере на чтение. По этому, помня, что я хочу дефрагментацию и у 65% файлов размер менее 1 килобайта — разве не логичнее использовать более маленький volblocksize?