From: xfs@oss.sgi.com
To: xfs@oss.sgi.com
Subject: [XFS updates] XFS development tree branch, xfs-async-aio-extend, created. xfs-for-linus-v3.14-rc1-2-12923-g9862f62
Date: Sun, 9 Feb 2014 21:17:22 -0600 (CST) [thread overview]
Message-ID: <20140210031723.8C7C27F55@oss.sgi.com> (raw)
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".
The branch, xfs-async-aio-extend has been created
at 9862f62faba8c279ac07415a6f610041116fbdc0 (commit)
- Log -----------------------------------------------------------------
commit 9862f62faba8c279ac07415a6f610041116fbdc0
Author: Christoph Hellwig <hch@infradead.org>
Date: Mon Feb 10 10:28:04 2014 +1100
xfs: allow appending aio writes
XFS can easily support appending aio writes by ensuring we always allocate
blocks as unwritten extents when performing direct I/O writes and only
converting them to written extents at I/O completion.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
commit d531d91d69902e55633ed834f531aa0b48d618cc
Author: Christoph Hellwig <hch@infradead.org>
Date: Mon Feb 10 10:27:43 2014 +1100
xfs: always use unwritten extents for direct I/O writes
To allow aio writes beyond i_size we need to create unwritten extents for
newly allocated blocks, similar to how we already do inside i_size.
Instead of adding another special case we now use unwritten extents
unconditionally. This also marks the end of directly allocation data
extents in all of XFS - we now always use either delalloc or unwritten
extents.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
commit 6039257378e4c84da06e68230b14fef955508ce6
Author: Christoph Hellwig <hch@infradead.org>
Date: Mon Feb 10 10:27:11 2014 +1100
direct-io: add flag to allow aio writes beyond i_size
Some filesystems can handle direct I/O writes beyond i_size safely,
so allow them to opt into receiving them.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
-----------------------------------------------------------------------
hooks/post-receive
--
XFS development tree
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
reply other threads:[~2014-02-10 3:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140210031723.8C7C27F55@oss.sgi.com \
--to=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox