Ну и решили что я подключусь на стадии установки шарика и его настройки, чтобы если чем могу- тем помочь дружественному админу. Но через неделю встал вопрос о том, что винда Server 2008 x64 не видит тома больше 2Tb. Точнее она их видит, но бьет диск на том в 2Tb и  все остальное, что просто висит немым укором в управлении диска, но является не управляемым разделом. Все естественно удивились, ибо тут же у клиента пошли разговоры- что вы меня дурите- я чотко знаю, что ОНО ДОЛЖНО РАБОТАТЬ! Самое главное что мы тоже все это знали и понимали, но никакие темы с динамическими дисками и прочим не прокатывали. И все из-за того что RAID контроллер, помимо Arraw не мог сделать ничего (об этом в первом пункте).

Полазив на мелкомягких да форумах, выяснил, что это ограничение накладывается не самой виндой, а MBR разделом, который не может быть больше 2Tb (хотя у мелкомягких на сайте заявлено что до 4Tb). Почему и как расписывать не охота- просто принять за данность, что MBR не поддерживает свыше 2Tb.
А вот специально созданный, изначально под Itanium, тип партиции GPT – может (и самый лол заключается в том, что мелкомягкие советуют прибегать к этому типу разделов на дисках свыше 2Tb- как то не вяжется с 4Tb под MBR). Но Windows Server 2008 по дефолту создает раздел MBR, так что для победы над прекрасной и ужасной Windows Server 2008 надо загнать диск в GPT партицию. Надо отметить, что в GPT нельзя конвертить съемные диски, и кластерные, доступные через SCSI or Fibre Channel. И сделать это можно несколькими способами:

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

1. Самый, на мой взгляд, простой способ, но требующий человеческого RAID контороллера (в моем случае пришлось долго и упорно препираться с админом, чтобы доказать ему по скайпу, что такое возможно, так как пилить в офис меня ломало). Мы либо создаем два массива из имеющихся дисков, если у нас их скажем шесть и более штук, или же создаем один массив, но бьем его средствами RAID контроллера на пару виртуальных дисков VD- 150-200GB и все остальное, после чего на 200Gb ставим Windows Server и уже из винды конвертим оставшееся пространство в GPT том.

Поскольку у меня получилось все сделать с первого варианта, то остальные способы скорее теоретические выкладки, которые можно попробовать, если например RAID не дает возможности создавать виртуальные диски. Сам не пробовал, так что еще раз оговорюсь- я всего лишь предполагаю что так возможно.

2. Используя установочный диск FreeBSD 8.Х или Linux c CONFIG_LBD enabled размечаем диск, на небольшую партицию под MBR и здоровую под GPT, после чего на MBR закатываем Server 2008 и опять же из винды конвертим оставшееся пространство в GPT.

3. Данный способ родился из непоняток с оффсайта мелкомягких, так как в статье изначально грится что винда не может грузиться с GPT раздела, если она не  под Itanium, но в других доках относительно Microsoft Windows Server 2008 и дисках больше 2Tb ничего не говорится про загрузочный диск, а напротив рекомендуется делать из раздела более 2Тб партицию GPT. Собственно при начале установки Windows Server 2008 мы выходим на диске в консоль восстановления сервера и уже оттуда конвертим наш раздел в GPT.

Собственно процесс конвертации MBR в GPT выглядит следующим образом (можно конвертить и из Панель управления -> Администрирование -> Управление компьютером -> Управление дисками):
запускаем dos-promt с правами администратора (правый клик в иконку, запустить от администратора) и входим в управление партициями
> diskpart
все команды выполняются дочерними к консоли DISKPART
> list disk
смотрим что там у нас за диски и пишем нужный номер
> select disk 0
удаляем все данные с партиции
> clean
> convert gpt

Более подробно о различиях между GPT и MBR можно почитать на сайте мелкомягких.

