Eric Lee / smarc-fsl-linux-kernel

04 May, 2011

1 commit

25 May, 2010

1 commit

14 Oct, 2009

1 commit

  • 257c62e1b   Btrfs: avoid tree log commit when there are no changes ... Browse Code »

    rpm has a habit of running fdatasync when the file hasn't
    changed. We already detect if a file hasn't been changed
    in the current transaction but it might have been sent to
    the tree-log in this transaction and not changed since
    the last call to fsync.

    In this case, we want to avoid a tree log sync, which includes
    a number of synchronous writes and barriers. This commit
    extends the existing tracking of the last transaction to change
    a file to also track the last sub-transaction.

    The end result is that rpm -ivh and -Uvh are roughly twice as fast,
    and on par with ext3.

    Signed-off-by: Chris Mason

    Chris Mason
     

25 Mar, 2009

1 commit

  • 12fcfd22f   Btrfs: tree logging unlink/rename fixes ... Browse Code »

    The tree logging code allows individual files or directories to be logged
    without including operations on other files and directories in the FS.
    It tries to commit the minimal set of changes to disk in order to
    fsync the single file or directory that was sent to fsync or O_SYNC.

    The tree logging code was allowing files and directories to be unlinked
    if they were part of a rename operation where only one directory
    in the rename was in the fsync log. This patch adds a few new rules
    to the tree logging.

    1) on rename or unlink, if the inode being unlinked isn't in the fsync
    log, we must force a full commit before doing an fsync of the directory
    where the unlink was done. The commit isn't done during the unlink,
    but it is forced the next time we try to log the parent directory.

    Solution: record transid of last unlink/rename per directory when the
    directory wasn't already logged. For renames this is only done when
    renaming to a different directory.

    mkdir foo/some_dir
    normal commit
    rename foo/some_dir foo2/some_dir
    mkdir foo/some_dir
    fsync foo/some_dir/some_file

    The fsync above will unlink the original some_dir without recording
    it in its new location (foo2). After a crash, some_dir will be gone
    unless the fsync of some_file forces a full commit

    2) we must log any new names for any file or dir that is in the fsync
    log. This way we make sure not to lose files that are unlinked during
    the same transaction.

    2a) we must log any new names for any file or dir during rename
    when the directory they are being removed from was logged.

    2a is actually the more important variant. Without the extra logging
    a crash might unlink the old name without recreating the new one

    3) after a crash, we must go through any directories with a link count
    of zero and redo the rm -rf

    mkdir f1/foo
    normal commit
    rm -rf f1/foo
    fsync(f1)

    The directory f1 was fully removed from the FS, but fsync was never
    called on f1, only its parent dir. After a crash the rm -rf must
    be replayed. This must be able to recurse down the entire
    directory tree. The inode link count fixup code takes care of the
    ugly details.

    Signed-off-by: Chris Mason

    Chris Mason
     

25 Sep, 2008

1 commit