12 Aug, 2008

1 commit


11 Aug, 2008

2 commits


05 Aug, 2008

1 commit

  • Converting page lock to new locking bitops requires a change of page flag
    operation naming, so we might as well convert it to something nicer
    (!TestSetPageLocked_Lock => trylock_page, SetPageLocked => set_page_locked).

    This also facilitates lockdeping of page lock.

    Signed-off-by: Nick Piggin
    Acked-by: KOSAKI Motohiro
    Acked-by: Peter Zijlstra
    Acked-by: Andrew Morton
    Acked-by: Benjamin Herrenschmidt
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

01 Aug, 2008

1 commit

  • In ordered mode, the current jbd2 aborts the journal if a file data buffer
    has an error. But this behavior is unintended, and we found that it has
    been adopted accidentally.

    This patch undoes it and just calls printk() instead of aborting the
    journal. Unlike a similar patch for ext3/jbd, file data buffers are
    written via generic_writepages(). But we also need to set AS_EIO
    into their mappings because wait_on_page_writeback_range() clears
    AS_EIO before a user process sees it.

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

    Hidehiro Kawai
     

27 Jul, 2008

1 commit


14 Jul, 2008

1 commit

  • journal_try_to_free_buffers() could race with jbd commit transaction
    when the later is holding the buffer reference while waiting for the
    data buffer to flush to disk. If the caller of
    journal_try_to_free_buffers() request tries hard to release the buffers,
    it will treat the failure as error and return back to the caller. We
    have seen the directo IO failed due to this race. Some of the caller of
    releasepage() also expecting the buffer to be dropped when passed with
    GFP_KERNEL mask to the releasepage()->journal_try_to_free_buffers().

    With this patch, if the caller is passing the GFP_KERNEL to indicating
    this call could wait, in case of try_to_free_buffers() failed, let's
    waiting for journal_commit_transaction() to finish commit the current
    committing transaction , then try to free those buffers again with
    journal locked.

    Signed-off-by: Mingming Cao
    Reviewed-by: Badari Pulavarty
    Signed-off-by: "Theodore Ts'o"

    Mingming Cao
     

12 Jul, 2008

4 commits

  • This provides a new ordered mode implementation which gets rid of using
    buffer heads to enforce the ordering between metadata change with the
    related data chage. Instead, in the new ordering mode, it keeps track
    of all of the inodes touched by each transaction on a list, and when
    that transaction is committed, it flushes all of the dirty pages for
    those inodes. In addition, the new ordered mode reverses the lock
    ordering of the page lock and transaction lock, which provides easier
    support for delayed allocation.

    Signed-off-by: Aneesh Kumar K.V
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Aneesh Kumar K.V
     
  • Signed-off-by: Jan Kara

    Jan Kara
     
  • This patch adds necessary framework into JBD2 to be able to track inodes
    with each transaction and write-out their dirty data during transaction
    commit time.

    This new ordered mode brings all sorts of advantages such as possibility
    to get rid of journal heads and buffer heads for data buffers in ordered
    mode, better ordering of writes on transaction commit, simplification of
    some JBD code, no more anonymous pages when truncate of data being
    committed happens. Also with this new ordered mode, delayed allocation
    on ordered mode is much simpler.

    Signed-off-by: Jan Kara

    Jan Kara
     
  • Carlo Wood has demonstrated that it's possible to recover deleted
    files from the journal. Something that will make this easier is if we
    can put the time of the commit into commit block.

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

    Theodore Ts'o
     

07 Jun, 2008

1 commit


04 Jun, 2008

1 commit


26 May, 2008

1 commit


16 May, 2008

1 commit


13 May, 2008

1 commit

  • bdevname() fills the buffer that it is given as a parameter, so calling
    strcpy() or snprintf() on the returned value is redundant (and probably not
    guaranteed to work - I don't think strcpy and snprintf support overlapping
    buffers.)

    Signed-off-by: Jean Delvare
    Cc: Stephen Tweedie
    Cc: Jens Axboe
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jean Delvare
     

30 Apr, 2008

1 commit

  • jbd2 debugfs and stats entries should only be created if cache initialisation
    is successful. At the moment they are being created unconditionally which
    will leave them dangling if cache (and hence module) initialisation fails.

    Signed-off-by: Duane Griffin
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Duane Griffin
     

29 Apr, 2008

1 commit


28 Apr, 2008

1 commit

  • Make revocation cache destruction safe to call if initialisation fails
    partially or entirely. This allows it to be used to cleanup in the case of
    initialisation failure, simplifying the code slightly.

    Signed-off-by: Duane Griffin
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Aneesh Kumar K.V

    Duane Griffin
     

17 Apr, 2008

