Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4

safest. If ``data=writeback``, dirty data blocks are not flushed to the

disk before the metadata are written to disk through the journal.

In case of ``data=ordered`` mode, Ext4 also supports fast commits which

help reduce commit latency significantly. The default ``data=ordered``

mode works by logging metadata blocks to the journal. In fast commit

mode, Ext4 only stores the minimal delta needed to recreate the

affected metadata in fast commit space that is shared with JBD2.

Once the fast commit area fills in or if fast commit is not possible

or if JBD2 commit timer goes off, Ext4 performs a traditional full commit.

A full commit invalidates all the fast commits that happened before

it and thus it makes the fast commit area empty for further fast

commits. This feature needs to be enabled at mkfs time.

The journal inode is typically inode 8. The first 68 bytes of the

journal inode are replicated in the ext4 superblock. The journal itself

is normal (but hidden) file within the filesystem. The file usually

     - h\_commit\_nsec

     - Nanoseconds component of the above timestamp.

Fast commits

~~~~~~~~~~~~

Fast commit area is organized as a log of tag length values. Each TLV has

a ``struct ext4_fc_tl`` in the beginning which stores the tag and the length

of the entire field. It is followed by variable length tag specific value.

Here is the list of supported tags and their meanings:

.. list-table::

   :widths: 8 20 20 32

   :header-rows: 1

   * - Tag

     - Meaning

     - Value struct

     - Description

   * - EXT4_FC_TAG_HEAD

     - Fast commit area header

     - ``struct ext4_fc_head``

     - Stores the TID of the transaction after which these fast commits should

       be applied.

   * - EXT4_FC_TAG_ADD_RANGE

     - Add extent to inode

     - ``struct ext4_fc_add_range``

     - Stores the inode number and extent to be added in this inode

   * - EXT4_FC_TAG_DEL_RANGE

     - Remove logical offsets to inode

     - ``struct ext4_fc_del_range``

     - Stores the inode number and the logical offset range that needs to be

       removed

   * - EXT4_FC_TAG_CREAT

     - Create directory entry for a newly created file

     - ``struct ext4_fc_dentry_info``

     - Stores the parent inode number, inode number and directory entry of the

       newly created file

   * - EXT4_FC_TAG_LINK

     - Link a directory entry to an inode

     - ``struct ext4_fc_dentry_info``

     - Stores the parent inode number, inode number and directory entry

   * - EXT4_FC_TAG_UNLINK

     - Unlink a directory entry of an inode

     - ``struct ext4_fc_dentry_info``

     - Stores the parent inode number, inode number and directory entry

   * - EXT4_FC_TAG_PAD

     - Padding (unused area)

     - None

     - Unused bytes in the fast commit area.

   * - EXT4_FC_TAG_TAIL

     - Mark the end of a fast commit

     - ``struct ext4_fc_tail``

     - Stores the TID of the commit, CRC of the fast commit of which this tag

       represents the end of

if you allow unprivileged userspace to trigger codepaths containing

these calls.

Fast commits

~~~~~~~~~~~~

JBD2 to also allows you to perform file-system specific delta commits known as

fast commits. In order to use fast commits, you first need to call

:c:func:`jbd2_fc_init` and tell how many blocks at the end of journal

area should be reserved for fast commits. Along with that, you will also need

to set following callbacks that perform correspodning work:

`journal->j_fc_cleanup_cb`: Cleanup function called after every full commit and

fast commit.

`journal->j_fc_replay_cb`: Replay function called for replay of fast commit

blocks.

File system is free to perform fast commits as and when it wants as long as it

gets permission from JBD2 to do so by calling the function

:c:func:`jbd2_fc_begin_commit()`. Once a fast commit is done, the client

file  system should tell JBD2 about it by calling

:c:func:`jbd2_fc_end_commit()`. If file system wants JBD2 to perform a full

commit immediately after stopping the fast commit it can do so by calling

:c:func:`jbd2_fc_end_commit_fallback()`. This is useful if fast commit operation

fails for some reason and the only way to guarantee consistency is for JBD2 to

perform the full traditional commit.

JBD2 helper functions to manage fast commit buffers. File system can use

:c:func:`jbd2_fc_get_buf()` and :c:func:`jbd2_fc_wait_bufs()` to allocate

and wait on IO completion of fast commit buffers.

Currently, only Ext4 implements fast commits. For details of its implementation

of fast commits, please refer to the top level comments in

fs/ext4/fast_commit.c.

Summary

~~~~~~~

		indirect.o inline.o inode.o ioctl.o mballoc.o migrate.o \

		mmp.o move_extent.o namei.o page-io.o readpage.o resize.o \

		super.o symlink.o sysfs.o xattr.o xattr_hurd.o xattr_trusted.o \

		xattr_user.o

		xattr_user.o fast_commit.o

ext4-$(CONFIG_EXT4_FS_POSIX_ACL)	+= acl.o

ext4-$(CONFIG_EXT4_FS_SECURITY)		+= xattr_security.o

	handle = ext4_journal_start(inode, EXT4_HT_XATTR, credits);

	if (IS_ERR(handle))

		return PTR_ERR(handle);

	ext4_fc_start_update(inode);

	if ((type == ACL_TYPE_ACCESS) && acl) {

		error = posix_acl_update_mode(inode, &mode, &acl);

	}

out_stop:

	ext4_journal_stop(handle);

	ext4_fc_stop_update(inode);

	if (error == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries))

		goto retry;

	return error;

				      struct buffer_head *bh)

{

	ext4_fsblk_t	blk;

	struct ext4_group_info *grp = ext4_get_group_info(sb, block_group);

	struct ext4_group_info *grp;

	if (EXT4_SB(sb)->s_mount_state & EXT4_FC_REPLAY)

		return 0;

	grp = ext4_get_group_info(sb, block_group);

	if (buffer_verified(bh))

		return 0;

	 */

	set_buffer_new(bh);

	trace_ext4_read_block_bitmap_load(sb, block_group, ignore_locked);

	bh->b_end_io = ext4_end_bitmap_read;

	get_bh(bh);

	submit_bh(REQ_OP_READ, REQ_META | REQ_PRIO |

		  (ignore_locked ? REQ_RAHEAD : 0), bh);

	ext4_read_bh_nowait(bh, REQ_META | REQ_PRIO |

			    (ignore_locked ? REQ_RAHEAD : 0),

			    ext4_end_bitmap_read);

	return bh;

verify:

	err = ext4_validate_block_bitmap(sb, desc, block_group, bh);