1. 09 1月, 2006 3 次提交
  2. 31 10月, 2005 2 次提交
  3. 08 9月, 2005 1 次提交
    • K
      [PATCH] Speedup FAT filesystem directory reads · f3ef6f63
      Karsten Wiese 提交于
            OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      
      This speeds up directory reads for large FAT partitions, if the buffercache
      has to be filled from the drive. Following values were taken from:
      
              $ time find path_to_freshly_mounted_fat > /dev/null
      
      on an otherwise idle system.
      
      FAT with 16KB Clusters on IDE attached drive:   Factor  2
      FAT with 32KB Clusters on USB2 attached drive:  Factor 10 (!)
      Its less than 1/10 slower, if the buffercache is uptodate.
      
      The patch introduces the new function fat_dir_readahead().
      
      fat_dir_readahead() calls sb_breadahead() to readahead a whole cluster,
      if the requested sector is the first one in a cluster.
      It is usefull to do this, because on FAT directories occupy whole
      clusters, with the exception of FAT12/FAT16 root dirs.
      
      Readahead is only done, if the cluster's first sector is not uptodate
      to avoid overhead, when the buffer cache is already uptodate.
      Note that under memory pressure, the maximal byte count wasted
      (read: has to be red from disk twice) is 1 cluster's size.  Thats 64KB.
      
      fat_dir_readahead() is called from fat__get_entry().
      
      There is also an unrelated cleanup at one spot:
      
              if (bh)
                      brelse(bh);
      
      is replaced with:
      
              brelse(bh);
      
      brelse() can handle NULL pointer arguments by itself.
      Signed-off-by: NKarsten Wiese <annabellesgarden@yahoo.de>
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f3ef6f63
  4. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4