24 Jun, 2005

1 commit


19 May, 2005

1 commit

  • Avoid console spam with ext3 aborted journal.

    ext3 usually reports error conditions that it detects in its environment.
    But when its journal gets aborted due to such errors, it can sometimes
    continue to report that condition forever, spamming the console to such
    an extent that the initial first cause of the journal abort can be lost.

    When the journal aborts, we put the filesystem into readonly mode. Most
    subsequent filesystem operations will get rejected immediately by checks
    for MS_RDONLY either in the filesystem or in the VFS. But some paths do
    not have such checks --- for example, if we continue to write to a file
    handle that was opened before the fs went readonly. (We only check for
    the ROFS condition when the file is first opened.) In these cases, we
    can continue to generate log errors similar to

    EXT3-fs error (device $DEV) in start_transaction: Journal has aborted

    for each subsequent write.

    There is really no point in generating these errors after the initial
    error has been fully reported. Specifically, if we're starting a
    completely new filesystem operation, and the filesystem is *already*
    readonly (ie. the ext3 layer has already detected and handled the
    underlying jbd abort), and we see an EROFS error, then there is simply
    no point in reporting it again.

    Signed-off-by: Stephen Tweedie
    Signed-off-by: Linus Torvalds

    Stephen Tweedie
     

06 May, 2005

1 commit


01 May, 2005

1 commit

  • The extra race-with-truncate-then-retry logic around
    ext3_get_block_handle(), which was inherited from ext2, becomes unecessary
    for ext3, since we have already obtained the ei->truncate_sem in
    ext3_get_block_handle() before calling ext3_alloc_branch(). The
    ei->truncate_sem is already there to block concurrent truncate and block
    allocation on the same inode. So the inode's indirect addressing tree
    won't be changed after we grab that semaphore.

    We could, after get the semaphore, re-verify the branch is up-to-date or
    not. If it has been changed, then get the updated branch. If we still
    need block allocation, we will have a safe version of the branch to work
    with in the ext3_find_goal()/ext3_splice_branch().

    The code becomes more readable after remove those retry logic. The patch
    also clean up some gotos in ext3_get_block_handle() to make it more
    readable.

    Signed-off-by: Mingming Cao
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mingming Cao
     

17 Apr, 2005

2 commits

  • )

    From: Andreas Gruenbacher

    ext[23]_get_acl will return an error when reading the attribute fails or
    out-of-memory occurs. Catch this case.

    Signed-off-by: Andreas Gruenbacher
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     
  • 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