11 Oct, 2011

1 commit


23 Dec, 2009

2 commits


09 Jan, 2009

2 commits

  • * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (57 commits)
    jbd2: Fix oops in jbd2_journal_init_inode() on corrupted fs
    ext4: Remove "extents" mount option
    block: Add Kconfig help which notes that ext4 needs CONFIG_LBD
    ext4: Make printk's consistently prefixed with "EXT4-fs: "
    ext4: Add sanity checks for the superblock before mounting the filesystem
    ext4: Add mount option to set kjournald's I/O priority
    jbd2: Submit writes to the journal using WRITE_SYNC
    jbd2: Add pid and journal device name to the "kjournald2 starting" message
    ext4: Add markers for better debuggability
    ext4: Remove code to create the journal inode
    ext4: provide function to release metadata pages under memory pressure
    ext3: provide function to release metadata pages under memory pressure
    add releasepage hooks to block devices which can be used by file systems
    ext4: Fix s_dirty_blocks_counter if block allocation failed with nodelalloc
    ext4: Init the complete page while building buddy cache
    ext4: Don't allow new groups to be added during block allocation
    ext4: mark the blocks/inode bitmap beyond end of group as used
    ext4: Use new buffer_head flag to check uninit group bitmaps initialization
    ext4: Fix the race between read_inode_bitmap() and ext4_new_inode()
    ext4: code cleanup
    ...

    Linus Torvalds
     
  • As spotted by kmemtrace, struct ext3_sb_info is 17152 bytes on 64-bit
    which makes it a very bad fit for SLAB allocators. The culprit of the
    wasted memory is ->s_blockgroup_lock which can be as big as 16 KB when
    NR_CPUS >= 32.

    To fix that, allocate ->s_blockgroup_lock, which fits nicely in a order 2
    page in the worst case, separately. This shinks down struct ext3_sb_info
    enough to fit a 1 KB slab cache so now we allocate 16 KB + 1 KB instead of
    32 KB saving 15 KB of memory.

    Acked-by: Andreas Dilger
    Signed-off-by: Pekka Enberg
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pekka Enberg
     

05 Jan, 2009

1 commit

  • As suggested by Andreas Dilger, introduce a bgl_lock_ptr() helper in
    and add separate sb_bgl_lock() helpers to
    filesystem specific header files to break the hidden dependency to
    struct ext[234]_sb_info.

    Also, while at it, convert the macros to static inlines to try make up
    for all the times I broke Andrew Morton's tree.

    Acked-by: Andreas Dilger
    Signed-off-by: Pekka Enberg
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pekka Enberg
     

29 Oct, 2008

1 commit

  • The original ext3 hash algorithms assumed that variables of type char
    were signed, as God and K&R intended. Unfortunately, this assumption
    is not true on some architectures. Userspace support for marking
    filesystems with non-native signed/unsigned chars was added two years
    ago, but the kernel-side support was never added (until now).

    Signed-off-by: "Theodore Ts'o"
    Cc: akpm@linux-foundation.org
    Cc: linux-kernel@vger.kernel.org

    Theodore Ts'o
     

17 Oct, 2007

1 commit


17 Jul, 2007

1 commit

  • This is a patch that speeds up statfs. It is very simple - the "overhead"
    calculation, which takes a huge amount of time for large filesystems, never
    changes unless the size of the filesystem itself changes. That means we can
    store it in memory and only recalculate if the filesystem has been resized
    (almost never).

    It also fixes a minor problem that we never update the on-disk superblock free
    blocks/inodes counts until the filesystem is unmounted. While not fatal, we
    may as well update that on disk when we have the information, and it makes
    things like debugfs and dumpe2fs report a bit more accurate info.

    Signed-off-by: Badari Pulavarty
    Signed-off-by: Andreas Dilger
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Badari Pulavarty
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds