1. 04 6月, 2009 1 次提交
  2. 25 5月, 2009 1 次提交
  3. 18 5月, 2009 2 次提交
  4. 03 5月, 2009 1 次提交
  5. 02 5月, 2009 3 次提交
  6. 26 4月, 2009 2 次提交
  7. 01 5月, 2009 1 次提交
    • T
      ext4: ext4_mark_recovery_complete() doesn't need to use lock_super · a63c9eb2
      Theodore Ts'o 提交于
      The function ext4_mark_recovery_complete() is called from two call
      paths: either (a) while mounting the filesystem, in which case there's
      no danger of any other CPU calling write_super() until the mount is
      completed, and (b) while remounting the filesystem read-write, in
      which case the fs core has already locked the superblock.  This also
      allows us to take out a very vile unlock_super()/lock_super() pair in
      ext4_remount().
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a63c9eb2
  8. 26 4月, 2009 1 次提交
  9. 01 5月, 2009 1 次提交
    • T
      ext4: Avoid races caused by on-line resizing and SMP memory reordering · 8df9675f
      Theodore Ts'o 提交于
      Ext4's on-line resizing adds a new block group and then, only at the
      last step adjusts s_groups_count.  However, it's possible on SMP
      systems that another CPU could see the updated the s_group_count and
      not see the newly initialized data structures for the just-added block
      group.  For this reason, it's important to insert a SMP read barrier
      after reading s_groups_count and before reading any (for example) the
      new block group descriptors allowed by the increased value of
      s_groups_count.
      
      Unfortunately, we rather blatently violate this locking protocol
      documented in fs/ext4/resize.c.  Fortunately, (1) on-line resizes
      happen relatively rarely, and (2) it seems rare that the filesystem
      code will immediately try to use just-added block group before any
      memory ordering issues resolve themselves.  So apparently problems
      here are relatively hard to hit, since ext3 has been vulnerable to the
      same issue for years with no one apparently complaining.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      8df9675f
  10. 02 5月, 2009 1 次提交
  11. 01 5月, 2009 2 次提交
    • T
      ext4: Fix and simplify s_dirt handling · 7234ab2a
      Theodore Ts'o 提交于
      The s_dirt flag wasn't completely handled correctly, but it didn't
      really matter when journalling was enabled.  It turns out that when
      ext4 runs without a journal, we don't clear s_dirt in places where we
      should have, with the result that the high-level write_super()
      function was writing the superblock when it wasn't necessary.
      
      So we fix this by making ext4_commit_super() clear the s_dirt flag,
      and removing many of the other places where s_dirt is manipulated.
      When journalling is enabled, the s_dirt flag might be left set more
      often, but s_dirt really doesn't matter when journalling is enabled.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      7234ab2a
    • T
      ext4: Simplify ext4_commit_super()'s function signature · e2d67052
      Theodore Ts'o 提交于
      The ext4_commit_super() function took both a struct super_block * and
      a struct ext4_super_block *, but the struct ext4_super_block can be
      derived from the struct super_block.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      e2d67052
  12. 25 4月, 2009 1 次提交
  13. 28 4月, 2009 1 次提交
    • T
      ext4: Fallback to vmalloc if kmalloc can't allocate s_flex_groups array · c5ca7c76
      Theodore Ts'o 提交于
      For very large filesystems, the s_flex_groups array can get quite big.
      For example, a filesystem that can be resized up to 16TB will have
      8192 flex groups (assuming the default flex_bg size of 16), so the
      array is 96k, which is *very* marginal for kmalloc().  On the other
      hand, a 160GB filesystem without the resize_inode feature will only
      require 960 bytes.  So we try to allocate the array first using
      kmalloc(), and if that fails, we'll try to use vmalloc() instead.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      c5ca7c76
  14. 08 4月, 2009 1 次提交
  15. 28 3月, 2009 1 次提交
    • T
      ext4: Regularize mount options · 06705bff
      Theodore Ts'o 提交于
      Add support for using the mount options "barrier" and "nobarrier", and
      "auto_da_alloc" and "noauto_da_alloc", which is more consistent than
      "barrier=<0|1>" or "auto_da_alloc=<0|1>".  Most other ext3/ext4 mount
      options use the foo/nofoo naming convention.  We allow the old forms
      of these mount options for backwards compatibility.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      06705bff
  16. 26 3月, 2009 3 次提交
  17. 17 3月, 2009 1 次提交
    • T
      ext4: Add auto_da_alloc mount option · afd4672d
      Theodore Ts'o 提交于
      Add a mount option which allows the user to disable automatic
      allocation of blocks whose allocation by delayed allocation when the
      file was originally truncated or when the file is renamed over an
      existing file.  This feature is intended to save users from the
      effects of naive application writers, but it reduces the effectiveness
      of the delayed allocation code.  This mount option disables this
      safety feature, which may be desirable for prodcutions systems where
      the risk of unclean shutdowns or unexpected system crashes is low.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      afd4672d
  18. 05 3月, 2009 2 次提交
  19. 31 3月, 2009 2 次提交
  20. 01 3月, 2009 1 次提交
  21. 28 2月, 2009 1 次提交
  22. 16 2月, 2009 1 次提交
  23. 10 2月, 2009 1 次提交
  24. 10 1月, 2009 1 次提交
    • T
      filesystem freeze: add error handling of write_super_lockfs/unlockfs · c4be0c1d
      Takashi Sato 提交于
      Currently, ext3 in mainline Linux doesn't have the freeze feature which
      suspends write requests.  So, we cannot take a backup which keeps the
      filesystem's consistency with the storage device's features (snapshot and
      replication) while it is mounted.
      
      In many case, a commercial filesystem (e.g.  VxFS) has the freeze feature
      and it would be used to get the consistent backup.
      
      If Linux's standard filesystem ext3 has the freeze feature, we can do it
      without a commercial filesystem.
      
      So I have implemented the ioctls of the freeze feature.
      I think we can take the consistent backup with the following steps.
      1. Freeze the filesystem with the freeze ioctl.
      2. Separate the replication volume or create the snapshot
         with the storage device's feature.
      3. Unfreeze the filesystem with the unfreeze ioctl.
      4. Take the backup from the separated replication volume
         or the snapshot.
      
      This patch:
      
      VFS:
      Changed the type of write_super_lockfs and unlockfs from "void"
      to "int" so that they can return an error.
      Rename write_super_lockfs and unlockfs of the super block operation
      freeze_fs and unfreeze_fs to avoid a confusion.
      
      ext3, ext4, xfs, gfs2, jfs:
      Changed the type of write_super_lockfs and unlockfs from "void"
      to "int" so that write_super_lockfs returns an error if needed,
      and unlockfs always returns 0.
      
      reiserfs:
      Changed the type of write_super_lockfs and unlockfs from "void"
      to "int" so that they always return 0 (success) to keep a current behavior.
      Signed-off-by: NTakashi Sato <t-sato@yk.jp.nec.com>
      Signed-off-by: NMasayuki Hamaguchi <m-hamaguchi@ys.jp.nec.com>
      Cc: <xfs-masters@oss.sgi.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c4be0c1d
  25. 07 1月, 2009 1 次提交
    • T
      ext4: Remove "extents" mount option · 83982b6f
      Theodore Ts'o 提交于
      This mount option is largely superfluous, and in fact the way it was
      implemented was buggy; if a filesystem which did not have the extents
      feature flag was mounted -o extents, the filesystem would attempt to
      create and use extents-based file even though the extents feature flag
      was not eabled.  The simplest thing to do is to nuke the mount option
      entirely.  It's not all that useful to force the non-creation of new
      extent-based files if the filesystem can support it.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      83982b6f
  26. 06 1月, 2009 1 次提交
  27. 07 1月, 2009 1 次提交
  28. 06 1月, 2009 3 次提交
  29. 07 1月, 2009 1 次提交