セクター規模の問題は非常に複雑になっています。 2009 年後半まで、ハードディスクの大部分は 512 バイトのセクターを使用していました。 2009 年後半、ディスク メーカーはいわゆる Advanced Format の導入を開始しました。 (AF) ディスク。4096 バイトのセクターを使用します。これらの最初の AF ディスク (そして、知る限り、今日のすべての AF ディスク) は、各 4096 バイトの 物理 を示すコンピューターへのインターフェイスを提供します。 8 つの 512 バイト logical に分割されたセクタ セクター。この変換により、512 バイトを想定して構築された多くの BIOS を含む古いツールが引き続き機能するようになります。お使いのディスクが AF を使用しているかどうかはわかりませんが、どちらの場合も、ほぼ確実に 512 バイトの論理セクター サイズを使用しています。つまり、OS へのインターフェイスは 512 バイトのセクターを使用する必要があります。
問題を複雑にしているのは、特定の USB ディスク エンクロージャです。これらのエンクロージャの一部は、AF と逆の動作をします。8 つのディスク セクタを取り、それらを 1 つの新しい 4096 バイト セクタにバンドルします。この動きの背後にある理由はわかりませんが、実用的な利点の 1 つは、2 TiB を超えるディスクを古い MBR パーティショニング システムで使用できることです。主な欠点の 1 つは、これらのエンクロージャの 1 つでパーティション化されたディスクを直接使用できないこと、またはこのタイプの変換を行わないエンクロージャで使用できないことです。同様に、この翻訳なしで作成されたディスクは、このようなエンクロージャーに移された場合は使用できません。この問題は MBR 自体をはるかに超えていることに注意してください。ディスクは最初のパーティションを (512 バイト) セクター 2048 で始まると認識するかもしれませんが、OS が (4096 バイト) セクター 2048 をシークする場合、そうしません。 そのパーティションの始まりを見つけてください！この問題に遭遇しました。そのため、USB エンクロージャの障害であるという最初の考えは、マザーボードが台無しになったという最近の考えよりも的を射ています。 したことがない この方法でセクターサイズを変換するマザーボードについて聞いたことがあります。 (ただし、一部のハードウェア RAID デバイスはそうします。)
Linux にセクター サイズの認識を強制的に調整させる方法はわかりませんが、十分なディスク容量がある場合は、低レベルのディスク コピーを別のディスクに実行すると役立つ場合があります。例:
dd if=/dev/sdb of=~/image.img
これにより、ディスクが /dev/sdb からコピーされます (USB ディスク; 必要に応じて調整) ファイル ~/image.img に .その後、次のスクリプトを使用してイメージのパーティションをマウントできます:
#!/bin/bash
gdisk -l $1 > /tmp/mount_image.tmp
let StartSector=`egrep "^ $2|^ $2" /tmp/mount_image.tmp | fmt -u -s | sed -e 's/^[ \t]*//' | head -1 | cut -d " " -f 2`
let StartByte=($StartSector*512)
echo "Mounting partition $2, which begins at sector $StartSector"
mount -o loop,offset=$StartByte $1 $3
rm /tmp/mount_image.tmp
スクリプトを mount_image のように保存します。 次のように使用します:
./mount_image ~/image.img 2 /mnt
これにより、image.img のパーティション 2 がマウントされます /mnt へ .スクリプトは GPT fdisk (gdisk )、ほとんどのディストリビューションには gptfdisk というパッケージに含まれています または gdisk .
長期的には、より良い解決策は、セクター サイズの変換を行わないディスクを接続する方法を見つけることです。新しいマザーボードに直接接続するとうまくいくはずです。または、おそらく翻訳を行わない外部エンクロージャを見つけることができます.実際、一部のエンクロージャは USB ポートでは変換を行いますが、eSATA ポートでは行わないため、エンクロージャに eSATA ポートがある場合は、それを使用してみることができます。これらのソリューションはすべてお金がかかる可能性が高いことを認識していますが、それはあなたが持っていないと言っていますが、翻訳エンクロージャーを翻訳しないエンクロージャーと交換できるかもしれません.
私が思いつくもう 1 つのオプションは、VirtualBox のような仮想マシンを使用することです。このようなツールは、ディスク デバイスにアクセスするときに 512 バイトのセクター サイズを想定し、事実上変換を元に戻します。または、ディスクの内容を生でコピーできる場合があります (dd if=/dev/sdc of=/dev/sdb のように) ) を仮想マシン内に配置すると、内容が圧縮されてコピーされる可能性があるため、元のイメージが消費するよりも少ないディスク領域にイメージを収めることができます。
このスクリプトは、レイドまたはクリプトがある場合のロッド スミスの提案を一般化したものです。保証はありません。気軽に改善してください！ (mdadm に関する最新の調査結果で更新)
#!/bin/sh
#
# This script solve the following problem:
#
# 1. create a GPT partition on a large disk while attached directly via SATA
# when the device present itself with 512 bytes of block size:
# sd 3:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 2. try to use a SATA to USB adapter like ID 067b:2773 Prolific Technology, Inc.
# this present the device with 4096 bytes of block size:
# sd 19:0:0:0: [sdc] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
#
# 3. The kernel is unable to read correctly the partition table with
# the USB adaper.
#
#
# With the current tools (kernel and gdisk) in debian wheezy is
# possible to use losetup to remap the partitions to loop devices so
# you can use them as usual with any filesystem, raid or crypto
#
# I still do not know if this issue is originated by the adapter or by
# the disk and if there are any others workarounds.
#
# Known version of the software:
# $ apt-show-versions linux-image-3.2.0-4-amd64
# linux-image-3.2.0-4-amd64/wheezy uptodate 3.2.54-2
# $ apt-show-versions gdisk
# gdisk/wheezy uptodate 0.8.5-1
attach_device() {
device="$1";
MYTMPDIR=`mktemp -d`
trap "rm -rf $MYTMPDIR" EXIT
# gdisk on the device use the 4096 sector size
# but we need to force it to 512
# this is a knwon workaround from http://superuser.com/a/679800
# basically we make a copy of the gpt partition table on a file
dd if="/dev/$device" bs=16384 count=1 of="$MYTMPDIR/gpt" 2> /dev/null
# we extract the offset and the size of each partition
#
# FIXME: the "+ 1" seems strange, but it is needed to get the same
# size value from:
#
# blockdev --getsize64
#
# without the "+ 1" some funny things happens, for example
# you will not be able to start a recognized md device:
#
# md: loop1 does not have a valid v1.2 superblock, not importing!
# md: md_import_device returned -22
#
# even if
#
# mdadm --examine /dev/loop1
#
# does not complaint
gdisk -l \
"$MYTMPDIR/gpt" 2> /dev/null | \
awk '/^ *[0-9]/ {printf "%.0f %.0f\n", $2 * 512, ($3 - $2 + 1) * 512}' > $MYTMPDIR/offset-size
# we create a loop device with the give offset and size
while read line;
do
offset=$(printf "$line" | cut -d ' ' -f 1);
size=$(printf "$line" | cut -d ' ' -f 2);
losetup --verbose --offset "$offset" --sizelimit "$size" `losetup -f` /dev/$device;
done < $MYTMPDIR/offset-size;
}
detach_device() {
device="$1";
for loopdevice in `losetup -a | grep "$device" | cut -d : -f 1`;
do
losetup --verbose --detach "$loopdevice";
done;
}
usage() {
cat <<EOF
Usage:
- $0 -h to print this help
- $0 sda to attach the gpt partitions of sda
- $0 -d sda to detach the gpt partitions of sda
EOF
}
detach=0;
while getopts hd action
do
case "$action" in
d) detach=1;;
h) usage;;
esac
done
shift $(($OPTIND-1))
if [ $# -ne 1 ];
then
usage;
fi
if [ "x$detach" = "x0" ]; then
attach_device $1;
else
detach_device $1;
fi
WD My Book 外部エンクロージャから 4TB ディスクを取り外したときに、この問題が発生しました。問題は:
<オール>解決策: パーティション テーブルを GPT に書き換え、512 バイト セクターを使用するように値を変換します。
私の場合、パーティションは 1MB のオフセットで始まり、ディスクの終わりの前 (~856kB) で終わりました。パーティションの前の MBR+GPT (17408 バイト) とディスクの最後にあるバックアップ GPT (16896 バイト) が許可されるため、これは良いことです。
念のため、両方の領域の画像を作成しました (dd を使用)。
fdisk -l /dev/sde からの出力に注目しました .
gdisk を使用して最初のパーティションを削除しました。必要に応じて、私が行ったようにして、整列値を 8 (4096) に変更して、できるだけ多くのスペースを使用することができます。次に、2048 で開始し、ディスクの最後で終了する新しいパーティションを作成しました。後でファイル システムを拡張します。
ありがたいことに、セクター サイズの変更は、ファイル システム、LVM、LUKS には影響しません。