6 commits

  • __FUNCTION__ is gcc-specific, use __func__

    Signed-off-by: Harvey Harrison
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: "Theodore Ts'o"

    Harvey Harrison
     
  • Fix kernel-doc notation in jbd2.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Mingming Cao
    Signed-off-by: Andrew Morton
    Signed-off-by: "Theodore Ts'o"

    Randy Dunlap
     
  • If an error occurs during jbd2 cache initialisation it is possible for the
    journal_head_cache to be NULL when jbd2_journal_destroy_journal_head_cache is
    called. Replace the J_ASSERT with an if block to handle the situation
    correctly.

    Note that even with this fix things will break badly if jbd2 is statically
    compiled in and cache initialisation fails.

    Signed-off-by: Duane Griffin
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Duane Griffin
     
  • The revocation table initialisation/destruction code is repeated for each of
    the two revocation tables stored in the journal. Refactoring the duplicated
    code into functions is tidier, simplifies the logic in initialisation in
    particular, and slightly reduces the code size.

    There should not be any functional change.

    Signed-off-by: Duane Griffin
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Duane Griffin
     
  • There are several cases where the running transaction can get buffers
    added to its BJ_Metadata list which it never dirtied, which makes its
    t_nr_buffers counter end up larger than its t_outstanding_credits
    counter.

    This will cause issues when starting new transactions as while we are
    logging buffers we decrement t_outstanding_buffers, so when
    t_outstanding_buffers goes negative, we will report that we need less
    space in the journal than we actually need, so transactions will be
    started even though there may not be enough room for them. In the worst
    case scenario (which admittedly is almost impossible to reproduce) this
    will result in the journal running out of space.

    The fix is to only refile buffers from the committing transaction to the
    running transactions BJ_Modified list when b_modified is set on that
    journal, which is the only way to be sure if the running transaction has
    modified that buffer.

    This patch also fixes an accounting error in journal_forget, it is
    possible that we can call journal_forget on a buffer without having
    modified it, only gotten write access to it, so instead of freeing a
    credit, we only do so if the buffer was modified. The assert will help
    catch if this problem occurs. Without these two patches I could hit
    this assert within minutes of running postmark, with them this issue no
    longer arises.

    Cc:
    Cc: Jan Kara
    Signed-off-by: Josef Bacik
    Signed-off-by: Andrew Morton
    Signed-off-by: "Theodore Ts'o"

    Josef Bacik
     
  • Currently at the start of a journal commit we loop through all of the buffers
    on the committing transaction and clear the b_modified flag (the flag that is
    set when a transaction modifies the buffer) under the j_list_lock.

    The problem is that everywhere else this flag is modified only under the jbd2
    lock buffer flag, so it will race with a running transaction who could
    potentially set it, and have it unset by the committing transaction.

    This is also a big waste, you can have several thousands of buffers that you
    are clearing the modified flag on when you may not need to. This patch
    removes this code and instead clears the b_modified flag upon entering
    do_get_write_access/journal_get_create_access, so if that transaction does
    indeed use the buffer then it will be accounted for properly, and if it does
    not then we know we didn't use it.

    That will be important for the next patch in this series. Tested thoroughly
    by myself using postmark/iozone/bonnie++.

    Cc:
    Cc: Jan Kara
    Signed-off-by: Josef Bacik
    Signed-off-by: Andrew Morton
    Signed-off-by: "Theodore Ts'o"

    Josef Bacik
     

31 Mar, 2008

1 commit


20 Mar, 2008

1 commit

  • Fix a long-standing typo (predating git) that will cause data corruption if a
    journal data block needs unescaping. At the moment the wrong buffer head's
    data is being unescaped.

    To test this case mount a filesystem with data=journal, start creating and
    deleting a bunch of files containing only JBD2_MAGIC_NUMBER (0xc03b3998), then
    pull the plug on the device. Without this patch the files will contain zeros
    instead of the correct data after recovery.

    Signed-off-by: Duane Griffin
    Acked-by: Jan Kara
    Cc:
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Duane Griffin
     

10 Feb, 2008