И так пытался, и так- ничего не выходит, как ни стараюсь. Если ставлю размер тома более 256Gb система ругается, что создать не может, и сама автоматом ставит на 256Gb. Стал рыть- выясняется интересная особенность, что максимально возможный размер создаваемого тома зависит от величины размера блока VMFS тома- первый дефолтный лимит для тома составляет 255GB, при размере блока 1MB, при увеличении размера блока, также увеличивается возможный размер тома:
1MB размер блока = максимальный размер VMDK 256GB
2MB размер блока = максимальный размер VMDK 512GB
4MB размер блока = максимальный размер VMDK 1024GB
8MB размер блока = максимальный размер VMDK 2048GB/512bytes
Единственный возможный вариант изменить размер блока- отформатировать LUN с новым размером блока, ибо он задается при форматировании. Сижу втыкаю, думаю что делать.

Поскольку парень я ленивый и ставить снова винду, по второму разу меня совершенно не улыбает, то сначала форматирую пустой массив, используя размер блока 8Mb, а затем загружаю первый datastore, и в нем нахожу галочку смувить папку, в которой и лежит операционка, на другой доступный том. Мувлю (трансфер порядка 60 гиг занимает около 30 минут) сначала одну операционку, потом вторую. После этого форматирую первый datastore опять же с использованием размера кластера в 8Mb. После этого создаю два тома размерами по 800Gb и в 1200Gb.

Теперь вот сижу, смотрю на дело рук своих и так прямо таки горжусь собой, что понимаю что теперь мне даже работа в Запорожье будет по плечу Ну а если серьезно, то VMware меня уже начинает пугать, ибо какое то большое количество всевозможных ограничений, в которые постоянно утыкаешься как слепой кутенок, в процессе работы. Благо что некоторые из них все же удается обходить с некоторой сноровкой.

Но тут возникает интересный момент- система видит единственный datastore размеров в 800Gb, и все. То есть в девайсах показывает что есть рейд контроллер, есть рейд массив на 2.8TB, но попытка обнаружения новых datastore не увенчивается успехом, так что в системе доступны только 800 гиг. Гуглю, лезу по форумам и обнаруживаю интересный момент, что VMware не может создавать хранилища больше двух террабайт, то есть у системы VMware и имеется ограничение на создание файлов размером более 2TB.

Чертыхаюсь, перегружаюсь- вижу что VMware видит том на аппаратном уровне, так что попытка разбить его на слайсы сразу будет увенчана неудачей. Собственно залезаю снова в рейдовский биос, сношу том и нарезаю его двумя кусками в 900Gb и 1900GB, после чего запускаю снова инсталлер. VMware видит оба куска, и я ставлю её на тот что  размером 900Gb. Все устанавливаю, загружаю систему, подключаюсь гипервизором- все замечательно: в системе два хранилища данных datastore, размерами в 900Gb и 1900Gb.

Резюме: Система виртуализации VMware ESXi не может создавать хранилища данных LUN размером превосходящие 2TB, в данном случае сказывают ограничения по размеру создаваемого файла. При этом если том превышает своими размерами 2TB, то система берет то количество дискового пространства, которое выходит за пределы 2TB и из них создает хранилище, отбрасывая 2TB за ненадобностью. В этой связи единственный способ борьбы- нарезка имеющегося дискового пространства массивами не превышающими 2TB, в этом случае VMware подхватывает их без проблем, и нарезанные массивы подключаются к настроенным системам, средствами VMware путем добавления новых дисков.

На сервере в дальнейшем планируется размещение данных пользователей, почты и прочего мусора. Ну и благодаря тому что VMware понимает VLAN то вероятнее всего сюда же засунем и базы 1С, для того чтобы работа программист 1с не пропала втуне, ибо как выяснилось при ближнем рассмотрении, у данного клиента та же проблема что и у всех других, что мне доводилось встречать- люди хранят в файловой помойке всякую шнягу типо музыки и фотографий, а архиважные бухгалтерские базы 1С почему то хостятся на локальной машине бухгалтера. Видимо до первого выхода из строя жесткого диска.

Заходим в консоль, и смотрим вообще что у нас там происходит, с помощью утилиты df (сокращение от disk free), предоставляющей информацию о состоянии нашего диска и точек монтирования:

root@server [~]# df -ah
Filesystem Size Used Avail Use% Mounted on
/dev/vzfs 20G 5.0G 1017M 84% /
proc 0 0 0 – /proc
sysfs 0 0 0 – /sys
none 7.9G 4.0K 7.9G 1% /dev
none 0 0 0 – /dev/pts
none 0 0 0 – /proc/sys/fs/binfmt_misc

