web-dev-qa-db-ja.com

LinuxでSDカードの全容量をテストするにはどうすればよいですか?

EBayから64 GB SDカードを購入しました。 Arch Linux ARM=イメージを書き込み、それを使用してRaspberry Piを起動するときに問題なく動作します。

しかし、その上に単一のext4パーティションを作成してカードのすべての容量を使用しようとすると、エラーが発生します。 mkfs.ext4は常に楽しく終了します。ただし、パーティションをmountedにすることはできず、常にエラーがスローされます。dmesgは、カーネルメッセージにCannot find journalが含まれていることを示します。これは、少なくとも2つのプラットフォーム(Arch Linux ARMおよびUbuntu 13.04)で当てはまることが証明されています。

一方、FAT32パーティションをエラーなしで作成してマウントできます(全容量チェックは行われていません)。

一部の悪意のある人がSDカードインターフェイスを変更して、OSに間違った容量を報告する可能性があると聞きました(つまり、カードは実際には2 GBだけですが、それ自体は64 GBと報告されています)。

SDカードで不良ブロックをチェックするためにbadblocksのようなツールが存在することは知っています。 badblocksはこのような問題を検出できますか?そうでない場合、カードをテストするために他にどのような解決策がありますか?

だまされたかどうか知りたいのですが。結果が悪いアイテムを受け取っただけであることが示された場合、私は売り手にのみ戻ることができ、誰かが私をだまそうとしたことをeBayに報告します。

