Hatena::Groupfilesystem

fs_n314

2009-08-20

cpコマンド

| 20:29 |  cpコマンド - fs_n314 を含むブックマーク はてなブックマーク -  cpコマンド - fs_n314

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はどこだろ…。

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20090820

2009-05-28

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

| 15:09 |  マウントの処理がutil-linuxからnfs-utilsに移動していた - fs_n314 を含むブックマーク はてなブックマーク -  マウントの処理がutil-linuxからnfs-utilsに移動していた - fs_n314

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

util-linux 2.13 以降において、NFS マウントの処理は util-linux 自体ではなく、nfs-common が処理します。全てのシステムNFS 共有をマウントするわけではないですし、ポートマッパを標準でインストールするのを避けるため、util-linuxnfs-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
トラックバック - http://filesystem.g.hatena.ne.jp/n314/20090528

2009-05-27

iget()がなくなっていた

| 22:24 |  iget()がなくなっていた - fs_n314 を含むブックマーク はてなブックマーク -  iget()がなくなっていた - fs_n314

メモ

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

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


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

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20090527

2008-06-03

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

02:29 | bonnie++のSequential Readでは何が行われているか - fs_n314 を含むブックマーク はてなブックマーク - bonnie++のSequential Readでは何が行われているか - fs_n314

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 になっている。

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20080603

2008-05-23

lookup_one_lenからlookup

| 18:11 |  lookup_one_lenからlookup - fs_n314 を含むブックマーク はてなブックマーク -  lookup_one_lenからlookup - fs_n314

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

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

lookup_one_len関数 - fs_n314 - filesystemグループ

大丈夫じゃなかった。

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


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

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


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

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20080523
日記の検索