問題タブ [superblock]

Unix（具体的にはMac OS X）では、スーパーブロックは、iノードが開始および終了するディスクアドレスなど、ディスク上のデータのレイアウトに関する情報を格納することを知っています。プログラム内のiノードのリストをスキャンして、削除されたファイルを探します。iノードが始まるディスクアドレスを見つけるにはどうすればよいですか？statfsコマンドを見ましたが、この情報は提供されません。

C言語の規則では、配列インデックスは0からカウントされます。iノード番号が0ではなく1から始まるのはなぜですか。

iノード0が特別な用途のために予約されている場合、iノード0の重要性は何ですか？

私は、ext2パーティションを読み取ることができるWindows用のリーダープログラムを作成する任務を負っています。

私のテストでは、ext2にフォーマットしたドライブと、mkfsを使用して作成したファイル（Linuxでマウントされて正常に動作するファイル）を使用しています。

何らかの理由で、ドライブ（実際のスーパーブロック）からスーパーブロックを読み取ると、すべての正しいメタデータ（つまり、ブロックサイズ、iノード数など）を取得しますが、ファイルに対してまったく同じことを行うと、悪い結果が返されます（も意味ない）。

2つの間に違いはありますか？

\。\X：を使用してドライブを開き、mkfsを使用してファイルを作成します。

Linux カーネルでget_sb_nodevと get_sb関数を置き換えた関数は何ですか?

3.5 以降のカーネルでは使用できなくなりました

c++ を使用して Linux inode ビットマップをフェッチします。このコードを使用して、最初にスーパー ブロックを取得しました。

しかし、実行するたびにエラーが発生します:

これに関する良い例やチュートリアルが見つかりませんでした。誰か助けてくれませんか?

EDIT：
私は含めまし<linux/stat.h>たが、それでも同じエラーが発生します。

私はかなり長い間Linuxサーバーを使用しており、cifsマウントを使用していくつかのWindows共有にマウントしています。

これまでのところ、/etc/fstab には常に次の行がありました: //IPADDRESS/sharename /mnt/localfolder cifs soft,username=xxx,password=xxx,_netdev,uid=500,gid=501 0 0

前回の再起動以降 (おそらく新しいカーネル アップデートを適用したため)、共有をマウントできません。

現在のカーネル: 3.4.76-65.111.amzn1.x86_64

これは私がチェックしたものとコマンドの結果です:

1. ネットワーク環境は変更されておらず、共有/IP は他の PC から到達可能であり、使用可能です。

2. cifs-utils、nfs4-acl-tools、nfs-utils がインストールされ、portmap が実行されている

3. 手動マウント コマンド (常に機能):

mount -t cifs -o credentials=/root/.smbcredentials,_netdev,uid=500,gid=501 //IPADDRESS/sharename /mnt/localmap/

戻り値: マウント: 間違った fs タイプ、不適切なオプション、//IPADDRESS/sharename の不適切なスーパーブロック、コードページまたはヘルパー プログラムの欠落、またはその他のエラー (複数のファイル システム (nfs、cifs など) の場合、/sbin/mount.ヘルパー プログラムが必要な場合があります) ) 場合によっては、役に立つ情報が syslog に見つかります。尻尾かそこら

4. dmesg | テールリターン:

CIFS VFS: DFS ルートへの接続はまだ実装されていません CIFS VFS: cifs_mount がリターン コード = -22 で失敗しました

他に何を試すことができるか、またはこれが何であるかについてのアイデアはありますか?

多くのリンクを見つけましたが、ほとんどすべてが理由ではなく修正を指しています。

USBカードリーダーを介してPCに接続されたSDカードに7GBのext4パーティションを作成しました。上記のパーティション (/dev/sdc2) に 10488576 バイトを書き込むアプリケーションがあります。アプリケーションの実行後、ファイル システムが破損しているように見えます。

アプリケーションは単に以下のようなものを使用しています (正確なコードを投稿することはできません):

ファイルシステムのブロックサイズは 4K です。32768 、98304 、163840 、229376 、294912 、819200、884736 、1605632 でスーパーブロックをバックアップします。さらに情報が必要な場合はお知らせください。この破損の原因を理解する必要があります。なぜなら、アプリケーション コードに何か問題がある可能性があることを強く確信しているからです。

EDIT: プライマリ スーパーブロックが 0 から始まり、前の lseek() 呼び出しwrite()も0 に対して行われていることがわかりSEEK_SETます。これにより、スーパーブロック情報が上書きされます。スーパーブロックの前に lseek を試してみwrite()ます。

EDIT： 上記のようにして、これを修正しました。dumpe2fs o/p によると、グループ 0 について以下がありました。

だから、書く前に、私は 8593*4096 に lseek しました。これで、ファイルシステムは壊れなくなりました。