kernel/git/stable/linux.git/fs/ext4/ialloc.c, branch linux-2.6.29.y

ext4: really print the find_group_flex fallback warning only once

2009-06-15T16:40:35+00:00

(cherry picked from commit 6b82f3cb2d480b7714eb0ff61aee99c22160389e) Missing braces caused the warning to print more than once. Signed-Off-By: Chuck Ebbert Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: tighten restrictions on inode flags

2009-06-15T16:40:22+00:00

(cherry picked from commit 2dc6b0d48ca0599837df21b14bb8393d0804af57) At the moment there are few restrictions on which flags may be set on which inodes. Specifically DIRSYNC may only be set on directories and IMMUTABLE and APPEND may not be set on links. Tighten that to disallow TOPDIR being set on non-directories and only NODUMP and NOATIME to be set on non-regular file, non-directories. Introduces a flags masking function which masks flags based on mode and use it during inode creation and when flags are set via the ioctl to facilitate future consistency. Signed-off-by: Duane Griffin Acked-by: Andreas Dilger Cc: Signed-off-by: Andrew Morton Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: don't inherit inappropriate inode flags from parent

2009-06-15T16:40:22+00:00

(cherry picked from commit 8fa43a81b97853fc69417bb6054182e78f95cbeb) At present INDEX and EXTENTS are the only flags that new ext4 inodes do NOT inherit from their parent. In addition prevent the flags DIRTY, ECOMPR, IMAGIC, TOPDIR, HUGE_FILE and EXT_MIGRATE from being inherited. List inheritable flags explicitly to prevent future flags from accidentally being inherited. This fixes the TOPDIR flag inheritance bug reported at http://bugzilla.kernel.org/show_bug.cgi?id=9866. Signed-off-by: Duane Griffin Acked-by: Andreas Dilger Cc: Signed-off-by: Andrew Morton Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

ext4: Print the find_group_flex() warning only once

2009-03-12T16:20:01+00:00

This is a short-term warning, and even printk_ratelimit() can result in too much noise in system logs. So only print it once as a warning. Signed-off-by: "Theodore Ts'o"

ext4: fix ext4_free_inode() vs. ext4_claim_inode() race

2009-03-04T23:38:18+00:00

I was seeing fsck errors on inode bitmaps after a 4 thread dbench run on a 4 cpu machine: Inode bitmap differences: -50736 -(50752--50753) etc... I believe that this is because ext4_free_inode() uses atomic bitops, and although ext4_new_inode() *used* to also use atomic bitops for synchronization, commit 393418676a7602e1d7d3f6e560159c65c8cbd50e changed this to use the sb_bgl_lock, so that we could also synchronize against read_inode_bitmap and initialization of uninit inode tables. However, that change left ext4_free_inode using atomic bitops, which I think leaves no synchronization between setting & unsetting bits in the inode table. The below patch fixes it for me, although I wonder if we're getting at all heavy-handed with this spinlock... Signed-off-by: Eric Sandeen Reviewed-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o"

ext4: Add fallback for find_group_flex

2009-02-21T17:13:24+00:00

This is a workaround for find_group_flex() which badly needs to be replaced. One of its problems (besides ignoring the Orlov algorithm) is that it is a bit hyperactive about returning failure under suspicious circumstances. This can lead to spurious ENOSPC failures even when there are inodes still available. Work around this for now by retrying the search using find_group_other() if find_group_flex() returns -1. If find_group_other() succeeds when find_group_flex() has failed, log a warning message. A better block/inode allocator that will fix this problem for real has been queued up for the next merge window. Signed-off-by: "Theodore Ts'o"

ext4: Remove "extents" mount option

2009-01-06T19:53:16+00:00

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: "Theodore Ts'o"

ext4: Add markers for better debuggability

2009-01-04T01:03:21+00:00

Signed-off-by: "Theodore Ts'o"

ext4: mark the blocks/inode bitmap beyond end of group as used

2009-01-06T02:46:04+00:00

We need to mark the block/inode bitmap beyond the end of the group with '1'. Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Cc: stable@kernel.org

ext4: Use new buffer_head flag to check uninit group bitmaps initialization

2009-01-06T02:49:55+00:00

For uninit block group, the on-disk bitmap is not initialized. That implies we cannot depend on the uptodate flag on the bitmap buffer_head to find bitmap validity. Use a new buffer_head flag which would be set after we properly initialize the bitmap. This also prevents (re-)initializing the uninit group bitmap every time we call ext4_read_block_bitmap(). Signed-off-by: Aneesh Kumar K.V Signed-off-by: "Theodore Ts'o" Cc: stable@kernel.org