1 commit

  • In JBD2 jbd2_journal_write_commit_record(), clear the buffer_ordered
    flag for the bh after barried IO has succeed. This prevents later, if
    the same buffer head were submitted to the underlying device, which has
    been reconfigured to not support barrier request, the JBD2 commit code
    could treat it as a normal IO (without barrier).

    This is a port from JBD/ext3 fix from Neil Brown.

    More details from Neil:

    Some devices - notably dm and md - can change their behaviour in
    response to BIO_RW_BARRIER requests. They might start out accepting
    such requests but on reconfiguration, they find out that they cannot
    any more. JBD2 deal with this by always testing if BIO_RW_BARRIER
    requests fail with EOPNOTSUPP, and retrying the write
    requests without the barrier (probably after waiting for any pending
    writes to complete).

    However there is a bug in the handling this in JBD2 for ext4 .

    When ext4/JBD2 to submit a BIO_RW_BARRIER request,
    it sets the buffer_ordered flag on the buffer head.
    If the request completes successfully, the flag STAYS SET.

    Other code might then write the same buffer_head after the device has
    been reconfigured to not accept barriers. This write will then fail,
    but the "other code" is not ready to handle EOPNOTSUPP errors and the
    error will be treated as fatal.

    Cc: Neil Brown
    Signed-off-by: Dave Kleikamp
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Dave Kleikamp
     

07 Feb, 2008

1 commit


05 Feb, 2008

3 commits

  • JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT needs to be checked with
    JBD2_HAS_INCOMPAT_FEATURE

    Signed-off-by: Aneesh Kumar K.V
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Aneesh Kumar K.V
     
  • With journal checksum patch we added asynchronous commits of journal
    commit headers, and accidentally dropped taking a reference on the
    buffer head.

    (Before the change, sync_dirty_buffer did the get_bh(). The associative
    put_bh is done by journal_wait_on_commit_record().)

    Signed-off-by: Aneesh Kumar K.V
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Aneesh Kumar K.V
     
  • The buffer head pointer passed to journal_wait_on_commit_record() could
    be NULL if the previous journal_submit_commit_record() failed or journal
    has already aborted.

    Looking at the jbd2 debug messages, before the oops happened, the jbd2
    is aborted due to trying to access the next log block beyond the end
    of device. This might be caused by using a corrupted image.

    We need to check the error returns from journal_submit_commit_record()
    and avoid calling journal_wait_on_commit_record() in the failure case.

    This addresses Kernel Bugzilla #9849

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

    Mingming Cao
     

30 Jan, 2008

1 commit

  • The break_lock data structure and code for spinlocks is quite nasty.
    Not only does it double the size of a spinlock but it changes locking to
    a potentially less optimal trylock.

    Put all of that under CONFIG_GENERIC_LOCKBREAK, and introduce a
    __raw_spin_is_contended that uses the lock data itself to determine whether
    there are waiters on the lock, to be used if CONFIG_GENERIC_LOCKBREAK is
    not set.

    Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
    decouple it from the spinlock implementation, and make it typesafe (rwlocks
    do not have any need_lockbreak sites -- why do they even get bloated up
    with that break_lock then?).

    Signed-off-by: Nick Piggin
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Nick Piggin
     

29 Jan, 2008

