Re: выравнивание раздела: кому верить, fdisk или parted?
Sergey Spiridonov <sena@s73.work> wrote:
> Приветствую
> > > Не понял тебя. В соответствующий драйвер можно USB UASP внести
> > > изменение, и он будет поправлять optimal_io, в зависимости от усб
> > > идентификатора, то есть возвращать либо 0 либо 33554432, вместо
> > > 33553920, как сейчас.
> > Ещё раз и меееееедлееееенннннно - эта цифра обозначает максимальный
> > размер одного URB между USB девайсами. К твоему винту она не
> > относится совсем никак.
> Во-первых размер странный, не находишь? Почему он не дотягивает один
> блок в 512 байт до 65536? Если это число из железа, то либо
> железо сообщает неправильный размер, либо драйвер его
> неправильно интерпретирует. А значит его можно подправить в драйвере.
Нет, не странный. Это дело двух USB железок какой поток данных они будут
гонять.
> Во-вторых если это просто максимальный размер URB между USB девайсами,
Потому, что parted - гендерно-нейтральная поделка.
> почему это значение используется для выравнивания? Ведь в руководстве
> parted написано что выравнивание должно быть кратно размеру физического
> сектора, который равен в данном случае 4096. Это правило здесь явно
> нарушается - а значит необходимо поправить либо код, либо
> руководство parted, а может и то и другое.
Вот тебе с моей машины:
# grep . /sys/block/sd*/queue/optimal_io_size
/sys/block/sda/queue/optimal_io_size:0
/sys/block/sdb/queue/optimal_io_size:0
/sys/block/sdc/queue/optimal_io_size:0
/sys/block/sdd/queue/optimal_io_size:0
/sys/block/sde/queue/optimal_io_size:0
/sys/block/sdf/queue/optimal_io_size:0
/sys/block/sdg/queue/optimal_io_size:0
/sys/block/sdh/queue/optimal_io_size:0
/sys/block/sdi/queue/optimal_io_size:0
/sys/block/sdj/queue/optimal_io_size:0
# grep . /sys/block/sd*/alignment_offset
/sys/block/sda/alignment_offset:0
/sys/block/sdb/alignment_offset:0
/sys/block/sdc/alignment_offset:0
/sys/block/sdd/alignment_offset:0
/sys/block/sde/alignment_offset:0
/sys/block/sdf/alignment_offset:0
/sys/block/sdg/alignment_offset:0
/sys/block/sdh/alignment_offset:0
/sys/block/sdi/alignment_offset:0
/sys/block/sdj/alignment_offset:0
Изволите перестать писать на диски? Или писать по 0 байт?
> > > Я читал что шифрование само по себе не должно добавлять много
> > > тормозов, если ЦПУ поддерживает аппаратное ускорение AES. По
> > > крайней мере, так
> > Если поддерживает. Вот куча всякого MIPS/ARM железа - не
> > поддерживает. А в качестве микросервера с USB3 для бакапов спрятанное
> > в кладовке имеет место быть.
> Я писал, какое у меня железо.
> > Муххахха. Скорость хреновой флешки.
> Это ещё цветочки, но при этом хотя бы пользоваться системой вполне
> реально.
> > Нисколько. За них инсталлер сам всё разметит, с учетом эмпирической
> > цифры в 2048 секторов, которой "должно хватить на любой алигн для
> Какой ещё инсталлер? При чём тут инсталлер? Проблема с parted. Впрочем
> в инсталлере тоже может быть подобный баг.
Такой инсталлер, которым debian ставят. Ибо расчитано под один раз разбили и
поставили, а флешки и прочая usb-хрень уже воткнута отформатированной в fat/exfat/ntfs.
А те, кто может вотнуть неформатированный блочный девайс - обладают знаниями
про fdsik. А гнутый parted он опционален, в базовой поставке его нет.
> > Выкинь нахрен свою USB корзинку, распечатай и повесь на стенку плакат
> ...
> > > Предыстория такова:
> > ... ты купил какой-то шлак, вместо банальной корзинки с eSATA
> > подключением и теперь занимаешься починкой нечинимого.
> Как говорится, играл, но не угадал ни одой буквы. На УСБ3 я перешёл как
> раз с eSATA. По причине тех же затыков и тормозов.
Угадал. То, что ты не знаешь, что делашь - я сразу написал. И то, что ты
не можешь внятно описать проблему - тоже.
Reply to: