悪魔は細部に宿る... まず、Unix 設計の基本原則があります:すべてはファイルです 、ここでうまく説明されています。
2 つ目は、stat(2) 呼び出しが inode を提供していることです。 device-special file に関するファイルシステムに保存された統計 サイズがゼロです（lstat(2)と考えてください ）。ファイルシステムを持つブロックデバイスがある場合、 statfs(2) を使用してそれに関する情報を取得します または getfsstat(2) または statvfs(2) ファイルシステム/デバイスに依存しない方法で。
特別なファイル (通常は /dev にある) の扱いは常にシステム固有であり、マニュアル ページはセクション 4 にあります。したがって、デバイスを直接操作したい場合は、そこの詳細を読む必要があります。たとえば、Linux では man 4 hd プログラムで IDE ブロック デバイスと対話する方法を示します。一方 man 4 sd SCSI ディスクの操作方法などを説明します。
第 3 に、システム コールの機能に一貫性がないことは想定されていません NOR
これがお役に立てば幸いです。
この Unix Stack Exchange の質問から:
<ブロック引用>デバイス ファイルは、それ自体はファイルではありません。これらは、Unix ライクなオペレーティング システムでデバイスを使用するための I/O インターフェイスです。これらはディスク上のスペースを使用しませんが、stat コマンドで報告されるように i ノードを使用します:
$ stat /dev/sda
File: /dev/sda
Size: 0 Blocks: 0 IO Block: 4096 block special file
Device: 6h/6d Inode: 14628 Links: 1 Device type: 8,0
それは stat を解決します
この「ファイル」でシークできるという事実は関係ありません。これは実際にはファイルではありませんが、 open することができます それを読んでください。あなたもそれを求めることができます。最下位レベルでディスクを読み取ることができるため、シークが必要です (これが機能する理由であり、「実際の」ファイルのように新しい位置を返さないのはなぜですか?)。
this other UnixSE answer によると、この /dev/sda/size を読むことでデバイスのサイズを取得できます ファイル。
/dev/sda などの「デバイス」の長さ POSIX struct stat で指定されていません :
off_t st_size For regular files, the file size in bytes.
For symbolic links, the length in bytes of the
pathname contained in the symbolic link.
For a shared memory object, the length in bytes.
For a typed memory object, the length in bytes.
For other file types, the use of this field is
unspecified.
したがって、POSIX にはディスク デバイスの「サイズ」に関する要件はありません。
Linux も同様に stat() を指定していません ディスク デバイスのサイズを返します:
st_size
このフィールドは、ファイルのサイズ (通常のファイルまたはシンボリック リンクの場合) をバイト単位で示します。シンボリック リンクのサイズは、終端のヌル バイトを除いたパス名の長さです。