1. 19 5月, 2015 1 次提交
  2. 02 5月, 2015 1 次提交
  3. 12 4月, 2015 2 次提交
  4. 03 4月, 2015 1 次提交
  5. 30 8月, 2014 1 次提交
  6. 29 7月, 2014 1 次提交
  7. 28 5月, 2014 1 次提交
  8. 24 1月, 2014 1 次提交
  9. 29 8月, 2013 1 次提交
  10. 29 6月, 2013 1 次提交
  11. 20 4月, 2013 1 次提交
    • T
      ext4: fix readdir error in the case of inline_data+dir_index · 8af0f082
      Tao Ma 提交于
      Zach reported a problem that if inline data is enabled, we don't
      tell the difference between the offset of '.' and '..'. And a
      getdents will fail if the user only want to get '.' and what's worse,
      if there is a conversion happens when the user calls getdents
      many times, he/she may get the same entry twice.
      
      In theory, a dir block would also fail if it is converted to a
      hashed-index based dir since f_pos will become a hash value, not the
      real one, but it doesn't happen.  And a deep investigation shows that
      we uses a hash based solution even for a normal dir if the dir_index
      feature is enabled.
      
      So this patch just adds a new htree_inlinedir_to_tree for inline dir,
      and if we find that the hash index is supported, we will do like what
      we do for a dir block.
      Reported-by: NZach Brown <zab@redhat.com>
      Signed-off-by: NTao Ma <boyu.mt@taobao.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      8af0f082
  12. 03 3月, 2013 1 次提交
  13. 23 2月, 2013 1 次提交
  14. 29 1月, 2013 1 次提交
  15. 18 12月, 2012 1 次提交
  16. 11 12月, 2012 2 次提交
  17. 23 7月, 2012 1 次提交
  18. 30 4月, 2012 1 次提交
  19. 20 3月, 2012 1 次提交
  20. 19 3月, 2012 1 次提交
  21. 21 2月, 2012 1 次提交
  22. 11 1月, 2011 1 次提交
  23. 20 12月, 2010 1 次提交
  24. 28 10月, 2010 1 次提交
    • T
      ext4: improve llseek error handling for overly large seek offsets · e0d10bfa
      Toshiyuki Okajima 提交于
      The llseek system call should return EINVAL if passed a seek offset
      which results in a write error.  What this maximum offset should be
      depends on whether or not the huge_file file system feature is set,
      and whether or not the file is extent based or not.
      
      
      If the file has no "EXT4_EXTENTS_FL" flag, the maximum size which can be 
      written (write systemcall) is different from the maximum size which can be 
      sought (lseek systemcall).
      
      For example, the following 2 cases demonstrates the differences
      between the maximum size which can be written, versus the seek offset
      allowed by the llseek system call:
      
      #1: mkfs.ext3 <dev>; mount -t ext4 <dev>
      #2: mkfs.ext3 <dev>; tune2fs -Oextent,huge_file <dev>; mount -t ext4 <dev>
      
      Table. the max file size which we can write or seek
             at each filesystem feature tuning and file flag setting
      +============+===============================+===============================+
      | \ File flag|                               |                               |
      |      \     |     !EXT4_EXTENTS_FL          |        EXT4_EXTETNS_FL        |
      |case       \|                               |                               |
      +------------+-------------------------------+-------------------------------+
      | #1         |   write:      2194719883264   | write:       --------------   |
      |            |   seek:       2199023251456   | seek:        --------------   |
      +------------+-------------------------------+-------------------------------+
      | #2         |   write:      4402345721856   | write:       17592186044415   |
      |            |   seek:      17592186044415   | seek:        17592186044415   |
      +------------+-------------------------------+-------------------------------+
      
      The differences exist because ext4 has 2 maxbytes which are sb->s_maxbytes
      (= extent-mapped maxbytes) and EXT4_SB(sb)->s_bitmap_maxbytes (= block-mapped 
      maxbytes).  Although generic_file_llseek uses only extent-mapped maxbytes.
      (llseek of ext4_file_operations is generic_file_llseek which uses
      sb->s_maxbytes.)
      
      Therefore we create ext4 llseek function which uses 2 maxbytes.
      
      The new own function originates from generic_file_llseek().
      If the file flag, "EXT4_EXTENTS_FL" is not set, the function alters 
      inode->i_sb->s_maxbytes into EXT4_SB(inode->i_sb)->s_bitmap_maxbytes.
      Signed-off-by: NToshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      e0d10bfa
  25. 27 7月, 2010 3 次提交
  26. 14 6月, 2010 1 次提交
  27. 17 5月, 2010 3 次提交
  28. 05 3月, 2010 1 次提交
  29. 02 3月, 2010 1 次提交
  30. 16 2月, 2010 1 次提交
  31. 14 5月, 2009 2 次提交
  32. 15 2月, 2009 1 次提交
    • W
      ext4: New rec_len encoding for very large blocksizes · 3d0518f4
      Wei Yongjun 提交于
      The rec_len field in the directory entry is 16 bits, so to encode
      blocksizes larger than 64k becomes problematic.  This patch allows us
      to supprot block sizes up to 256k, by using the low 2 bits to extend
      the range of rec_len to 2**18-1 (since valid rec_len sizes must be a
      multiple of 4).  We use the convention that a rec_len of 0 or 65535
      means the filesystem block size, for compatibility with older kernels.
      
      It's unlikely we'll see VM pages of up to 256k, but at some point we
      might find that the Linux VM has been enhanced to support filesystem
      block sizes > than the VM page size, at which point it might be useful
      for some applications to allow very large filesystem block sizes.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      3d0518f4
  33. 06 1月, 2009 1 次提交