fs_n314

cpコマンド

utils | 20:29 |

apt-get source coreutils

# cp.c
main
  do_copy
# copy.c
    copy
      copy_internal
        copy_reg # ファイルの種類やオプションによっていろいろ
          source_desc = open (src_name, O_RDONLY | O_BINARY)
          dest_desc = open (dst_name, O_WRONLY | O_CREAT | O_BINARY, dst_mode) # ファイルがある場合は O_CREAT => O_TRUNC
          read(source_desc, buf, buf_size)
          lseek(dest_desc, (off_t)n_read, SEEK_CUR) < 0L)
          full_write (dest_desc, buf, n)

full_writeはどこだろ…。

マウントの処理がutil-linuxからnfs-utilsに移動していた

nfs | 15:09 |

5.2. nfs-common が NFS マウントを処理するようになりました

util-linux 2.13 以降において、NFS マウントの処理は util-linux 自体ではなく、nfs-common が処理します。全てのシステムが NFS 共有をマウントするわけではないですし、ポートマッパを標準でインストールするのを避けるため、util-linux は nfs-common を提案するだけです。NFS 共有をマウントする必要があるなら、システムに nfs-common がインストールされていることを確認してください。mount パッケージのインストール前スクリプトは、NFS マウントが存在するかチェックして、nfs-common に含まれている /usr/sbin/mount.nfs がなかったり、nfs-common が古かったりすると処理を中断します。mount のアップグレード前に、nfs-common をアップグレードするか、NFS マウントを全てアンマウントしてください。

http://www.debian.org/releases/stable/i386/release-notes/ch-information.ja.html#nfs-common

# etch?
# libgssglue-dev => libgssapi-dev

# lenny
apt-get install pkg-config libblkid-dev libwrap0-dev libblkid-dev libevent-dev libnfsidmap-dev librpcsecgss-dev libgssglue-dev libkbr5-dev
apt-get source nfs-common

iget()がなくなっていた

vfs | 22:24 |

メモ。

深追いできそうなら後で書く。

http://kerneltrap.org/mailarchive/linux-kernel/2007/10/12/335805

しかし何たる反応の遅さ。

bonnie++のSequential Readでは何が行われているか

02:29 |

Sequential CreateやSequential Readと言われると何となく分かった気になるけれど、実際に中でどう動いているのかを見る。

ここでのreadというのは実はstatである。

int COpenTest::stat_sequential(BonTimer &timer)
{
  timer.timestamp();
  int count = 0;
  for(int i = 0; i < m_number_directories; i++)
  {
    char buf[6];
    if(m_number_directories != 1)
    {
      sprintf(buf, "%05d", i);
    }

    DIR *d = opendir(".");

    dirent *file_ent;
    while((file_ent = readdir(d)) != NULL)
    {
      if(file_ent->d_name[0] != '.') // our files do not start with a dot
      {
        if(-1 == stat_file(file_ent->d_name))
        {
          if(m_number_directories != 1)
            chdir("..");
          return -1;
        }
        count++;
      }
    }
    closedir(d);

  }

  timer.get_delta_t(StatSeq);
  return 0;

#ifdef OS2 の部分とエラーなどにより途中でreturnする部分は削った。

m_number_directoriesというのは -n オプションで指定したnum-directoriesであり、デフォルトは1である。

ディレクトリにファイルがある限りstat_fileを繰り返している。

int COpenTest::stat_file(CPCCHAR file)
{
  struct stat st;
  if(stat(file, &st))
  {
    fprintf(stderr, "Can't stat file %s\n", file);
    return -1;
  }
  if(st.st_size)
  {
    FILE_TYPE fd = 0;
    fd = open(file, O_RDONLY);
    if(fd == -1)

    for(int i = 0; i < st.st_size; i += m_chunk_size)
    {
      int to_read = st.st_size - i;
      if(to_read > m_chunk_size) to_read = m_chunk_size;
      if(to_read != read(fd, static_cast<void *>(m_buf), to_read))
      {
        fprintf(stderr, "Can't read data.\n");
        return -1;
      }
    }
    file_close(fd);
  }
  return 0;
}

ここでstatシステムコールとreadシステムコールが呼び出されている。

ファイルがある限り繰り返すと書いたが、これはreadが呼ばれる前のcreateで作られる。

これはdirectory_size * DirectoryUnitであり、デフォルトは 16 * 1024 = 16384 になっている。

lookup_one_lenからlookup

vfs | 18:11 |

以前の疑問が後ろ向きに解決した。

VFSの中で、__lookup_hash()にnameidataをNULLで渡している。これもよくわからない。そんなことして大丈夫なの？

lookup_one_len関数 - fs_n314 - filesystemグループ

大丈夫じゃなかった。

というか、自分のファイルシステムの実装が駄目だった。

どうもi_op->lookupはnameidataがNULLのときでもちゃんと動くようにしなければならないらしい。

というか、ext3などのファイルシステムではnameidata自体が使われていない。

というわけで、可能な限りlookupの中でnameidataは使うなということで解釈。