= Сообщение: 7283 из 10763 ===================================== RU.UNIX.BSD = От : Victor Sudakov 2:5005/49 07 May 18 12:30:46 Кому : Eugene Grosbein 07 May 18 12:30:46 Тема : boot manager for GPT FGHI : area://RU.UNIX.BSD?msgid=2:5005/49+5aefe488 На : area://RU.UNIX.BSD?msgid=grosbein.net+f6e5a7ab = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Dear Eugene,
06 May 18 23:06, you wrote to me:
EG>>> Зачем тебе неограниченное количество разделов на носимом EG>>> диске-то? Одного FAT32/NTS в MBR недостаточно для обмена EG>>> данными? VS>> Hа носимом диске уже давно недостаточно FAT32 из-за ограничения VS>> размера файла в 4 Гб. А NTFS FreeBSD не умеет нормально на VS>> запись. Выручил бы exfat, но его нет не только в базовой системе, VS>> но даже в бинарных пакетах из-за каких-то лицензионных VS>> ограничений. И они оба (rw NTFS и exfat) только через fuse.
EG> Твои данные на эту тему сильно устарели. Во-первых, ту реализацию EG> NTFS, которая не умеля rw, из FreeBSD давно выкинули уже. Вместо EG> неё fuse нынче в базовой системе с десятки и на моём домашнем EG> dualboot-десктопе прекрасно монтируется NTFS с соседнего раздела с EG> Win8.1.
Через sysutils/fusefs-ntfs же?
EG> Правда, для этого саму Win8.1 пришлось настроить размонтировать EG> раздел при shutdown (ценой слегка более медленного EG> выключения/включения), а то по дефолту оно нынче только симулирует EG> shutdown, а реально выполняет что-то вроде suspend-to-disk и не EG> размонтирует fs.
У меня с Windows 7 проблемы с записью были: через NTFS-3G пишешь-пишешь на NTFS диски, а загрузившись в Windows, записанного не находишь. Писал в никуда. Потому и написал выше "А NTFS FreeBSD не умеет нормально на запись."
Виноват тут скорее всего виндовый fast restarting, но я не знаю, как его отключить отдельно от hibernation.
VS>> Hо речь ведь не обязательно про носимый диск. Вот к примеру VS>> первые два пришедших в голову сценария.
VS>> 1. Делается ТО компа с FreeBSD, железячник загружает его с VS>> хитрого ремонтного flash/DVD для проверки железа. Лучше если его VS>> инструменты будут видеть на диске нечто знакомое им, а то ещё VS>> попытаются чинить. Собственно Protective MBR на такой случай и VS>> придуман.
EG> Я бы не пустил к железке железячника, который использует для TO железа EG> инструменты, "пытающиеся чинить" информацию на диске - в самом крайнем EG> случае, предварительно убрав собственно диски. Hафик-нафик.
Случаи всякие бывают. Protective MBR (и вообще наличие стандартной, всеми признаваемой partitioning scheme) - доп. подстраховка.
[dd]
EG>>>>> И это в GPT тоже плохо. В нём всё плохо - ни совместимости EG>>>>> с graid/gmirror, VS>> Работает в общем-то с gmirror, хоть и с руганью в начале загрузки VS>> на отсутствие второй GPT. Hеаккуратненько, да.
EG> Тут проблема вовсе не в "неаккуратненько", а в том, что софт надеется EG> на доступность резервной копии GPT и ведет себя соответственно, EG> а в момент X внезапно окажется, что нет ни оригинала, EG> ни копии и совершенно штатная процедура загрузки с использованием EG> бекапа ВHЕЗАПHО переходит в разряд аварийной починки вручную.
Это какой например софт так надеется?
EG>>>>> ни мультизагрузчиков, единственный бут-раздел. VS>> Да, единственный бут-раздел это минус, особенно если привык, что VS>> на MBR их с лёгкостью 4 шт и boot0 совершенно беспроблемен.
EG> Кстати сказать, дополнительная ненужная single point of failure.
EG> Одна из причин, по которым я на домашнем десктопе держу несколько EG> операционок с MBR, это то, что при софтовом повреждении одной из них EG> до состояния незагружаемости у меня всегда есть возможность EG> загрузиться во вторую, где заранее настроенное комфортное окружение EG> с доступом в сеть (к вебу, к своей почте) и даже если форс-мажор EG> и некогда заниматься починкой - десктоп всё равно жив и доступен.
Это проще на флешку поставить полноценную систему. У меня есть такая (правда без иксов).
