Использование dd на дисках с разным размером сектора

Использование dd на дисках с разным размером сектора

Я хотел бы переместить раздел на новый диск. Старый диск имеет размер сектора 512 байт, а новый — 4096 байт. Я попытался выполнить dd всего диска, но это не удалось, поскольку раздел на старом диске не был выровнен по границам 4 КБ. Поэтому вместо этого я создал раздел с нуля на новом диске с помощью fdisk, затем скопировал этот раздел между дисками с помощью dd. Наконец, я расширил файловую систему на новом диске с помощью resize2fs. Похоже, это сработало, поскольку я могу смонтировать новый раздел (пока только для чтения) и просмотреть файлы, а fsck сообщает, что он чистый.

Но у меня все еще есть сомнения относительно того, безопасно ли это делать. Например, заботится ли FS о размере сектора таким образом, что это может что-то сломать, или она защищена от этого слоем VFS или самим HD?

решение1

Вы не сказали нам, какую команду dd вы изначально пробовали и которая не удалась. Однако я потратил немного времени на проверку исходного кода команды dd (из пакета coreutils) и, похоже, у нас тут проблема.

1852   /* Some devices require alignment on a sector or page boundary
1853      (e.g. character disk devices).  Align the input buffer to a
1854      page boundary to cover all bases.  Note that due to the swab
1855      algorithm, we must have at least one byte in the page before
1856      the input buffer;  thus we allocate 2 pages of slop in the
1857      real buffer.  8k above the blocksize shouldn't bother anyone.
1858 
1859      The page alignment is necessary on any Linux kernel that supports
1860      either the SGI raw I/O patch or Steven Tweedies raw I/O patch.
1861      It is necessary when accessing raw (i.e. character special) disk
1862      devices on Unixware or other SVR4-derived system.  */

Если вы дадите сообщение об ошибке, я могу провести дальнейший поиск. Но для меня это то, где мы попали. То есть выравнивание границы страницы в 512 байт с границей страницы в 4 КиБ не кажется правильным.

Теперь, переходя ко второй части, вы создали раздел второго диска (с помощью fdisk) размером 512 байт. Однако размер сектора, объявленный большинством современных дисков для ОС, составляет 1 МБ, что составляет 4096 КиБ.

В функции update_sector_offset файла fdisk.c вы увидите

/*
             * Align the begin of partitions to:
             *
             * a) topology
             *  a2) alignment offset
             *  a1) or physical sector (minimal_io_size, aka "grain")
             *
             * b) or default to 1MiB (2048 sectrors, Windows Vista default)
             *
             * c) or for very small devices use 1 phy.sector
             */
            sector_t x = 0;

            if (fdisk_dev_has_topology(cxt)) {
                    if (cxt->alignment_offset)
                            x = cxt->alignment_offset;
                    else if (cxt->io_size > 2048 * 512)
                            x = cxt->io_size;
            }
            /* default to 1MiB */
            if (!x)
                    x = 2048 * 512;

            sector_offset = x / cxt->sector_size;

*cxt — дескриптор структуры fdisk.

Итак, эта часть мне не ясна. То есть, если ваш новый диск объявил размер сектора как 4096 КиБ или 512 байт.

Теперь перейдем к последней части.

Нет, файловые системы на самом деле не заботятся о размере сектора. И пока размер блока составляет 4 КиБ, все должно быть в порядке, потому что, поскольку размер виртуальной страницы (в контексте mm) составляет 4 КиБ, mmaped IO должен быть выровнен с этим. На моем ноутбуке размер блока и физический размер сектора одинаковы.

$ sudo blockdev --getpbsz /dev/sda
[sudo] password for chakraborty: 
4096

$ sudo blockdev --getbsz /dev/sda
4096

IO происходит в контексте размера блока, а не размера сектора. Если из-за физического размера сектора FS столкнется с какой-либо проблемой, я буду очень удивлен. Однако VFS не заходит так далеко. VFS находится между приложением, выдающим IO, и фактической файловой системой. То, что мы обсуждаем, находится ниже уровня VFS.

Связанный контент