лучшим решением было бы расположение основного монитора всегда в landscape, а второго — в портретном,
тогда ничего вертеть не надо.
вопрос в том, будет ли удобно работать изображением с таким разбросом по ширине и хватит ли свободного места на столе =) если ответы утвердительные, я бы выбрал этот вариант.
есть далеко не везде, обычно положение монитора знает только сам монитор, и никуда его не передаёт.
просто, проблема-то больше в удобстве. нужно не просто повернуть, а ещё отодвинуть второй моник куда-то (ведь первый стал шире), передвинуть первый, настроить под себя заново. ещё при повороте изображения на основном мониторе похерится расположение иконок и окон.
в общем стоя в гамаке можно заниматься сексом, но зачем?
так точно, win7 в курсе.
при переносе я вам расписал: переносите акронисом как есть, затем берёте paragon alingment tool или любой из множества аналогов от производителя винта или сторонних разработчиков и выравниваете этой утилитой разделы (она по сути сама всё делает, одну кнопку запуска только надо нажать). после этого потери производительности из-за невыравненных разделов не будет.
но и в этом случае винчестер будет достаточно медленнее, чем «нормальный». именно поэтому я всё же рекомендовал бы посмотреть в сторону 512-секторных экземпляров. пусть для ноутбука винт будет поменьше, но без этих извращений, мне кажется. на десктопе же использование advanced format смысла не имеет абсолютно никакого и попахивает ненормальщиной =)
поиграю в капитана:
потому что технология ещё только появилась.
ос должна уметь выравнивать партиции по границе 4к.
если выравнивать, то производительность всё равно существенно ниже, чем у обычных винтов. там и транслятор там и сам по себе слабенький, и необходимость трансляции секторов тоже как бы не ускоряет =)
если не выравнивать, то производительность умирает в ноль.
консоль естественно будет тормозить процесс вывода, зачем с ней экспериментировать?
если, как вы говорите, тормоза не привязаны к PHP, мучайте apache, напрямую отдающий файл нужного размера. проследите зависимость от размера (так поймёте — сеть виновата или буферизация). копайте в сторону буферов вебсервера, если ни к чему не приведёт, то в сторону буферов ос.
Ну так а что вы хотите от NTFS =)
Если хотите именно расшаривать одно хранилище между несколькими подключениями, то либо ставите на него кластерную ФС (glusterfs, zfs итд), либо монтируете его куда-нибудь в одну точку и с неё раздаёте по NFS.
по вашим уточнениям: либо ваш внутренний сервер должен возвращать в хтмле относительные пути — тогда проблема уйдёт сама, либо (если код там недоступен для правок) можно воспользоваться модулем замены в nginx.
вариант проверки номер два, яйца те же, вид другой: делаете из консоли insert этого самого умляута (копипастнув его) в базу. после чего вы делаете select и медитируете на результат =)
мистика. похоже, в базе не совсем то, что вы думаете там лежит =)
решающий тест: делаете селект и вывод на экран из консольного php, перенаправляете вывод в файл. смотрите что там. подкладываете этот текстовый файл туда где его можно запросить браузером и собственно запрашиваете. смотрите что получилось.
подозреваю, что в первом случае у вас будет два символа, а во втором один умляут.
pdf утверждает, что диски на SLC чипах — не будет проблем с любым контроллером/осью.
если свободное место не очень важно, то я бы всё же понадеялся, что контроллер в дисках достаточно новый для умного wear leveling'а и оставил неразмеченным ~%10 объёма накопителей.
raid 60 — надёжнее (я бы всё-таки выбрал этот вариант)
raid 10 — быстрее (в данном случае по большей части зависит от производительности контроллера)
по дисковому пространству потери на избыточность будут одинаковые.
по поводу работы с дисками.
1. если у вас аналоги Intel X25-E (подозреваю, что это скорее всего так), то их можно ставить на любой контроллер без проблем и размечать полностью.
2. если у вас нечто на MLC-чипах и не последнего поколения (vertex 3 сотоварищи), то либо использовать их с raid-контроллером и осью, умеющими trim, либо не использовать вообще =)
3. если MLC, но свеженькие, то можно использовать и без trim'а, но при этом крайне желательно размечать не весь объём накопителей. оставив 10% неразмеченным — увеличиваете срок службы в два раза. я бы оставил ~50%, что без trim'а, что с ним.
тогда ничего вертеть не надо.
вопрос в том, будет ли удобно работать изображением с таким разбросом по ширине и хватит ли свободного места на столе =) если ответы утвердительные, я бы выбрал этот вариант.