[〜#〜]更新[〜#〜]

操作とメッセージ:

~$ Sudo mkfs.ext4 /dev/sde1
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
4096000 inodes, 16383996 blocks
819199 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
500 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
4096000, 7962624, 11239424

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done   

~$ dmesg | tail
...
[4199.749118]...
~$ Sudo mount /dev/sde1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sde1,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

~$ dmesg | tail
...
[ 4199.749118]...
[ 4460.857603] JBD2: no valid journal superblock found
[ 4460.857618] EXT4-fs (sde1): error loading journal

[〜#〜]更新[〜#〜]

badblocks /dev/sdeを実行しましたが、エラーは報告されません。つまり、残りの原因は次のとおりです。

  • SDカーは良いですが、何らかの理由でmke2fsまたはmountまたはカーネルに問題の原因となるバグがあります。

  • 私は、敗北を検出できないbadblocksという方法でだまされました。 badblocksが書き込み/読み取りテストを実行しているだけだと思う​​ので、これはもっともらしいことです。ただし、不正行為者は、アウトバウンドエリアへのアクセスをインバウンドブロックにリンクさせることができます。この場合、インプレース書き込み読み取りチェックでは問題を検出できません。

適切なテストを実行できるアプリケーションがない場合は、簡単なCプログラムを作成してテストできると思います。

17
Earth Engine

もし誰かがこれを後で見た場合:誰かが "F3"と呼ばれるオープンソースツールを書いて、SDカードや他のそのようなメディアの容量をテストしました。 プロジェクトのhompage および Github内 にあります。

26
Radtoo

不正行為は次の手順で確認されました。

  • ランダムデータファイルを生成します。 (4194304 = 4×1024×1024 = 4 MiB、合計サイズ= 40×4 MiB = 160 MiB)

    コマンド:

    dd if=/dev/urandom of=test.orig bs=4194304 count=40
    40+0 records in
    40+0 records out
    167772160 bytes (168 MB) copied, 11.0518 s, 15.2 MB/s
    
  • データをSDカードにコピーします。 (2038340×4096 = 8153600 KiB = 7962.5 MiB)

    コマンド:

    Sudo dd if=test.orig of=/dev/sde seek=2038399 bs=4096
    40960+0 records in
    40960+0 records out
    167772160 bytes (168 MB) copied, 41.6087 s, 4.0 MB/s
    
  • SDカードからデータを読み戻します。

    コマンド:

    Sudo dd if=/dev/sde of=test.result skip=2038399 bs=4096 count=40960
    40960+0 records in
    40960+0 records out
    167772160 bytes (168 MB) copied, 14.5498 s, 11.5 MB/s
    
  • 結果を表示

    コマンド:

    hexdump test.result | less
    ...
    0000ff0 b006 fe69 0823 a635 084a f30a c2db 3f19
    0001000 0000 0000 0000 0000 0000 0000 0000 0000
    *
    1a81000 a8a5 9f9d 6722 7f45 fbde 514c fecd 5145
    
    ...
    

どうした?ゼロのギャップが観察されました。これは、ランダムデータがカードに実際に書き込まれていないことを示します。しかし、なぜデータは1a81000?明らかに、カードには内部キャッシュがあります。

また、キャッシュの動作を調査することもできます。

hexdump test.orig | grep ' 0000 0000 '

結果は得られません。つまり、生成されたゴミにはそのようなパターンがありません。しかしながら、

hexdump test.result | grep ' 0000 0000 '
0001000 0000 0000 0000 0000 0000 0000 0000 0000
213b000 0000 0000 0000 0000 0000 0000 0000 0000
407b000 0000 0000 0000 0000 0000 0000 0000 0000
601b000 0000 0000 0000 0000 0000 0000 0000 0000

4試合あります。

これがbadblocksチェックに合格する理由です。さらにテストを行うと、実際の容量は7962.5 MB、つまり8 thanGBをわずかに下回ることがわかります。

これが単なるランダムなハードウェア障害である可能性は非常に低いものの、一種の不正行為(つまり、詐欺)である可能性が高いと私は結論付けています。他の被害者を助けるためにどのような行動を取ることができるか知りたいのですが。

アップデート11/05/2019

  • 正しいseekパラメータは2038399。上記で示したよりも多くの経験をしました。基本的に、最初に推測する必要があります。適切なサイズのデータ​​を推測する必要があり、データの破損が発生した場所を推測する必要があります。しかし、いつでも bisection method を使用して支援できます。

  • 以下のコメントでは、上記の2番目のステップ(SDカードへのデータのコピー)では1セクターしかコピーされないと想定されていました。しかし、私は私の実験でこの間違いをしませんでした。代わりに、seekは「結果の表示」ステップでオフセット1000は単にデータの2番目のセクターで発生します。 seekが2038399セクターの場合、破損は2038400番目のセクターにあります。

6
Earth Engine

まず、@ RadtooによるFの回答を読んでください。それが正しい方法です。

私はどういうわけかそれを逃し、自分のやり方を試しました:

  1. 1 GBのテストファイルを作成:_dd if=/dev/urandom bs=1024k count=1024 of=testfile1gb_

  2. そのファイルのコピーをsdcardに書き込みます(64はGBのSDカードサイズです):for i in $(seq 1 64); do dd if=testfile1gb bs=1024k of=/media/sdb1/test.$i; done

  3. ファイルのmd5をチェックします(最後以外のすべてが不完全で、一致している必要があります):_md5sum testfile1gb /media/sdb1/test.*_

3
domen

次のことを行う小さなスクリプトを書きました。

-ターゲットUSBまたはSCカードに一時ディレクトリを作成します

このスクリプトを使用して、8 GBのmicroSDを64 GBにパスしたeBayの販売者に騙されたと結論付けました

#!/bin/bash
#Save file as 'filltext' and remember to set the executable flag to run it
if [ -d "$1" ]; then
 if [ -d "$1/tmp" ]; then
  echo "."
 else
  mkdir $1/tmp
 fi

#Make a tmp file and fill it with 3MB of junk
 TMPTSTR=$(mktemp)      
 base64 </dev/urandom  | head -c 5000000 > $TMPTSTR

 TESTVAL=$(md5sum $TMPTSTR | awk '{ print $1 }')

 while $CHECKEDOK; do

  FL=$( tr -dc A-Za-z0-9 </dev/urandom  | head -c 5).TEST

  cp $TMPTSTR $1/tmp/$FL
  TESTTMP=$(md5sum $1/tmp/$FL | awk '{ print $1 }')
  if [ "$TESTVAL" != "$TESTTMP" ]; then   
   echo "Checksum ERROR"
   echo "Original: $TESTVAL Temp File:$TESTTMP"
   CHECKEDOK=false
   df $1 -Ph
   echo 
   echo 
   echo "Removing test files"
   rm $1/tmp -r
   rm $TMPTSTR
   df $1 -Ph
  else
   #echo -n "$FL..."
   clear
   df $1 -Ph
  fi
 done

else
 echo "Error: Directory $1 does not exists."
 echo "Usage: filltest [PATH]"
 echo
 echo "Try the PATH of a mounted USB dongle or SD card to confirm it's capacity"

fi
2
Robert Charest

SDカードの全容量をテストする最も簡単な方法は、SDカードをファイルで満たしてから、ファイルが正しいことを確認することです:diff -qr /directory/on/computer /directory/on/SD

または、プログラムを使用してパターンまたはハッシュのチェーンをファイルに書き込み、それらが正しいことを確認することもできます。

@ Earthy Engineが指摘したように、SDカードをいっぱいにしてからデータを読み取ることが重要です。これは、単にデータの小さなブロックを書き込んでから読み取るという従来のアプローチが、偽のSSDカードにだまされているためです。 。

2
Zaz

一連の数値(各行は16バイト)を書き込んでから、内容を確認できます。

dd if=<(seq -w 0 123456789012345) of=/dev/yourSdHere

次に、スキップ==出力を確認します(書き込まれるレコード数が少ないスキップ値の小さなサンプルを使用)。スキップ= 9876

dd if=/dev/yourSdHere bs=16 count=1 skip=9876
000000000009876
1+0 records in
1+0 records out
16 bytes copied, ...

または、1つのライナーで20か所のサンプルを作成します。

seq -w 000000000000000 NumberOfWrittenRecords | shuf | head -20 | while read i; do [[ $(dd if=/dev/yourSdHere bs=16 count=1 skip=$i) == $i ]] && echo ok || echo bad; done
  • SDカードに書き込んでいることを確認してください
  • ファイルに書き込むof=tempFileOnSD、カードに保存されているデータの破壊を回避したい場合(偽物でない場合のみ該当)
  • 64GBとラベル付けされた8GBカードの場合、20回のテストすべてに合格する確率は(8GB/64GB)** 20 <1e-18
1
karpada