7 commits

  • Get rid of sparse related warnings from places that use integer as NULL
    pointer. (Ported from upstream ext3/jbd changes.)

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

    Mingming Cao
     
  • While "every 5 seconds" doesn't sound as a problem, there can be many
    of these (and these timers do add up over all the kernel). The "5
    second" wakeup isn't really timing sensitive; in addition even with
    rounding it'll still happen every 5 seconds (with the exception of the
    very first time, which is likely to be rounded up to somewhere closer
    to 6 seconds)

    (Ported from similar JBD patch made by Arjan van de Ven to
    fs/jbd/transaction.c)

    Cc: Arjan van de Ven
    Cc: Andrew Morton
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Mingming Cao
     
  • This patch marks slab allocations by jbd2 as short-lived in support of
    Mel Gorman's "Group short-lived and reclaimable kernel allocations"
    patch. (Ported from similar changes made to fs/jbd/journal.c and
    fs/jbd/revoke.c in Mel's patch.)

    Cc: Mel Gorman
    Cc: Andrew Morton
    Signed-off-by: Mingming Cao
    Signed-off-by: "Theodore Ts'o"

    Mingming Cao
     
  • Ported from similar patch for the jbd layer.

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

    Mingming Cao
     
  • The journal checksum feature adds two new flags i.e
    JBD2_FEATURE_INCOMPAT_ASYNC_COMMIT and JBD2_FEATURE_COMPAT_CHECKSUM.

    JBD2_FEATURE_CHECKSUM flag indicates that the commit block contains the
    checksum for the blocks described by the descriptor blocks.
    Due to checksums, writing of the commit record no longer needs to be
    synchronous. Now commit record can be sent to disk without waiting for
    descriptor blocks to be written to disk. This behavior is controlled
    using JBD2_FEATURE_ASYNC_COMMIT flag. Older kernels/e2fsck should not be
    able to recover the journal with _ASYNC_COMMIT hence it is made
    incompat.
    The commit header has been extended to hold the checksum along with the
    type of the checksum.

    For recovery in pass scan checksums are verified to ensure the sanity
    and completeness(in case of _ASYNC_COMMIT) of every transaction.

    Signed-off-by: Andreas Dilger
    Signed-off-by: Girish Shilamkar
    Signed-off-by: Dave Kleikamp
    Signed-off-by: Mingming Cao

    Girish Shilamkar
     
  • The patch below updates the jbd stats patch to 2.6.20/jbd2.
    The initial patch was posted by Alex Tomas in December 2005
    (http://marc.info/?l=linux-ext4&m=113538565128617&w=2).
    It provides statistics via procfs such as transaction lifetime and size.

    Sometimes, investigating performance problems, i find useful to have
    stats from jbd about transaction's lifetime, size, etc. here is a
    patch for review and inclusion probably.

    for example, stats after creation of 3M files in htree directory:

    [root@bob ~]# cat /proc/fs/jbd/sda/history
    R/C tid wait run lock flush log hndls block inlog ctime write drop close
    R 261 8260 2720 0 0 750 9892 8170 8187
    C 259 750 0 4885 1
    R 262 20 2200 10 0 770 9836 8170 8187
    R 263 30 2200 10 0 3070 9812 8170 8187
    R 264 0 5000 10 0 1340 0 0 0
    C 261 8240 3212 4957 0
    R 265 8260 1470 0 0 4640 9854 8170 8187
    R 266 0 5000 10 0 1460 0 0 0
    C 262 8210 2989 4868 0
    R 267 8230 1490 10 0 4440 9875 8171 8188
    R 268 0 5000 10 0 1260 0 0 0
    C 263 7710 2937 4908 0
    R 269 7730 1470 10 0 3330 9841 8170 8187
    R 270 0 5000 10 0 830 0 0 0
    C 265 8140 3234 4898 0
    C 267 720 0 4849 1
    R 271 8630 2740 20 0 740 9819 8170 8187
    C 269 800 0 4214 1
    R 272 40 2170 10 0 830 9716 8170 8187
    R 273 40 2280 0 0 3530 9799 8170 8187
    R 274 0 5000 10 0 990 0 0 0

    where,

    R - line for transaction's life from T_RUNNING to T_FINISHED
    C - line for transaction's checkpointing
    tid - transaction's id
    wait - for how long we were waiting for new transaction to start
    (the longest period journal_start() took in this transaction)
    run - real transaction's lifetime (from T_RUNNING to T_LOCKED
    lock - how long we were waiting for all handles to close
    (time the transaction was in T_LOCKED)
    flush - how long it took to flush all data (data=ordered)
    log - how long it took to write the transaction to the log
    hndls - how many handles got to the transaction
    block - how many blocks got to the transaction
    inlog - how many blocks are written to the log (block + descriptors)
    ctime - how long it took to checkpoint the transaction
    write - how many blocks have been written during checkpointing
    drop - how many blocks have been dropped during checkpointing
    close - how many running transactions have been closed to checkpoint this one

    all times are in msec.

    [root@bob ~]# cat /proc/fs/jbd/sda/info
    280 transaction, each upto 8192 blocks
    average:
    1633ms waiting for transaction
    3616ms running transaction
    5ms transaction was being locked
    1ms flushing data (in ordered mode)
    1799ms logging transaction
    11781 handles per transaction
    5629 blocks per transaction
    5641 logged blocks per transaction

    Signed-off-by: Johann Lombardi
    Signed-off-by: Mariusz Kozlowski
    Signed-off-by: Mingming Cao
    Signed-off-by: Eric Sandeen

    Johann Lombardi
     
  • Before we start committing a transaction, we call
    __journal_clean_checkpoint_list() to cleanup transaction's written-back
    buffers.

    If this call happens to remove all of them (and there were already some
    buffers), __journal_remove_checkpoint() will decide to free the transaction
    because it isn't (yet) a committing transaction and soon we fail some
    assertion - the transaction really isn't ready to be freed :).

    We change the check in __journal_remove_checkpoint() to free only a
    transaction in T_FINISHED state. The locking there is subtle though (as
    everywhere in JBD ;(). We use j_list_lock to protect the check and a
    subsequent call to __journal_drop_transaction() and do the same in the end
    of journal_commit_transaction() which is the only place where a transaction
    can get to T_FINISHED state.

    Probably I'm too paranoid here and such locking is not really necessary -
    checkpoint lists are processed only from log_do_checkpoint() where a
    transaction must be already committed to be processed or from
    __journal_clean_checkpoint_list() where kjournald itself calls it and thus
    transaction cannot change state either. Better be safe if something
    changes in future...

    Signed-off-by: Jan Kara
    Cc:
    Signed-off-by: Andrew Morton

    Jan Kara