Если мы хотели бы просмотреть информацию об использовании inode (максимальное число теоретически возможных файлов на данной файловой системе), то это можно проделать с помощью опции -i.
root@server [~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vzfs 20971520 176654 20794866 1% /

если нет надобности выводить информацию по какой то из файловых систем, то её можно исключить используя опцию -x , а опцией -t можно ограничить вывод определенными типами файловых систем.
root@server [~]# df -ah -x sysfs
Filesystem Size Used Avail Use% Mounted on
/dev/vzfs 20G 5.0G 893M 85% /
proc 0 0 0 – /proc
none 7.9G 4.0K 7.9G 1% /dev
none 0 0 0 – /dev/pts
none 0 0 0 – /proc/sys/fs/binfmt_misc

В моем примере видно, что творится какая то чертовщина, поскольку разница общего и использованного объема составляет 15 Гигов, при том, что свободным у меня остается 1Гиг. Явно что какой то глюк, поэтому надо смотреть кто и сколько кушает. Для этого мы воспользуемся утилитой du (сокращение от disk usage), предоставляющей нам информацию об использовании диска файлами и директориями.
root@server [~]# du -hsx /
5.4G /

Это общий размер дискового пространства занимаемого файловой системой / . Чтобы посмотреть разблюдовку по директориям в корневой файловой системе:
root@server [~]# du -shc /*
0 /aquota.group
0 /aquota.user
5.0M /bin
4.0K /boot
4.0K /dev
6.5M /etc
887M /home
24M /lib
4.0K /media
4.0K /mnt
14M /opt
0 /proc
4.8M /root
21M /sbin
7.8M /scripts
4.0K /selinux
4.0K /srv
0 /sys
12K /tmp
4.2G /usr
354M /var
1.5M /yum
1.4M /yum-ce5.tar.gz
5.4G total

Где опция -s выводит итоговый объям для кадого аргумента, опция -h пишет нам в удобочитаемом формате, опция -c заканчивает список общей суммой.
Естественно, что проделывать все операции необходимо из под пользователя имеющего права чтения на директории.

При одновременном использовании этих команд, в большистве случаев мы получим разные результаты вывода для каждой из них. Это вызвано различными алгоритмами работы данных утилит, которые следуют из их названий: утилита df считает общий суммарный объем блоков, помеченных в суперблоке файловых систем как свободные, в то время как утилита du исходит из информации об объеме занятом файлами, отправляясь от  описания в метаданных.
В связи с тем, что операции файловой системы абсолютно во всех случаях, так или иначе, кэшируются, то довольно часто может возникнуть ситуация, когда файл физически удален, т.е. имя файла удалено из записи каталога, а в карте занятости, освобождение соответствующего пространства еще не произошло, и тогда, как раз, блоки данных будут подсчитываться при использовании df, и будут не учтены в результатах du.

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

Для того есть несколько способов.

Через таблицы управления доступом к файловой системе
Вызываем MS-DOS promt и там задаем команду управления ACL:     cacls FILE_XXX /t /p everyone:n
которая обнулит права доступа к файлу, т.ч. после перезагрузки он станет доступным к удалению

Через убийство explorer.exe
Проводник являясь систеой программой собственноручно лочит многие файлы причисляемые им к системных, собственно поэтому часто, в процессе лечения какой нибудь пакости необходима перезагрузка- explorer принимая файл за системный, запрещает какому либо процессу убить его. Панацеей в этой ситуации будет убийство самого explorer.exe
Открываем MS-DOS promt: Пуск -> Выполнить -> cmd -> переходим в директорию где находится залоченный файл cd c:\XXX
Вызываем диспетчер задач, для этого отжимаем CTRL-ALT-DEL -> Диспетчер задач -> вкладка Процессы
Выделяем процесс с гордым именем explorer.exe и нажимаем “Завершить процесс”
Возвращаемся в окошко MS-DOS и убиваем файл: del c:\XXX
Перегружаемся, или переключаемся снова в Диспетчер задач -> вкладка Приложения -> Новая задача -> explorer.exe

Через консоль восстановления Windows
Для этого нам понадобится загрузочный диск Windows CD. Вставляем, выставляем в BIOS загрузку с CD, жмем клавишу на промте и ждем загрузки меню, где одним из пунктов нам будет предложено выбрать консоль восстановления нажатием клавиши “R“. Нас выкинет в окно подобное MS-DOS promt где мы переходим в необходимую директорию и удаляем файл из коммандной строчки. Поскольку система в тот момент не загружена, файл будет разблокирован и должен удалиться без проблем.

Через загрузочный диск Live CD (я использовал дистрибутив Knoppix Live CD который очень хорошо подходит для работы с виндовыми партициями)
Нарезаем iso’шник на болванку, и грузимся с неё. В меню вы бираем либо File Manager либо Graphical Programs.
1. Выбираем File Manager в разделе Mount Devices выбираем нужный нам диск -> mount contents -> browse files и попадаем в окно Midnight Commander, идентичный Norton Cammander файловый менеджер. Там находим нужный файл и удаляем его нажатием F8, единственное что моугт возникнуть трудности с русскими кодировками, тогда надо использовать графический интерфейс. Обратное перемещение по меню осуществляется нажатием CTRL + C
2. Выбираем Graphical Programs -> Full X Session , ждем загрузки системы и жмем в иконку на рабочем столе My documents. В левом фрейме находим свой диск и привычным кликаньем мыши удаляем ненужный и опостылевший, уже к этому моменту, файл. На самом деле Knoppix Live CD судя по заверениям авторов также подходит и для восстановления слетевших партиций, т.к. без проблем считывает битые файлы в связи с тем, что не видит виндовых блокировок и разрешений. Не думаю, что он может стать хорошей альтернативой программам и утилитам восстановления, тем более что удаленные файлы он все таки не видит, но для выполнения небольших задач вроде того как снести битый или лоченный файл подходит вполне. У него еще куча всяких разных фич, но о них я напишу позднее.

Нужно еще также упомянуть программу Unlocker, она правда не доступна с сайта разработчика, но в инете достаточно зеркал которые предлагают её закачать. Вроде бы как с её помощью также возможно удалить любой файл, недоступный для стандартного удаления. Но, говоря откровенно, я не очень люблю ставить различный неизведанный мусор, тем более который отсутствует у создателя, да и Eset у меня что то на неё ругнулся, т.ч. все остальные кроме установки левого софта мне кажутся наиболее привлекательными для использования.

Есть два пути загнать флешку в NTFS:  сконвертировать файлову систему и отформатировать.

Конвертация происходит путем использования утилиты convert.exe, без потери существующих данных, но тем не менее перед использованием этой утилиты я настоятельно рекомендую данные сохранить.
Запускаем DOS-promt и стартового меню, или пишем в запуске программ (вызывается на клавиатуре: win-окошко + R)  cmd
В открывшемся окне вбиваем: convert <имя_переносного_диска>: /fs:ntfs /nosecurity /x
Жмем ввод и ждем завершения процесса преобразования файловой системы.
Для корректного преобразования системы, ввиду специфики построения NTFS, на диске должно присутствовать свободное место, порядка 2-3% от объема диска.
Более подробную информацию можно получить задав в промте команду convert /?

Второй способ, на мой взгляд более правильный, т.е. чистое форматирование в NTFS.
Для этого щелкаем правой клавишей мышки на ярлычке Мой компьютер -> Свойства, вкладка Оборудование -> Диспетчер устройств, раздел Дисковые устройства и там выбираем диск соответствующий вашей флешке, открываем -> вкладка Политка -> переставляете радио-кнопку в положение Оптимизировать для выполнения. Жмем ОК и идем в проводник, там правой клавишей мыши выбираем пункт форматировать и видим что в выпадающем меню тип файловой системы стала доступна система NTFS.

*** Несколько основных правил:
Не стоит использовать систему NTFS на загрузочных флешках;
Если вы планируете использовать их на системах ранее Windows 2000 или отличных от виндовой операционки.
Также существуют специальные программные средства для форматирования флешек к формате NTFS, но встает вопрос зачем нужны сторонние средства, если все можно сделать подручными.