2005-04-17 02:20:36 +04:00
/*
2005-11-02 06:58:39 +03:00
* Copyright ( c ) 2000 - 2005 Silicon Graphics , Inc .
* All Rights Reserved .
2005-04-17 02:20:36 +04:00
*
2005-11-02 06:58:39 +03:00
* This program is free software ; you can redistribute it and / or
* modify it under the terms of the GNU General Public License as
2005-04-17 02:20:36 +04:00
* published by the Free Software Foundation .
*
2005-11-02 06:58:39 +03:00
* This program is distributed in the hope that it would be useful ,
* but WITHOUT ANY WARRANTY ; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
* GNU General Public License for more details .
2005-04-17 02:20:36 +04:00
*
2005-11-02 06:58:39 +03:00
* You should have received a copy of the GNU General Public License
* along with this program ; if not , write the Free Software Foundation ,
* Inc . , 51 Franklin St , Fifth Floor , Boston , MA 02110 - 1301 USA
2005-04-17 02:20:36 +04:00
*/
# include "xfs.h"
2013-10-23 03:36:05 +04:00
# include "xfs_shared.h"
2013-10-23 03:50:10 +04:00
# include "xfs_format.h"
# include "xfs_log_format.h"
# include "xfs_trans_resv.h"
2005-04-17 02:20:36 +04:00
# include "xfs_mount.h"
# include "xfs_inode.h"
2013-10-23 03:50:10 +04:00
# include "xfs_trans.h"
2012-03-13 12:41:05 +04:00
# include "xfs_inode_item.h"
2005-11-02 06:38:42 +03:00
# include "xfs_alloc.h"
2005-04-17 02:20:36 +04:00
# include "xfs_error.h"
# include "xfs_iomap.h"
2009-12-15 02:14:59 +03:00
# include "xfs_trace.h"
2010-03-05 05:00:42 +03:00
# include "xfs_bmap.h"
2013-08-12 14:49:42 +04:00
# include "xfs_bmap_util.h"
2013-10-23 03:51:50 +04:00
# include "xfs_bmap_btree.h"
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
# include <linux/gfp.h>
2005-04-17 02:20:36 +04:00
# include <linux/mpage.h>
2006-01-11 12:48:14 +03:00
# include <linux/pagevec.h>
2005-04-17 02:20:36 +04:00
# include <linux/writeback.h>
2016-02-08 06:40:51 +03:00
/* flags for direct write completions */
# define XFS_DIO_FLAG_UNWRITTEN (1 << 0)
# define XFS_DIO_FLAG_APPEND (1 << 1)
2016-02-15 09:21:19 +03:00
/*
* structure owned by writepages passed to individual writepage calls
*/
struct xfs_writepage_ctx {
struct xfs_bmbt_irec imap ;
bool imap_valid ;
unsigned int io_type ;
struct xfs_ioend * ioend ;
sector_t last_block ;
} ;
2009-12-15 02:14:59 +03:00
void
2006-03-14 05:26:27 +03:00
xfs_count_page_state (
struct page * page ,
int * delalloc ,
int * unwritten )
{
struct buffer_head * bh , * head ;
2010-06-24 03:46:01 +04:00
* delalloc = * unwritten = 0 ;
2006-03-14 05:26:27 +03:00
bh = head = page_buffers ( page ) ;
do {
2010-06-24 03:46:01 +04:00
if ( buffer_unwritten ( bh ) )
2006-03-14 05:26:27 +03:00
( * unwritten ) = 1 ;
else if ( buffer_delay ( bh ) )
( * delalloc ) = 1 ;
} while ( ( bh = bh - > b_this_page ) ! = head ) ;
}
2016-02-27 02:19:52 +03:00
struct block_device *
2007-09-14 09:23:17 +04:00
xfs_find_bdev_for_inode (
2010-04-28 16:28:52 +04:00
struct inode * inode )
2007-09-14 09:23:17 +04:00
{
2010-04-28 16:28:52 +04:00
struct xfs_inode * ip = XFS_I ( inode ) ;
2007-09-14 09:23:17 +04:00
struct xfs_mount * mp = ip - > i_mount ;
2007-11-23 08:29:42 +03:00
if ( XFS_IS_REALTIME_INODE ( ip ) )
2007-09-14 09:23:17 +04:00
return mp - > m_rtdev_targp - > bt_bdev ;
else
return mp - > m_ddev_targp - > bt_bdev ;
}
2006-01-11 07:40:13 +03:00
/*
* We ' re now finished for good with this ioend structure .
* Update the page state via the associated buffer_heads ,
* release holds on the inode and bio , and finally free
* up memory . Do not use the ioend after this .
*/
2005-09-02 10:58:49 +04:00
STATIC void
xfs_destroy_ioend (
xfs_ioend_t * ioend )
{
2006-01-11 07:40:13 +03:00
struct buffer_head * bh , * next ;
for ( bh = ioend - > io_buffer_head ; bh ; bh = next ) {
next = bh - > b_private ;
2006-06-09 08:58:38 +04:00
bh - > b_end_io ( bh , ! ioend - > io_error ) ;
2006-01-11 07:40:13 +03:00
}
2008-12-03 14:20:38 +03:00
2005-09-02 10:58:49 +04:00
mempool_free ( ioend , xfs_ioend_pool ) ;
}
2011-08-23 12:28:11 +04:00
/*
* Fast and loose check if this write could update the on - disk inode size .
*/
static inline bool xfs_ioend_is_append ( struct xfs_ioend * ioend )
{
return ioend - > io_offset + ioend - > io_size >
XFS_I ( ioend - > io_inode ) - > i_d . di_size ;
}
2012-03-13 12:41:05 +04:00
STATIC int
xfs_setfilesize_trans_alloc (
struct xfs_ioend * ioend )
{
struct xfs_mount * mp = XFS_I ( ioend - > io_inode ) - > i_mount ;
struct xfs_trans * tp ;
int error ;
tp = xfs_trans_alloc ( mp , XFS_TRANS_FSYNC_TS ) ;
2013-08-12 14:49:59 +04:00
error = xfs_trans_reserve ( tp , & M_RES ( mp ) - > tr_fsyncts , 0 , 0 ) ;
2012-03-13 12:41:05 +04:00
if ( error ) {
2015-06-04 06:47:56 +03:00
xfs_trans_cancel ( tp ) ;
2012-03-13 12:41:05 +04:00
return error ;
}
ioend - > io_append_trans = tp ;
2012-06-12 18:20:39 +04:00
/*
2012-11-28 06:01:00 +04:00
* We may pass freeze protection with a transaction . So tell lockdep
2012-06-12 18:20:39 +04:00
* we released it .
*/
2015-07-20 00:48:20 +03:00
__sb_writers_release ( ioend - > io_inode - > i_sb , SB_FREEZE_FS ) ;
2012-03-13 12:41:05 +04:00
/*
* We hand off the transaction to the completion thread now , so
* clear the flag here .
*/
current_restore_flags_nested ( & tp - > t_pflags , PF_FSTRANS ) ;
return 0 ;
}
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
/*
2011-12-19 00:00:12 +04:00
* Update on - disk file size now that data has been written to disk .
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
*/
2012-03-13 12:41:05 +04:00
STATIC int
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
xfs_setfilesize (
2015-02-02 02:02:09 +03:00
struct xfs_inode * ip ,
struct xfs_trans * tp ,
xfs_off_t offset ,
size_t size )
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
{
xfs_fsize_t isize ;
2012-02-29 13:53:48 +04:00
xfs_ilock ( ip , XFS_ILOCK_EXCL ) ;
2015-02-02 02:02:09 +03:00
isize = xfs_new_eof ( ip , offset + size ) ;
2012-03-13 12:41:05 +04:00
if ( ! isize ) {
xfs_iunlock ( ip , XFS_ILOCK_EXCL ) ;
2015-06-04 06:47:56 +03:00
xfs_trans_cancel ( tp ) ;
2012-03-13 12:41:05 +04:00
return 0 ;
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
}
2015-02-02 02:02:09 +03:00
trace_xfs_setfilesize ( ip , offset , size ) ;
2012-03-13 12:41:05 +04:00
ip - > i_d . di_size = isize ;
xfs_trans_ijoin ( tp , ip , XFS_ILOCK_EXCL ) ;
xfs_trans_log_inode ( tp , ip , XFS_ILOG_CORE ) ;
2015-06-04 06:48:08 +03:00
return xfs_trans_commit ( tp ) ;
2010-02-17 08:36:29 +03:00
}
2015-02-02 02:02:09 +03:00
STATIC int
xfs_setfilesize_ioend (
struct xfs_ioend * ioend )
{
struct xfs_inode * ip = XFS_I ( ioend - > io_inode ) ;
struct xfs_trans * tp = ioend - > io_append_trans ;
/*
* The transaction may have been allocated in the I / O submission thread ,
* thus we need to mark ourselves as being in a transaction manually .
* Similarly for freeze protection .
*/
current_set_flags_nested ( & tp - > t_pflags , PF_FSTRANS ) ;
2015-07-20 00:48:20 +03:00
__sb_writers_acquired ( VFS_I ( ip ) - > i_sb , SB_FREEZE_FS ) ;
2015-02-02 02:02:09 +03:00
2015-10-12 07:28:39 +03:00
/* we abort the update if there was an IO error */
if ( ioend - > io_error ) {
xfs_trans_cancel ( tp ) ;
return ioend - > io_error ;
}
2015-02-02 02:02:09 +03:00
return xfs_setfilesize ( ip , tp , ioend - > io_offset , ioend - > io_size ) ;
}
2010-02-17 08:36:29 +03:00
/*
2010-07-19 01:17:11 +04:00
* Schedule IO completion handling on the final put of an ioend .
2011-08-23 12:28:11 +04:00
*
* If there is no work to do we might as well call it a day and free the
* ioend right now .
2010-02-17 08:36:29 +03:00
*/
STATIC void
xfs_finish_ioend (
2010-07-19 01:17:11 +04:00
struct xfs_ioend * ioend )
2010-02-17 08:36:29 +03:00
{
if ( atomic_dec_and_test ( & ioend - > io_remaining ) ) {
2012-02-29 13:53:48 +04:00
struct xfs_mount * mp = XFS_I ( ioend - > io_inode ) - > i_mount ;
2012-05-23 00:56:21 +04:00
if ( ioend - > io_type = = XFS_IO_UNWRITTEN )
2012-02-29 13:53:48 +04:00
queue_work ( mp - > m_unwritten_workqueue , & ioend - > io_work ) ;
2015-02-02 02:02:09 +03:00
else if ( ioend - > io_append_trans )
2012-02-29 13:53:48 +04:00
queue_work ( mp - > m_data_workqueue , & ioend - > io_work ) ;
2011-08-23 12:28:11 +04:00
else
xfs_destroy_ioend ( ioend ) ;
2010-02-17 08:36:29 +03:00
}
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
}
2005-09-02 10:58:49 +04:00
/*
2009-10-30 12:11:47 +03:00
* IO write completion .
2006-01-11 07:40:13 +03:00
*/
STATIC void
2009-10-30 12:11:47 +03:00
xfs_end_io (
2010-02-17 08:36:29 +03:00
struct work_struct * work )
2005-09-02 10:58:49 +04:00
{
2010-02-17 08:36:29 +03:00
xfs_ioend_t * ioend = container_of ( work , xfs_ioend_t , io_work ) ;
struct xfs_inode * ip = XFS_I ( ioend - > io_inode ) ;
2010-03-04 03:57:09 +03:00
int error = 0 ;
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
2016-02-08 07:00:02 +03:00
/*
* Set an error if the mount has shut down and proceed with end I / O
* processing so it can perform whatever cleanups are necessary .
*/
if ( XFS_FORCED_SHUTDOWN ( ip - > i_mount ) )
2011-11-08 12:56:15 +04:00
ioend - > io_error = - EIO ;
2011-08-24 09:59:25 +04:00
2009-10-30 12:11:47 +03:00
/*
* For unwritten extents we need to issue transactions to convert a
* range to normal written extens after the data I / O has finished .
2015-10-12 07:28:39 +03:00
* Detecting and handling completion IO errors is done individually
* for each case as different cleanup operations need to be performed
* on error .
2009-10-30 12:11:47 +03:00
*/
2012-05-23 00:56:21 +04:00
if ( ioend - > io_type = = XFS_IO_UNWRITTEN ) {
2015-10-12 07:28:39 +03:00
if ( ioend - > io_error )
goto done ;
2012-11-28 06:01:00 +04:00
error = xfs_iomap_write_unwritten ( ip , ioend - > io_offset ,
ioend - > io_size ) ;
2012-03-13 12:41:05 +04:00
} else if ( ioend - > io_append_trans ) {
2015-02-02 02:02:09 +03:00
error = xfs_setfilesize_ioend ( ioend ) ;
2012-02-29 13:53:50 +04:00
} else {
2012-03-13 12:41:05 +04:00
ASSERT ( ! xfs_ioend_is_append ( ioend ) ) ;
2009-10-30 12:11:47 +03:00
}
[XFS] Fix to prevent the notorious 'NULL files' problem after a crash.
The problem that has been addressed is that of synchronising updates of
the file size with writes that extend a file. Without the fix the update
of a file's size, as a result of a write beyond eof, is independent of
when the cached data is flushed to disk. Often the file size update would
be written to the filesystem log before the data is flushed to disk. When
a system crashes between these two events and the filesystem log is
replayed on mount the file's size will be set but since the contents never
made it to disk the file is full of holes. If some of the cached data was
flushed to disk then it may just be a section of the file at the end that
has holes.
There are existing fixes to help alleviate this problem, particularly in
the case where a file has been truncated, that force cached data to be
flushed to disk when the file is closed. If the system crashes while the
file(s) are still open then this flushing will never occur.
The fix that we have implemented is to introduce a second file size,
called the in-memory file size, that represents the current file size as
viewed by the user. The existing file size, called the on-disk file size,
is the one that get's written to the filesystem log and we only update it
when it is safe to do so. When we write to a file beyond eof we only
update the in- memory file size in the write operation. Later when the I/O
operation, that flushes the cached data to disk completes, an I/O
completion routine will update the on-disk file size. The on-disk file
size will be updated to the maximum offset of the I/O or to the value of
the in-memory file size if the I/O includes eof.
SGI-PV: 958522
SGI-Modid: xfs-linux-melb:xfs-kern:28322a
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
2007-05-08 07:49:46 +04:00
2011-08-24 09:59:25 +04:00
done :
2012-11-28 06:01:00 +04:00
if ( error )
2014-06-25 08:58:08 +04:00
ioend - > io_error = error ;
2012-02-29 13:53:48 +04:00
xfs_destroy_ioend ( ioend ) ;
2009-04-06 20:42:11 +04:00
}
2005-09-02 10:58:49 +04:00
/*
* Allocate and initialise an IO completion structure .
* We need to track unwritten extent write completion here initially .
* We ' ll need to extend this for updating the ondisk inode size later
* ( vs . incore size ) .
*/
STATIC xfs_ioend_t *
xfs_alloc_ioend (
2006-01-11 07:40:13 +03:00
struct inode * inode ,
unsigned int type )
2005-09-02 10:58:49 +04:00
{
xfs_ioend_t * ioend ;
ioend = mempool_alloc ( xfs_ioend_pool , GFP_NOFS ) ;
/*
* Set the count to 1 initially , which will prevent an I / O
* completion callback from happening before we have started
* all the I / O from calling the completion routine too early .
*/
atomic_set ( & ioend - > io_remaining , 1 ) ;
2006-06-09 08:58:38 +04:00
ioend - > io_error = 0 ;
2016-02-15 09:23:12 +03:00
INIT_LIST_HEAD ( & ioend - > io_list ) ;
2006-01-11 07:40:13 +03:00
ioend - > io_type = type ;
2007-08-29 05:46:28 +04:00
ioend - > io_inode = inode ;
2005-09-05 02:23:35 +04:00
ioend - > io_buffer_head = NULL ;
2006-01-11 07:40:13 +03:00
ioend - > io_buffer_tail = NULL ;
2005-09-02 10:58:49 +04:00
ioend - > io_offset = 0 ;
ioend - > io_size = 0 ;
2012-03-13 12:41:05 +04:00
ioend - > io_append_trans = NULL ;
2005-09-02 10:58:49 +04:00
2009-10-30 12:11:47 +03:00
INIT_WORK ( & ioend - > io_work , xfs_end_io ) ;
2005-09-02 10:58:49 +04:00
return ioend ;
}
2005-04-17 02:20:36 +04:00
STATIC int
xfs_map_blocks (
struct inode * inode ,
loff_t offset ,
2010-04-28 16:28:56 +04:00
struct xfs_bmbt_irec * imap ,
2016-02-15 09:20:50 +03:00
int type )
2005-04-17 02:20:36 +04:00
{
2010-12-10 11:42:20 +03:00
struct xfs_inode * ip = XFS_I ( inode ) ;
struct xfs_mount * mp = ip - > i_mount ;
2010-12-10 11:42:22 +03:00
ssize_t count = 1 < < inode - > i_blkbits ;
2010-12-10 11:42:20 +03:00
xfs_fileoff_t offset_fsb , end_fsb ;
int error = 0 ;
int bmapi_flags = XFS_BMAPI_ENTIRE ;
int nimaps = 1 ;
if ( XFS_FORCED_SHUTDOWN ( mp ) )
2014-06-22 09:04:54 +04:00
return - EIO ;
2010-12-10 11:42:20 +03:00
2012-05-23 00:56:21 +04:00
if ( type = = XFS_IO_UNWRITTEN )
2010-12-10 11:42:20 +03:00
bmapi_flags | = XFS_BMAPI_IGSTATE ;
2010-12-10 11:42:21 +03:00
2016-02-15 09:20:50 +03:00
xfs_ilock ( ip , XFS_ILOCK_SHARED ) ;
2010-12-10 11:42:21 +03:00
ASSERT ( ip - > i_d . di_format ! = XFS_DINODE_FMT_BTREE | |
( ip - > i_df . if_flags & XFS_IFEXTENTS ) ) ;
2012-06-08 09:44:53 +04:00
ASSERT ( offset < = mp - > m_super - > s_maxbytes ) ;
2010-12-10 11:42:21 +03:00
2012-06-08 09:44:53 +04:00
if ( offset + count > mp - > m_super - > s_maxbytes )
count = mp - > m_super - > s_maxbytes - offset ;
2010-12-10 11:42:20 +03:00
end_fsb = XFS_B_TO_FSB ( mp , ( xfs_ufsize_t ) offset + count ) ;
offset_fsb = XFS_B_TO_FSBT ( mp , offset ) ;
2011-09-19 00:40:45 +04:00
error = xfs_bmapi_read ( ip , offset_fsb , end_fsb - offset_fsb ,
imap , & nimaps , bmapi_flags ) ;
2010-12-10 11:42:21 +03:00
xfs_iunlock ( ip , XFS_ILOCK_SHARED ) ;
2010-12-10 11:42:20 +03:00
2010-12-10 11:42:21 +03:00
if ( error )
2014-06-25 08:58:08 +04:00
return error ;
2010-12-10 11:42:20 +03:00
2012-05-23 00:56:21 +04:00
if ( type = = XFS_IO_DELALLOC & &
2010-12-10 11:42:21 +03:00
( ! nimaps | | isnullstartblock ( imap - > br_startblock ) ) ) {
2013-09-29 14:56:04 +04:00
error = xfs_iomap_write_allocate ( ip , offset , imap ) ;
2010-12-10 11:42:20 +03:00
if ( ! error )
trace_xfs_map_blocks_alloc ( ip , offset , count , type , imap ) ;
2014-06-25 08:58:08 +04:00
return error ;
2010-12-10 11:42:20 +03:00
}
2010-12-10 11:42:21 +03:00
# ifdef DEBUG
2012-05-23 00:56:21 +04:00
if ( type = = XFS_IO_UNWRITTEN ) {
2010-12-10 11:42:21 +03:00
ASSERT ( nimaps ) ;
ASSERT ( imap - > br_startblock ! = HOLESTARTBLOCK ) ;
ASSERT ( imap - > br_startblock ! = DELAYSTARTBLOCK ) ;
}
# endif
if ( nimaps )
trace_xfs_map_blocks_found ( ip , offset , count , type , imap ) ;
return 0 ;
2005-04-17 02:20:36 +04:00
}
2016-02-15 09:21:19 +03:00
STATIC bool
2010-04-28 16:28:58 +04:00
xfs_imap_valid (
2010-04-28 16:28:54 +04:00
struct inode * inode ,
2010-04-28 16:28:56 +04:00
struct xfs_bmbt_irec * imap ,
2010-04-28 16:28:58 +04:00
xfs_off_t offset )
2005-04-17 02:20:36 +04:00
{
2010-04-28 16:28:58 +04:00
offset > > = inode - > i_blkbits ;
2010-04-28 16:28:54 +04:00
2010-04-28 16:28:58 +04:00
return offset > = imap - > br_startoff & &
offset < imap - > br_startoff + imap - > br_blockcount ;
2005-04-17 02:20:36 +04:00
}
2006-01-11 07:40:13 +03:00
/*
* BIO completion handler for buffered IO .
*/
2007-10-12 10:17:47 +04:00
STATIC void
2006-01-11 07:40:13 +03:00
xfs_end_bio (
2015-07-20 16:29:37 +03:00
struct bio * bio )
2006-01-11 07:40:13 +03:00
{
xfs_ioend_t * ioend = bio - > bi_private ;
2015-09-07 23:28:32 +03:00
if ( ! ioend - > io_error )
ioend - > io_error = bio - > bi_error ;
2006-01-11 07:40:13 +03:00
/* Toss bio and pass work off to an xfsdatad thread */
bio - > bi_private = NULL ;
bio - > bi_end_io = NULL ;
bio_put ( bio ) ;
2006-06-09 08:58:38 +04:00
2010-07-19 01:17:11 +04:00
xfs_finish_ioend ( ioend ) ;
2006-01-11 07:40:13 +03:00
}
STATIC void
xfs_submit_ioend_bio (
2009-10-30 12:09:15 +03:00
struct writeback_control * wbc ,
xfs_ioend_t * ioend ,
struct bio * bio )
2006-01-11 07:40:13 +03:00
{
atomic_inc ( & ioend - > io_remaining ) ;
bio - > bi_private = ioend ;
bio - > bi_end_io = xfs_end_bio ;
2011-03-09 13:56:30 +03:00
submit_bio ( wbc - > sync_mode = = WB_SYNC_ALL ? WRITE_SYNC : WRITE , bio ) ;
2006-01-11 07:40:13 +03:00
}
STATIC struct bio *
xfs_alloc_ioend_bio (
struct buffer_head * bh )
{
2015-05-19 15:31:01 +03:00
struct bio * bio = bio_alloc ( GFP_NOIO , BIO_MAX_PAGES ) ;
2006-01-11 07:40:13 +03:00
ASSERT ( bio - > bi_private = = NULL ) ;
2013-10-12 02:44:27 +04:00
bio - > bi_iter . bi_sector = bh - > b_blocknr * ( bh - > b_size > > 9 ) ;
2006-01-11 07:40:13 +03:00
bio - > bi_bdev = bh - > b_bdev ;
return bio ;
}
STATIC void
xfs_start_buffer_writeback (
struct buffer_head * bh )
{
ASSERT ( buffer_mapped ( bh ) ) ;
ASSERT ( buffer_locked ( bh ) ) ;
ASSERT ( ! buffer_delay ( bh ) ) ;
ASSERT ( ! buffer_unwritten ( bh ) ) ;
mark_buffer_async_write ( bh ) ;
set_buffer_uptodate ( bh ) ;
clear_buffer_dirty ( bh ) ;
}
STATIC void
xfs_start_page_writeback (
struct page * page ,
2016-02-15 09:23:12 +03:00
int clear_dirty )
2006-01-11 07:40:13 +03:00
{
ASSERT ( PageLocked ( page ) ) ;
ASSERT ( ! PageWriteback ( page ) ) ;
2014-09-23 09:36:27 +04:00
/*
* if the page was not fully cleaned , we need to ensure that the higher
* layers come back to it correctly . That means we need to keep the page
* dirty , and for WB_SYNC_ALL writeback we need to ensure the
* PAGECACHE_TAG_TOWRITE index mark is not removed so another attempt to
* write this page in this writeback sweep will be made .
*/
if ( clear_dirty ) {
2006-12-21 02:24:01 +03:00
clear_page_dirty_for_io ( page ) ;
2014-09-23 09:36:27 +04:00
set_page_writeback ( page ) ;
} else
set_page_writeback_keepwrite ( page ) ;
2006-01-11 07:40:13 +03:00
unlock_page ( page ) ;
}
2013-08-07 14:11:09 +04:00
static inline int xfs_bio_add_buffer ( struct bio * bio , struct buffer_head * bh )
2006-01-11 07:40:13 +03:00
{
return bio_add_page ( bio , bh - > b_page , bh - > b_size , bh_offset ( bh ) ) ;
}
/*
2016-02-15 09:23:12 +03:00
* Submit all of the bios for an ioend . We are only passed a single ioend at a
* time ; the caller is responsible for chaining prior to submission .
xfs: fix broken error handling in xfs_vm_writepage
When we shut down the filesystem, it might first be detected in
writeback when we are allocating a inode size transaction. This
happens after we have moved all the pages into the writeback state
and unlocked them. Unfortunately, if we fail to set up the
transaction we then abort writeback and try to invalidate the
current page. This then triggers are BUG() in block_invalidatepage()
because we are trying to invalidate an unlocked page.
Fixing this is a bit of a chicken and egg problem - we can't
allocate the transaction until we've clustered all the pages into
the IO and we know the size of it (i.e. whether the last block of
the IO is beyond the current EOF or not). However, we don't want to
hold pages locked for long periods of time, especially while we lock
other pages to cluster them into the write.
To fix this, we need to make a clear delineation in writeback where
errors can only be handled by IO completion processing. That is,
once we have marked a page for writeback and unlocked it, we have to
report errors via IO completion because we've already started the
IO. We may not have submitted any IO, but we've changed the page
state to indicate that it is under IO so we must now use the IO
completion path to report errors.
To do this, add an error field to xfs_submit_ioend() to pass it the
error that occurred during the building on the ioend chain. When
this is non-zero, mark each ioend with the error and call
xfs_finish_ioend() directly rather than building bios. This will
immediately push the ioends through completion processing with the
error that has occurred.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-11-12 15:09:45 +04:00
*
* If @ fail is non - zero , it means that we have a situation where some part of
* the submission process has failed after we have marked paged for writeback
* and unlocked them . In this situation , we need to fail the ioend chain rather
* than submit it to IO . This typically only happens on a filesystem shutdown .
2006-01-11 07:40:13 +03:00
*/
2016-02-15 09:23:12 +03:00
STATIC int
2006-01-11 07:40:13 +03:00
xfs_submit_ioend (
2009-10-30 12:09:15 +03:00
struct writeback_control * wbc ,
xfs: fix broken error handling in xfs_vm_writepage
When we shut down the filesystem, it might first be detected in
writeback when we are allocating a inode size transaction. This
happens after we have moved all the pages into the writeback state
and unlocked them. Unfortunately, if we fail to set up the
transaction we then abort writeback and try to invalidate the
current page. This then triggers are BUG() in block_invalidatepage()
because we are trying to invalidate an unlocked page.
Fixing this is a bit of a chicken and egg problem - we can't
allocate the transaction until we've clustered all the pages into
the IO and we know the size of it (i.e. whether the last block of
the IO is beyond the current EOF or not). However, we don't want to
hold pages locked for long periods of time, especially while we lock
other pages to cluster them into the write.
To fix this, we need to make a clear delineation in writeback where
errors can only be handled by IO completion processing. That is,
once we have marked a page for writeback and unlocked it, we have to
report errors via IO completion because we've already started the
IO. We may not have submitted any IO, but we've changed the page
state to indicate that it is under IO so we must now use the IO
completion path to report errors.
To do this, add an error field to xfs_submit_ioend() to pass it the
error that occurred during the building on the ioend chain. When
this is non-zero, mark each ioend with the error and call
xfs_finish_ioend() directly rather than building bios. This will
immediately push the ioends through completion processing with the
error that has occurred.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-11-12 15:09:45 +04:00
xfs_ioend_t * ioend ,
2016-02-15 09:23:12 +03:00
int status )
2006-01-11 07:40:13 +03:00
{
struct buffer_head * bh ;
struct bio * bio ;
sector_t lastblock = 0 ;
2016-02-15 09:23:12 +03:00
/* Reserve log space if we might write beyond the on-disk inode size. */
if ( ! status & &
ioend - > io_type ! = XFS_IO_UNWRITTEN & & xfs_ioend_is_append ( ioend ) )
status = xfs_setfilesize_trans_alloc ( ioend ) ;
/*
* If we are failing the IO now , just mark the ioend with an
* error and finish it . This will run IO completion immediately
* as there is only one reference to the ioend at this point in
* time .
*/
if ( status ) {
ioend - > io_error = status ;
xfs_finish_ioend ( ioend ) ;
return status ;
}
2006-01-18 05:38:12 +03:00
2016-02-15 09:23:12 +03:00
bio = NULL ;
for ( bh = ioend - > io_buffer_head ; bh ; bh = bh - > b_private ) {
2006-01-11 07:40:13 +03:00
2016-02-15 09:23:12 +03:00
if ( ! bio ) {
retry :
bio = xfs_alloc_ioend_bio ( bh ) ;
} else if ( bh - > b_blocknr ! = lastblock + 1 ) {
xfs_submit_ioend_bio ( wbc , ioend , bio ) ;
goto retry ;
xfs: fix broken error handling in xfs_vm_writepage
When we shut down the filesystem, it might first be detected in
writeback when we are allocating a inode size transaction. This
happens after we have moved all the pages into the writeback state
and unlocked them. Unfortunately, if we fail to set up the
transaction we then abort writeback and try to invalidate the
current page. This then triggers are BUG() in block_invalidatepage()
because we are trying to invalidate an unlocked page.
Fixing this is a bit of a chicken and egg problem - we can't
allocate the transaction until we've clustered all the pages into
the IO and we know the size of it (i.e. whether the last block of
the IO is beyond the current EOF or not). However, we don't want to
hold pages locked for long periods of time, especially while we lock
other pages to cluster them into the write.
To fix this, we need to make a clear delineation in writeback where
errors can only be handled by IO completion processing. That is,
once we have marked a page for writeback and unlocked it, we have to
report errors via IO completion because we've already started the
IO. We may not have submitted any IO, but we've changed the page
state to indicate that it is under IO so we must now use the IO
completion path to report errors.
To do this, add an error field to xfs_submit_ioend() to pass it the
error that occurred during the building on the ioend chain. When
this is non-zero, mark each ioend with the error and call
xfs_finish_ioend() directly rather than building bios. This will
immediately push the ioends through completion processing with the
error that has occurred.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-11-12 15:09:45 +04:00
}
2016-02-15 09:23:12 +03:00
if ( xfs_bio_add_buffer ( bio , bh ) ! = bh - > b_size ) {
2009-10-30 12:09:15 +03:00
xfs_submit_ioend_bio ( wbc , ioend , bio ) ;
2016-02-15 09:23:12 +03:00
goto retry ;
}
2006-01-11 07:40:13 +03:00
2016-02-15 09:23:12 +03:00
lastblock = bh - > b_blocknr ;
}
if ( bio )
xfs_submit_ioend_bio ( wbc , ioend , bio ) ;
xfs_finish_ioend ( ioend ) ;
return 0 ;
2006-01-11 07:40:13 +03:00
}
/*
* Test to see if we ' ve been building up a completion structure for
* earlier buffers - - if so , we try to append to this ioend if we
* can , otherwise we finish off any current ioend and start another .
2016-02-15 09:23:12 +03:00
* Return the ioend we finished off so that the caller can submit it
* once it has finished processing the dirty page .
2006-01-11 07:40:13 +03:00
*/
STATIC void
xfs_add_to_ioend (
struct inode * inode ,
struct buffer_head * bh ,
2006-01-11 12:49:16 +03:00
xfs_off_t offset ,
2016-02-15 09:23:12 +03:00
struct xfs_writepage_ctx * wpc ,
struct list_head * iolist )
2006-01-11 07:40:13 +03:00
{
2016-02-15 09:21:19 +03:00
if ( ! wpc - > ioend | | wpc - > io_type ! = wpc - > ioend - > io_type | |
2016-03-07 01:32:14 +03:00
bh - > b_blocknr ! = wpc - > last_block + 1 | |
offset ! = wpc - > ioend - > io_offset + wpc - > ioend - > io_size ) {
2016-02-15 09:21:19 +03:00
struct xfs_ioend * new ;
2016-02-15 09:23:12 +03:00
if ( wpc - > ioend )
list_add ( & wpc - > ioend - > io_list , iolist ) ;
2016-02-15 09:21:19 +03:00
new = xfs_alloc_ioend ( inode , wpc - > io_type ) ;
new - > io_offset = offset ;
new - > io_buffer_head = bh ;
new - > io_buffer_tail = bh ;
wpc - > ioend = new ;
2006-01-11 07:40:13 +03:00
} else {
2016-02-15 09:21:19 +03:00
wpc - > ioend - > io_buffer_tail - > b_private = bh ;
wpc - > ioend - > io_buffer_tail = bh ;
2006-01-11 07:40:13 +03:00
}
bh - > b_private = NULL ;
2016-02-15 09:21:19 +03:00
wpc - > ioend - > io_size + = bh - > b_size ;
wpc - > last_block = bh - > b_blocknr ;
2016-02-15 09:23:12 +03:00
xfs_start_buffer_writeback ( bh ) ;
2006-01-11 07:40:13 +03:00
}
2006-03-14 05:26:43 +03:00
STATIC void
xfs_map_buffer (
2010-04-28 16:28:52 +04:00
struct inode * inode ,
2006-03-14 05:26:43 +03:00
struct buffer_head * bh ,
2010-04-28 16:28:56 +04:00
struct xfs_bmbt_irec * imap ,
2010-04-28 16:28:52 +04:00
xfs_off_t offset )
2006-03-14 05:26:43 +03:00
{
sector_t bn ;
2010-04-28 16:28:54 +04:00
struct xfs_mount * m = XFS_I ( inode ) - > i_mount ;
2010-04-28 16:28:56 +04:00
xfs_off_t iomap_offset = XFS_FSB_TO_B ( m , imap - > br_startoff ) ;
xfs_daddr_t iomap_bn = xfs_fsb_to_db ( XFS_I ( inode ) , imap - > br_startblock ) ;
2006-03-14 05:26:43 +03:00
2010-04-28 16:28:56 +04:00
ASSERT ( imap - > br_startblock ! = HOLESTARTBLOCK ) ;
ASSERT ( imap - > br_startblock ! = DELAYSTARTBLOCK ) ;
2006-03-14 05:26:43 +03:00
2010-04-28 16:28:55 +04:00
bn = ( iomap_bn > > ( inode - > i_blkbits - BBSHIFT ) ) +
2010-04-28 16:28:54 +04:00
( ( offset - iomap_offset ) > > inode - > i_blkbits ) ;
2006-03-14 05:26:43 +03:00
2010-04-28 16:28:52 +04:00
ASSERT ( bn | | XFS_IS_REALTIME_INODE ( XFS_I ( inode ) ) ) ;
2006-03-14 05:26:43 +03:00
bh - > b_blocknr = bn ;
set_buffer_mapped ( bh ) ;
}
2005-04-17 02:20:36 +04:00
STATIC void
xfs_map_at_offset (
2010-04-28 16:28:52 +04:00
struct inode * inode ,
2005-04-17 02:20:36 +04:00
struct buffer_head * bh ,
2010-04-28 16:28:56 +04:00
struct xfs_bmbt_irec * imap ,
2010-04-28 16:28:52 +04:00
xfs_off_t offset )
2005-04-17 02:20:36 +04:00
{
2010-04-28 16:28:56 +04:00
ASSERT ( imap - > br_startblock ! = HOLESTARTBLOCK ) ;
ASSERT ( imap - > br_startblock ! = DELAYSTARTBLOCK ) ;
2005-04-17 02:20:36 +04:00
2010-04-28 16:28:56 +04:00
xfs_map_buffer ( inode , bh , imap , offset ) ;
2005-04-17 02:20:36 +04:00
set_buffer_mapped ( bh ) ;
clear_buffer_delay ( bh ) ;
2006-01-11 07:40:13 +03:00
clear_buffer_unwritten ( bh ) ;
2005-04-17 02:20:36 +04:00
}
/*
2014-03-07 09:19:14 +04:00
* Test if a given page contains at least one buffer of a given @ type .
* If @ check_all_buffers is true , then we walk all the buffers in the page to
* try to find one of the type passed in . If it is not set , then the caller only
* needs to check the first buffer on the page for a match .
2005-04-17 02:20:36 +04:00
*/
2014-03-07 09:19:14 +04:00
STATIC bool
2012-04-23 09:58:43 +04:00
xfs_check_page_type (
2006-01-11 12:48:14 +03:00
struct page * page ,
2014-03-07 09:19:14 +04:00
unsigned int type ,
bool check_all_buffers )
2005-04-17 02:20:36 +04:00
{
2014-03-07 09:19:14 +04:00
struct buffer_head * bh ;
struct buffer_head * head ;
2005-04-17 02:20:36 +04:00
2014-03-07 09:19:14 +04:00
if ( PageWriteback ( page ) )
return false ;
if ( ! page - > mapping )
return false ;
if ( ! page_has_buffers ( page ) )
return false ;
2005-04-17 02:20:36 +04:00
2014-03-07 09:19:14 +04:00
bh = head = page_buffers ( page ) ;
do {
if ( buffer_unwritten ( bh ) ) {
if ( type = = XFS_IO_UNWRITTEN )
return true ;
} else if ( buffer_delay ( bh ) ) {
2014-04-03 23:56:30 +04:00
if ( type = = XFS_IO_DELALLOC )
2014-03-07 09:19:14 +04:00
return true ;
} else if ( buffer_dirty ( bh ) & & buffer_mapped ( bh ) ) {
2014-04-03 23:56:30 +04:00
if ( type = = XFS_IO_OVERWRITE )
2014-03-07 09:19:14 +04:00
return true ;
}
2005-04-17 02:20:36 +04:00
2014-03-07 09:19:14 +04:00
/* If we are only checking the first buffer, we are done now. */
if ( ! check_all_buffers )
break ;
} while ( ( bh = bh - > b_this_page ) ! = head ) ;
2005-04-17 02:20:36 +04:00
2014-03-07 09:19:14 +04:00
return false ;
2005-04-17 02:20:36 +04:00
}
2010-03-05 05:00:42 +03:00
STATIC void
xfs_vm_invalidatepage (
struct page * page ,
2013-05-22 07:17:23 +04:00
unsigned int offset ,
unsigned int length )
2010-03-05 05:00:42 +03:00
{
2013-05-22 07:58:01 +04:00
trace_xfs_invalidatepage ( page - > mapping - > host , page , offset ,
length ) ;
block_invalidatepage ( page , offset , length ) ;
2010-03-05 05:00:42 +03:00
}
/*
* If the page has delalloc buffers on it , we need to punch them out before we
* invalidate the page . If we don ' t , we leave a stale delalloc mapping on the
* inode that can trip a BUG ( ) in xfs_get_blocks ( ) later on if a direct IO read
* is done on that same region - the delalloc extent is returned when none is
* supposed to be there .
*
* We prevent this by truncating away the delalloc regions on the page before
* invalidating it . Because they are delalloc , we can do this without needing a
* transaction . Indeed - if we get ENOSPC errors , we have to be able to do this
* truncation without a transaction as there is no space left for block
* reservation ( typically why we see a ENOSPC in writeback ) .
*
* This is not a performance critical path , so for now just do the punching a
* buffer head at a time .
*/
STATIC void
xfs_aops_discard_page (
struct page * page )
{
struct inode * inode = page - > mapping - > host ;
struct xfs_inode * ip = XFS_I ( inode ) ;
struct buffer_head * bh , * head ;
loff_t offset = page_offset ( page ) ;
2014-03-07 09:19:14 +04:00
if ( ! xfs_check_page_type ( page , XFS_IO_DELALLOC , true ) )
2010-03-05 05:00:42 +03:00
goto out_invalidate ;
2010-03-15 05:36:35 +03:00
if ( XFS_FORCED_SHUTDOWN ( ip - > i_mount ) )
goto out_invalidate ;
2011-03-07 02:00:35 +03:00
xfs_alert ( ip - > i_mount ,
2010-03-05 05:00:42 +03:00
" page discard on page %p, inode 0x%llx, offset %llu. " ,
page , ip - > i_ino , offset ) ;
xfs_ilock ( ip , XFS_ILOCK_EXCL ) ;
bh = head = page_buffers ( page ) ;
do {
int error ;
2010-11-30 07:14:39 +03:00
xfs_fileoff_t start_fsb ;
2010-03-05 05:00:42 +03:00
if ( ! buffer_delay ( bh ) )
goto next_buffer ;
2010-11-30 07:14:39 +03:00
start_fsb = XFS_B_TO_FSBT ( ip - > i_mount , offset ) ;
error = xfs_bmap_punch_delalloc_range ( ip , start_fsb , 1 ) ;
2010-03-05 05:00:42 +03:00
if ( error ) {
/* something screwed, just bail */
2010-03-15 05:36:35 +03:00
if ( ! XFS_FORCED_SHUTDOWN ( ip - > i_mount ) ) {
2011-03-07 02:00:35 +03:00
xfs_alert ( ip - > i_mount ,
2010-03-05 05:00:42 +03:00
" page discard unable to remove delalloc mapping. " ) ;
2010-03-15 05:36:35 +03:00
}
2010-03-05 05:00:42 +03:00
break ;
}
next_buffer :
2010-11-30 07:14:39 +03:00
offset + = 1 < < inode - > i_blkbits ;
2010-03-05 05:00:42 +03:00
} while ( ( bh = bh - > b_this_page ) ! = head ) ;
xfs_iunlock ( ip , XFS_ILOCK_EXCL ) ;
out_invalidate :
2013-05-22 07:17:23 +04:00
xfs_vm_invalidatepage ( page , 0 , PAGE_CACHE_SIZE ) ;
2010-03-05 05:00:42 +03:00
return ;
}
2016-02-15 09:23:12 +03:00
/*
* We implement an immediate ioend submission policy here to avoid needing to
* chain multiple ioends and hence nest mempool allocations which can violate
* forward progress guarantees we need to provide . The current ioend we are
* adding buffers to is cached on the writepage context , and if the new buffer
* does not append to the cached ioend it will create a new ioend and cache that
* instead .
*
* If a new ioend is created and cached , the old ioend is returned and queued
* locally for submission once the entire page is processed or an error has been
* detected . While ioends are submitted immediately after they are completed ,
* batching optimisations are provided by higher level block plugging .
*
* At the end of a writeback pass , there will be a cached ioend remaining on the
* writepage context that the caller will need to submit .
*/
2016-02-15 09:21:37 +03:00
static int
xfs_writepage_map (
struct xfs_writepage_ctx * wpc ,
2016-02-15 09:23:12 +03:00
struct writeback_control * wbc ,
2016-02-15 09:21:37 +03:00
struct inode * inode ,
struct page * page ,
loff_t offset ,
__uint64_t end_offset )
{
2016-02-15 09:23:12 +03:00
LIST_HEAD ( submit_list ) ;
struct xfs_ioend * ioend , * next ;
2016-02-15 09:21:37 +03:00
struct buffer_head * bh , * head ;
ssize_t len = 1 < < inode - > i_blkbits ;
int error = 0 ;
int count = 0 ;
2016-02-15 09:23:12 +03:00
int uptodate = 1 ;
2016-02-15 09:21:37 +03:00
bh = head = page_buffers ( page ) ;
offset = page_offset ( page ) ;
do {
if ( offset > = end_offset )
break ;
if ( ! buffer_uptodate ( bh ) )
uptodate = 0 ;
/*
* set_page_dirty dirties all buffers in a page , independent
* of their state . The dirty state however is entirely
* meaningless for holes ( ! mapped & & uptodate ) , so skip
* buffers covering holes here .
*/
if ( ! buffer_mapped ( bh ) & & buffer_uptodate ( bh ) ) {
wpc - > imap_valid = false ;
continue ;
}
if ( buffer_unwritten ( bh ) ) {
if ( wpc - > io_type ! = XFS_IO_UNWRITTEN ) {
wpc - > io_type = XFS_IO_UNWRITTEN ;
wpc - > imap_valid = false ;
}
} else if ( buffer_delay ( bh ) ) {
if ( wpc - > io_type ! = XFS_IO_DELALLOC ) {
wpc - > io_type = XFS_IO_DELALLOC ;
wpc - > imap_valid = false ;
}
} else if ( buffer_uptodate ( bh ) ) {
if ( wpc - > io_type ! = XFS_IO_OVERWRITE ) {
wpc - > io_type = XFS_IO_OVERWRITE ;
wpc - > imap_valid = false ;
}
} else {
if ( PageUptodate ( page ) )
ASSERT ( buffer_mapped ( bh ) ) ;
/*
* This buffer is not uptodate and will not be
* written to disk . Ensure that we will put any
* subsequent writeable buffers into a new
* ioend .
*/
wpc - > imap_valid = false ;
continue ;
}
if ( wpc - > imap_valid )
wpc - > imap_valid = xfs_imap_valid ( inode , & wpc - > imap ,
offset ) ;
if ( ! wpc - > imap_valid ) {
error = xfs_map_blocks ( inode , offset , & wpc - > imap ,
wpc - > io_type ) ;
if ( error )
2016-02-15 09:23:12 +03:00
goto out ;
2016-02-15 09:21:37 +03:00
wpc - > imap_valid = xfs_imap_valid ( inode , & wpc - > imap ,
offset ) ;
}
if ( wpc - > imap_valid ) {
lock_buffer ( bh ) ;
if ( wpc - > io_type ! = XFS_IO_OVERWRITE )
xfs_map_at_offset ( inode , bh , & wpc - > imap , offset ) ;
2016-02-15 09:23:12 +03:00
xfs_add_to_ioend ( inode , bh , offset , wpc , & submit_list ) ;
2016-02-15 09:21:37 +03:00
count + + ;
}
} while ( offset + = len , ( ( bh = bh - > b_this_page ) ! = head ) ) ;
if ( uptodate & & bh = = head )
SetPageUptodate ( page ) ;
2016-02-15 09:23:12 +03:00
ASSERT ( wpc - > ioend | | list_empty ( & submit_list ) ) ;
2016-02-15 09:21:37 +03:00
2016-02-15 09:23:12 +03:00
out :
2016-02-15 09:21:37 +03:00
/*
2016-02-15 09:23:12 +03:00
* On error , we have to fail the ioend here because we have locked
* buffers in the ioend . If we don ' t do this , we ' ll deadlock
* invalidating the page as that tries to lock the buffers on the page .
* Also , because we may have set pages under writeback , we have to make
* sure we run IO completion to mark the error state of the IO
* appropriately , so we can ' t cancel the ioend directly here . That means
* we have to mark this page as under writeback if we included any
* buffers from it in the ioend chain so that completion treats it
* correctly .
2016-02-15 09:21:37 +03:00
*
2016-02-15 09:23:12 +03:00
* If we didn ' t include the page in the ioend , the on error we can
* simply discard and unlock it as there are no other users of the page
* or it ' s buffers right now . The caller will still need to trigger
* submission of outstanding ioends on the writepage context so they are
* treated correctly on error .
2016-02-15 09:21:37 +03:00
*/
2016-02-15 09:23:12 +03:00
if ( count ) {
xfs_start_page_writeback ( page , ! error ) ;
/*
* Preserve the original error if there was one , otherwise catch
* submission errors here and propagate into subsequent ioend
* submissions .
*/
list_for_each_entry_safe ( ioend , next , & submit_list , io_list ) {
int error2 ;
list_del_init ( & ioend - > io_list ) ;
error2 = xfs_submit_ioend ( wbc , ioend , error ) ;
if ( error2 & & ! error )
error = error2 ;
}
} else if ( error ) {
2016-02-15 09:21:37 +03:00
xfs_aops_discard_page ( page ) ;
ClearPageUptodate ( page ) ;
unlock_page ( page ) ;
2016-02-15 09:23:12 +03:00
} else {
/*
* We can end up here with no error and nothing to write if we
* race with a partial page truncate on a sub - page block sized
* filesystem . In that case we need to mark the page clean .
*/
xfs_start_page_writeback ( page , 1 ) ;
end_page_writeback ( page ) ;
2016-02-15 09:21:37 +03:00
}
2016-02-15 09:23:12 +03:00
2016-02-15 09:21:37 +03:00
mapping_set_error ( page - > mapping , error ) ;
return error ;
}
2005-04-17 02:20:36 +04:00
/*
2010-06-24 03:45:48 +04:00
* Write out a dirty page .
*
* For delalloc space on the page we need to allocate space and flush it .
* For unwritten space on the page we need to start the conversion to
* regular allocated space .
* For any other dirty buffer heads on the page we should flush them .
2005-04-17 02:20:36 +04:00
*/
STATIC int
2016-02-15 09:21:19 +03:00
xfs_do_writepage (
2010-06-24 03:45:48 +04:00
struct page * page ,
2016-02-15 09:21:19 +03:00
struct writeback_control * wbc ,
void * data )
2005-04-17 02:20:36 +04:00
{
2016-02-15 09:21:19 +03:00
struct xfs_writepage_ctx * wpc = data ;
2010-06-24 03:45:48 +04:00
struct inode * inode = page - > mapping - > host ;
2005-04-17 02:20:36 +04:00
loff_t offset ;
__uint64_t end_offset ;
2016-02-15 09:21:31 +03:00
pgoff_t end_index ;
2010-06-24 03:45:48 +04:00
2013-05-22 07:58:01 +04:00
trace_xfs_writepage ( inode , page , 0 , 0 ) ;
2010-06-24 03:45:48 +04:00
2010-06-24 03:46:01 +04:00
ASSERT ( page_has_buffers ( page ) ) ;
2010-06-24 03:45:48 +04:00
/*
* Refuse to write the page out if we are called from reclaim context .
*
2010-06-28 18:34:44 +04:00
* This avoids stack overflows when called from deeply used stacks in
* random callers for direct reclaim or memcg reclaim . We explicitly
* allow reclaim from kswapd as the stack usage there is relatively low .
2010-06-24 03:45:48 +04:00
*
2011-11-01 04:07:45 +04:00
* This should never happen except in the case of a VM regression so
* warn about it .
2010-06-24 03:45:48 +04:00
*/
2011-11-01 04:07:45 +04:00
if ( WARN_ON_ONCE ( ( current - > flags & ( PF_MEMALLOC | PF_KSWAPD ) ) = =
PF_MEMALLOC ) )
2010-08-24 05:47:51 +04:00
goto redirty ;
2005-04-17 02:20:36 +04:00
2010-06-24 03:45:48 +04:00
/*
2011-07-08 16:34:05 +04:00
* Given that we do not allow direct reclaim to call us , we should
* never be called while in a filesystem transaction .
2010-06-24 03:45:48 +04:00
*/
2014-06-06 10:05:15 +04:00
if ( WARN_ON_ONCE ( current - > flags & PF_FSTRANS ) )
2010-08-24 05:47:51 +04:00
goto redirty ;
2010-06-24 03:45:48 +04:00
2014-05-20 02:24:26 +04:00
/*
2016-02-15 09:21:31 +03:00
* Is this page beyond the end of the file ?
*
2014-05-20 02:24:26 +04:00
* The page index is less than the end_index , adjust the end_offset
* to the highest offset that this page should represent .
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* | file mapping | < EOF > |
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* | Page . . . | Page N - 2 | Page N - 1 | Page N | |
* ^ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ^ - - - - - - - - - - | - - - - - - - -
* | desired writeback range | see else |
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ^ - - - - - - - - - - - - - - - - - - |
*/
2016-02-15 09:21:31 +03:00
offset = i_size_read ( inode ) ;
end_index = offset > > PAGE_CACHE_SHIFT ;
2014-05-20 02:24:26 +04:00
if ( page - > index < end_index )
end_offset = ( xfs_off_t ) ( page - > index + 1 ) < < PAGE_CACHE_SHIFT ;
else {
/*
* Check whether the page to write out is beyond or straddles
* i_size or not .
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* | file mapping | < EOF > |
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* | Page . . . | Page N - 2 | Page N - 1 | Page N | Beyond |
* ^ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ^ - - - - - - - - - - - | - - - - - - - - -
* | | Straddles |
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ^ - - - - - - - - - - - | - - - - - - - - |
*/
2012-07-03 20:20:00 +04:00
unsigned offset_into_page = offset & ( PAGE_CACHE_SIZE - 1 ) ;
/*
2013-03-14 17:30:54 +04:00
* Skip the page if it is fully outside i_size , e . g . due to a
* truncate operation that is in progress . We must redirty the
* page so that reclaim stops reclaiming it . Otherwise
* xfs_vm_releasepage ( ) is called on it and gets confused .
2014-05-20 02:24:26 +04:00
*
* Note that the end_index is unsigned long , it would overflow
* if the given offset is greater than 16 TB on 32 - bit system
* and if we do check the page is fully outside i_size or not
* via " if (page->index >= end_index + 1) " as " end_index + 1 "
* will be evaluated to 0. Hence this page will be redirtied
* and be written out repeatedly which would result in an
* infinite loop , the user program that perform this operation
* will hang . Instead , we can verify this situation by checking
* if the page to write is totally beyond the i_size or if it ' s
* offset is just equal to the EOF .
2012-07-03 20:20:00 +04:00
*/
2014-05-20 02:24:26 +04:00
if ( page - > index > end_index | |
( page - > index = = end_index & & offset_into_page = = 0 ) )
2013-03-14 17:30:54 +04:00
goto redirty ;
2012-07-03 20:20:00 +04:00
/*
* The page straddles i_size . It must be zeroed out on each
* and every writepage invocation because it may be mmapped .
* " A file is mapped in multiples of the page size. For a file
2014-05-20 02:24:26 +04:00
* that is not a multiple of the page size , the remaining
2012-07-03 20:20:00 +04:00
* memory is zeroed when mapped , and writes to that region are
* not written out to the file . "
*/
zero_user_segment ( page , offset_into_page , PAGE_CACHE_SIZE ) ;
2014-05-20 02:24:26 +04:00
/* Adjust the end_offset to the end of file */
end_offset = offset ;
2005-04-17 02:20:36 +04:00
}
2016-02-15 09:23:12 +03:00
return xfs_writepage_map ( wpc , wbc , inode , page , offset , end_offset ) ;
2006-03-14 05:26:27 +03:00
2010-08-24 05:47:51 +04:00
redirty :
2006-03-14 05:26:27 +03:00
redirty_page_for_writepage ( wbc , page ) ;
unlock_page ( page ) ;
return 0 ;
}
2016-02-15 09:21:19 +03:00
STATIC int
xfs_vm_writepage (
struct page * page ,
struct writeback_control * wbc )
{
struct xfs_writepage_ctx wpc = {
. io_type = XFS_IO_INVALID ,
} ;
int ret ;
ret = xfs_do_writepage ( page , wbc , & wpc ) ;
2016-02-15 09:23:12 +03:00
if ( wpc . ioend )
ret = xfs_submit_ioend ( wbc , wpc . ioend , ret ) ;
return ret ;
2016-02-15 09:21:19 +03:00
}
2006-06-09 09:27:16 +04:00
STATIC int
xfs_vm_writepages (
struct address_space * mapping ,
struct writeback_control * wbc )
{
2016-02-15 09:21:19 +03:00
struct xfs_writepage_ctx wpc = {
. io_type = XFS_IO_INVALID ,
} ;
int ret ;
2007-08-29 05:44:37 +04:00
xfs_iflags_clear ( XFS_I ( mapping - > host ) , XFS_ITRUNCATED ) ;
2016-02-27 02:19:55 +03:00
if ( dax_mapping ( mapping ) )
return dax_writeback_mapping_range ( mapping ,
xfs_find_bdev_for_inode ( mapping - > host ) , wbc ) ;
2016-02-15 09:21:19 +03:00
ret = write_cache_pages ( mapping , wbc , xfs_do_writepage , & wpc ) ;
2016-02-15 09:23:12 +03:00
if ( wpc . ioend )
ret = xfs_submit_ioend ( wbc , wpc . ioend , ret ) ;
return ret ;
2006-06-09 09:27:16 +04:00
}
2006-03-14 05:26:27 +03:00
/*
* Called to move a page into cleanable state - and from there
2010-06-24 03:45:48 +04:00
* to be released . The page should already be clean . We always
2006-03-14 05:26:27 +03:00
* have buffer heads in this call .
*
2010-06-24 03:45:48 +04:00
* Returns 1 if the page is ok to release , 0 otherwise .
2006-03-14 05:26:27 +03:00
*/
STATIC int
2006-03-17 09:26:25 +03:00
xfs_vm_releasepage (
2006-03-14 05:26:27 +03:00
struct page * page ,
gfp_t gfp_mask )
{
2010-06-24 03:46:01 +04:00
int delalloc , unwritten ;
2006-03-14 05:26:27 +03:00
2013-05-22 07:58:01 +04:00
trace_xfs_releasepage ( page - > mapping - > host , page , 0 , 0 ) ;
2006-03-17 09:26:25 +03:00
2010-06-24 03:46:01 +04:00
xfs_count_page_state ( page , & delalloc , & unwritten ) ;
2006-03-14 05:26:27 +03:00
2014-06-06 10:05:15 +04:00
if ( WARN_ON_ONCE ( delalloc ) )
2006-03-14 05:26:27 +03:00
return 0 ;
2014-06-06 10:05:15 +04:00
if ( WARN_ON_ONCE ( unwritten ) )
2006-03-14 05:26:27 +03:00
return 0 ;
return try_to_free_buffers ( page ) ;
}
2015-04-16 14:57:48 +03:00
/*
2016-02-08 06:40:51 +03:00
* When we map a DIO buffer , we may need to pass flags to
* xfs_end_io_direct_write to tell it what kind of write IO we are doing .
2015-11-03 04:27:22 +03:00
*
* Note that for DIO , an IO to the highest supported file block offset ( i . e .
* 2 ^ 63 - 1F SB bytes ) will result in the offset + count overflowing a signed 64
* bit variable . Hence if we see this overflow , we have to assume that the IO is
* extending the file size . We won ' t know for sure until IO completion is run
* and the actual max write offset is communicated to the IO completion
* routine .
2015-04-16 14:57:48 +03:00
*/
static void
xfs_map_direct (
struct inode * inode ,
struct buffer_head * bh_result ,
struct xfs_bmbt_irec * imap ,
2016-02-08 06:40:51 +03:00
xfs_off_t offset )
2015-04-16 14:57:48 +03:00
{
2016-02-08 06:40:51 +03:00
uintptr_t * flags = ( uintptr_t * ) & bh_result - > b_private ;
2015-04-16 14:59:07 +03:00
xfs_off_t size = bh_result - > b_size ;
2016-02-08 06:40:51 +03:00
trace_xfs_get_blocks_map_direct ( XFS_I ( inode ) , offset , size ,
ISUNWRITTEN ( imap ) ? XFS_IO_UNWRITTEN : XFS_IO_OVERWRITE , imap ) ;
2015-04-16 14:59:07 +03:00
2016-02-08 06:40:51 +03:00
if ( ISUNWRITTEN ( imap ) ) {
* flags | = XFS_DIO_FLAG_UNWRITTEN ;
set_buffer_defer_completion ( bh_result ) ;
} else if ( offset + size > i_size_read ( inode ) | | offset + size < 0 ) {
* flags | = XFS_DIO_FLAG_APPEND ;
2015-04-16 15:00:00 +03:00
set_buffer_defer_completion ( bh_result ) ;
2015-04-16 14:57:48 +03:00
}
}
2015-04-16 14:58:21 +03:00
/*
* If this is O_DIRECT or the mpage code calling tell them how large the mapping
* is , so that we can avoid repeated get_blocks calls .
*
* If the mapping spans EOF , then we have to break the mapping up as the mapping
* for blocks beyond EOF must be marked new so that sub block regions can be
* correctly zeroed . We can ' t do this for mappings within EOF unless the mapping
* was just allocated or is unwritten , otherwise the callers would overwrite
* existing data with zeros . Hence we have to split the mapping into a range up
* to and including EOF , and a second mapping for beyond EOF .
*/
static void
xfs_map_trim_size (
struct inode * inode ,
sector_t iblock ,
struct buffer_head * bh_result ,
struct xfs_bmbt_irec * imap ,
xfs_off_t offset ,
ssize_t size )
{
xfs_off_t mapping_size ;
mapping_size = imap - > br_startoff + imap - > br_blockcount - iblock ;
mapping_size < < = inode - > i_blkbits ;
ASSERT ( mapping_size > 0 ) ;
if ( mapping_size > size )
mapping_size = size ;
if ( offset < i_size_read ( inode ) & &
offset + mapping_size > = i_size_read ( inode ) ) {
/* limit mapping to block that spans EOF */
mapping_size = roundup_64 ( i_size_read ( inode ) - offset ,
1 < < inode - > i_blkbits ) ;
}
if ( mapping_size > LONG_MAX )
mapping_size = LONG_MAX ;
bh_result - > b_size = mapping_size ;
}
2005-04-17 02:20:36 +04:00
STATIC int
2006-03-29 04:44:40 +04:00
__xfs_get_blocks (
2005-04-17 02:20:36 +04:00
struct inode * inode ,
sector_t iblock ,
struct buffer_head * bh_result ,
int create ,
2015-11-03 04:27:22 +03:00
bool direct ,
bool dax_fault )
2005-04-17 02:20:36 +04:00
{
2010-12-10 11:42:20 +03:00
struct xfs_inode * ip = XFS_I ( inode ) ;
struct xfs_mount * mp = ip - > i_mount ;
xfs_fileoff_t offset_fsb , end_fsb ;
int error = 0 ;
int lockmode = 0 ;
2010-04-28 16:28:56 +04:00
struct xfs_bmbt_irec imap ;
2010-12-10 11:42:20 +03:00
int nimaps = 1 ;
2005-11-02 07:13:13 +03:00
xfs_off_t offset ;
ssize_t size ;
2010-04-28 16:28:56 +04:00
int new = 0 ;
2010-12-10 11:42:20 +03:00
if ( XFS_FORCED_SHUTDOWN ( mp ) )
2014-06-22 09:04:54 +04:00
return - EIO ;
2005-04-17 02:20:36 +04:00
2005-11-02 07:13:13 +03:00
offset = ( xfs_off_t ) iblock < < inode - > i_blkbits ;
2006-03-29 04:44:40 +04:00
ASSERT ( bh_result - > b_size > = ( 1 < < inode - > i_blkbits ) ) ;
size = bh_result - > b_size ;
2008-09-17 10:50:14 +04:00
if ( ! create & & direct & & offset > = i_size_read ( inode ) )
return 0 ;
2012-03-27 18:34:50 +04:00
/*
* Direct I / O is usually done on preallocated files , so try getting
* a block mapping without an exclusive lock first . For buffered
* writes we already have the exclusive iolock anyway , so avoiding
* a lock roundtrip here by taking the ilock exclusive from the
* beginning is a useful micro optimization .
*/
if ( create & & ! direct ) {
2010-12-10 11:42:20 +03:00
lockmode = XFS_ILOCK_EXCL ;
xfs_ilock ( ip , lockmode ) ;
} else {
2013-12-07 00:30:09 +04:00
lockmode = xfs_ilock_data_map_shared ( ip ) ;
2010-12-10 11:42:20 +03:00
}
2010-06-24 05:44:35 +04:00
2012-06-08 09:44:53 +04:00
ASSERT ( offset < = mp - > m_super - > s_maxbytes ) ;
if ( offset + size > mp - > m_super - > s_maxbytes )
size = mp - > m_super - > s_maxbytes - offset ;
2010-12-10 11:42:20 +03:00
end_fsb = XFS_B_TO_FSB ( mp , ( xfs_ufsize_t ) offset + size ) ;
offset_fsb = XFS_B_TO_FSBT ( mp , offset ) ;
2011-09-19 00:40:45 +04:00
error = xfs_bmapi_read ( ip , offset_fsb , end_fsb - offset_fsb ,
& imap , & nimaps , XFS_BMAPI_ENTIRE ) ;
2005-04-17 02:20:36 +04:00
if ( error )
2010-12-10 11:42:20 +03:00
goto out_unlock ;
xfs: Don't use unwritten extents for DAX
DAX has a page fault serialisation problem with block allocation.
Because it allows concurrent page faults and does not have a page
lock to serialise faults to the same page, it can get two concurrent
faults to the page that race.
When two read faults race, this isn't a huge problem as the data
underlying the page is not changing and so "detect and drop" works
just fine. The issues are to do with write faults.
When two write faults occur, we serialise block allocation in
get_blocks() so only one faul will allocate the extent. It will,
however, be marked as an unwritten extent, and that is where the
problem lies - the DAX fault code cannot differentiate between a
block that was just allocated and a block that was preallocated and
needs zeroing. The result is that both write faults end up zeroing
the block and attempting to convert it back to written.
The problem is that the first fault can zero and convert before the
second fault starts zeroing, resulting in the zeroing for the second
fault overwriting the data that the first fault wrote with zeros.
The second fault then attempts to convert the unwritten extent,
which is then a no-op because it's already written. Data loss occurs
as a result of this race.
Because there is no sane locking construct in the page fault code
that we can use for serialisation across the page faults, we need to
ensure block allocation and zeroing occurs atomically in the
filesystem. This means we can still take concurrent page faults and
the only time they will serialise is in the filesystem
mapping/allocation callback. The page fault code will always see
written, initialised extents, so we will be able to remove the
unwritten extent handling from the DAX code when all filesystems are
converted.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-11-03 04:37:00 +03:00
/* for DAX, we convert unwritten extents directly */
2010-12-10 11:42:20 +03:00
if ( create & &
( ! nimaps | |
( imap . br_startblock = = HOLESTARTBLOCK | |
xfs: Don't use unwritten extents for DAX
DAX has a page fault serialisation problem with block allocation.
Because it allows concurrent page faults and does not have a page
lock to serialise faults to the same page, it can get two concurrent
faults to the page that race.
When two read faults race, this isn't a huge problem as the data
underlying the page is not changing and so "detect and drop" works
just fine. The issues are to do with write faults.
When two write faults occur, we serialise block allocation in
get_blocks() so only one faul will allocate the extent. It will,
however, be marked as an unwritten extent, and that is where the
problem lies - the DAX fault code cannot differentiate between a
block that was just allocated and a block that was preallocated and
needs zeroing. The result is that both write faults end up zeroing
the block and attempting to convert it back to written.
The problem is that the first fault can zero and convert before the
second fault starts zeroing, resulting in the zeroing for the second
fault overwriting the data that the first fault wrote with zeros.
The second fault then attempts to convert the unwritten extent,
which is then a no-op because it's already written. Data loss occurs
as a result of this race.
Because there is no sane locking construct in the page fault code
that we can use for serialisation across the page faults, we need to
ensure block allocation and zeroing occurs atomically in the
filesystem. This means we can still take concurrent page faults and
the only time they will serialise is in the filesystem
mapping/allocation callback. The page fault code will always see
written, initialised extents, so we will be able to remove the
unwritten extent handling from the DAX code when all filesystems are
converted.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-11-03 04:37:00 +03:00
imap . br_startblock = = DELAYSTARTBLOCK ) | |
( IS_DAX ( inode ) & & ISUNWRITTEN ( & imap ) ) ) ) {
xfs: Use preallocation for inodes with extsz hints
xfstest 229 exposes a problem with buffered IO, delayed allocation
and extent size hints. That is when we do delayed allocation during
buffered IO, we reserve space for the extent size hint alignment and
allocate the physical space to align the extent, but we do not zero
the regions of the extent that aren't written by the write(2)
syscall. The result is that we expose stale data in unwritten
regions of the extent size hints.
There are two ways to fix this. The first is to detect that we are
doing unaligned writes, check if there is already a mapping or data
over the extent size hint range, and if not zero the page cache
first before then doing the real write. This can be very expensive
for large extent size hints, especially if the subsequent writes
fill then entire extent size before the data is written to disk.
The second, and simpler way, is simply to turn off delayed
allocation when the extent size hint is set and use preallocation
instead. This results in unwritten extents being laid down on disk
and so only the written portions will be converted. This matches the
behaviour for direct IO, and will also work for the real time
device. The disadvantage of this approach is that for small extent
size hints we can get file fragmentation, but in general extent size
hints are fairly large (e.g. stripe width sized) so this isn't a big
deal.
Implement the second approach as it is simple and effective.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-23 09:58:44 +04:00
if ( direct | | xfs_get_extsz_hint ( ip ) ) {
2012-03-27 18:34:50 +04:00
/*
2015-10-12 07:34:20 +03:00
* xfs_iomap_write_direct ( ) expects the shared lock . It
* is unlocked on return .
2012-03-27 18:34:50 +04:00
*/
2015-10-12 07:34:20 +03:00
if ( lockmode = = XFS_ILOCK_EXCL )
xfs_ilock_demote ( ip , lockmode ) ;
2010-12-10 11:42:20 +03:00
error = xfs_iomap_write_direct ( ip , offset , size ,
& imap , nimaps ) ;
2012-03-27 18:34:50 +04:00
if ( error )
2014-06-25 08:58:08 +04:00
return error ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
new = 1 ;
2015-06-04 02:18:53 +03:00
2010-12-10 11:42:20 +03:00
} else {
2012-03-27 18:34:50 +04:00
/*
* Delalloc reservations do not require a transaction ,
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
* we can go on without dropping the lock here . If we
* are allocating a new delalloc block , make sure that
* we set the new flag so that we mark the buffer new so
* that we know that it is newly allocated if the write
* fails .
2012-03-27 18:34:50 +04:00
*/
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
if ( nimaps & & imap . br_startblock = = HOLESTARTBLOCK )
new = 1 ;
2010-12-10 11:42:20 +03:00
error = xfs_iomap_write_delay ( ip , offset , size , & imap ) ;
2012-03-27 18:34:50 +04:00
if ( error )
goto out_unlock ;
xfs_iunlock ( ip , lockmode ) ;
2010-12-10 11:42:20 +03:00
}
2015-04-16 14:59:07 +03:00
trace_xfs_get_blocks_alloc ( ip , offset , size ,
ISUNWRITTEN ( & imap ) ? XFS_IO_UNWRITTEN
: XFS_IO_DELALLOC , & imap ) ;
2010-12-10 11:42:20 +03:00
} else if ( nimaps ) {
2015-04-16 14:59:07 +03:00
trace_xfs_get_blocks_found ( ip , offset , size ,
ISUNWRITTEN ( & imap ) ? XFS_IO_UNWRITTEN
: XFS_IO_OVERWRITE , & imap ) ;
2012-03-27 18:34:50 +04:00
xfs_iunlock ( ip , lockmode ) ;
2010-12-10 11:42:20 +03:00
} else {
trace_xfs_get_blocks_notfound ( ip , offset , size ) ;
goto out_unlock ;
}
2005-04-17 02:20:36 +04:00
xfs: Don't use unwritten extents for DAX
DAX has a page fault serialisation problem with block allocation.
Because it allows concurrent page faults and does not have a page
lock to serialise faults to the same page, it can get two concurrent
faults to the page that race.
When two read faults race, this isn't a huge problem as the data
underlying the page is not changing and so "detect and drop" works
just fine. The issues are to do with write faults.
When two write faults occur, we serialise block allocation in
get_blocks() so only one faul will allocate the extent. It will,
however, be marked as an unwritten extent, and that is where the
problem lies - the DAX fault code cannot differentiate between a
block that was just allocated and a block that was preallocated and
needs zeroing. The result is that both write faults end up zeroing
the block and attempting to convert it back to written.
The problem is that the first fault can zero and convert before the
second fault starts zeroing, resulting in the zeroing for the second
fault overwriting the data that the first fault wrote with zeros.
The second fault then attempts to convert the unwritten extent,
which is then a no-op because it's already written. Data loss occurs
as a result of this race.
Because there is no sane locking construct in the page fault code
that we can use for serialisation across the page faults, we need to
ensure block allocation and zeroing occurs atomically in the
filesystem. This means we can still take concurrent page faults and
the only time they will serialise is in the filesystem
mapping/allocation callback. The page fault code will always see
written, initialised extents, so we will be able to remove the
unwritten extent handling from the DAX code when all filesystems are
converted.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2015-11-03 04:37:00 +03:00
if ( IS_DAX ( inode ) & & create ) {
ASSERT ( ! ISUNWRITTEN ( & imap ) ) ;
/* zeroing is not needed at a higher layer */
new = 0 ;
}
2015-04-16 14:58:21 +03:00
/* trim mapping down to size requested */
if ( direct | | size > ( 1 < < inode - > i_blkbits ) )
xfs_map_trim_size ( inode , iblock , bh_result ,
& imap , offset , size ) ;
2015-04-16 14:57:48 +03:00
/*
* For unwritten extents do not report a disk address in the buffered
* read case ( treat as if we ' re reading into a hole ) .
*/
2010-04-28 16:28:56 +04:00
if ( imap . br_startblock ! = HOLESTARTBLOCK & &
2015-04-16 14:57:48 +03:00
imap . br_startblock ! = DELAYSTARTBLOCK & &
( create | | ! ISUNWRITTEN ( & imap ) ) ) {
xfs_map_buffer ( inode , bh_result , & imap , offset ) ;
if ( ISUNWRITTEN ( & imap ) )
2005-04-17 02:20:36 +04:00
set_buffer_unwritten ( bh_result ) ;
2015-04-16 14:57:48 +03:00
/* direct IO needs special help */
2016-02-08 06:40:51 +03:00
if ( create & & direct ) {
if ( dax_fault )
ASSERT ( ! ISUNWRITTEN ( & imap ) ) ;
else
xfs_map_direct ( inode , bh_result , & imap , offset ) ;
}
2005-04-17 02:20:36 +04:00
}
2006-03-29 04:44:40 +04:00
/*
* If this is a realtime file , data may be on a different device .
* to that pointed to from the buffer_head b_bdev currently .
*/
2010-04-28 16:28:52 +04:00
bh_result - > b_bdev = xfs_find_bdev_for_inode ( inode ) ;
2005-04-17 02:20:36 +04:00
2006-03-29 04:44:40 +04:00
/*
2007-02-10 10:36:35 +03:00
* If we previously allocated a block out beyond eof and we are now
* coming back to use it then we will need to flag it as new even if it
* has a disk address .
*
* With sub - block writes into unwritten extents we also need to mark
* the buffer as new so that the unwritten parts of the buffer gets
* correctly zeroed .
2005-04-17 02:20:36 +04:00
*/
if ( create & &
( ( ! buffer_mapped ( bh_result ) & & ! buffer_uptodate ( bh_result ) ) | |
2007-02-10 10:36:35 +03:00
( offset > = i_size_read ( inode ) ) | |
2010-04-28 16:28:56 +04:00
( new | | ISUNWRITTEN ( & imap ) ) ) )
2005-04-17 02:20:36 +04:00
set_buffer_new ( bh_result ) ;
2010-04-28 16:28:56 +04:00
if ( imap . br_startblock = = DELAYSTARTBLOCK ) {
2005-04-17 02:20:36 +04:00
BUG_ON ( direct ) ;
if ( create ) {
set_buffer_uptodate ( bh_result ) ;
set_buffer_mapped ( bh_result ) ;
set_buffer_delay ( bh_result ) ;
}
}
return 0 ;
2010-12-10 11:42:20 +03:00
out_unlock :
xfs_iunlock ( ip , lockmode ) ;
2014-06-25 08:58:08 +04:00
return error ;
2005-04-17 02:20:36 +04:00
}
int
2006-03-29 04:44:40 +04:00
xfs_get_blocks (
2005-04-17 02:20:36 +04:00
struct inode * inode ,
sector_t iblock ,
struct buffer_head * bh_result ,
int create )
{
2015-11-03 04:27:22 +03:00
return __xfs_get_blocks ( inode , iblock , bh_result , create , false , false ) ;
2005-04-17 02:20:36 +04:00
}
2015-06-04 02:18:53 +03:00
int
2006-03-14 05:54:26 +03:00
xfs_get_blocks_direct (
2005-04-17 02:20:36 +04:00
struct inode * inode ,
sector_t iblock ,
struct buffer_head * bh_result ,
int create )
{
2015-11-03 04:27:22 +03:00
return __xfs_get_blocks ( inode , iblock , bh_result , create , true , false ) ;
}
int
xfs_get_blocks_dax_fault (
struct inode * inode ,
sector_t iblock ,
struct buffer_head * bh_result ,
int create )
{
return __xfs_get_blocks ( inode , iblock , bh_result , create , true , true ) ;
2005-04-17 02:20:36 +04:00
}
2016-02-08 06:40:51 +03:00
/*
* Complete a direct I / O write request .
*
* xfs_map_direct passes us some flags in the private data to tell us what to
* do . If no flags are set , then the write IO is an overwrite wholly within
* the existing allocated file size and so there is nothing for us to do .
*
* Note that in this case the completion can be called in interrupt context ,
* whereas if we have flags set we will always be called in task context
* ( i . e . from a workqueue ) .
*/
STATIC int
xfs_end_io_direct_write (
struct kiocb * iocb ,
2010-07-19 01:17:11 +04:00
loff_t offset ,
2016-02-08 06:40:51 +03:00
ssize_t size ,
void * private )
2005-09-05 02:22:52 +04:00
{
2016-02-08 06:40:51 +03:00
struct inode * inode = file_inode ( iocb - > ki_filp ) ;
struct xfs_inode * ip = XFS_I ( inode ) ;
struct xfs_mount * mp = ip - > i_mount ;
uintptr_t flags = ( uintptr_t ) private ;
int error = 0 ;
2015-04-16 15:00:00 +03:00
2016-02-08 06:40:51 +03:00
trace_xfs_end_io_direct_write ( ip , offset , size ) ;
2005-09-05 02:22:52 +04:00
2016-02-08 06:40:51 +03:00
if ( XFS_FORCED_SHUTDOWN ( mp ) )
return - EIO ;
2015-04-16 14:59:07 +03:00
2016-02-08 06:40:51 +03:00
if ( size < = 0 )
return size ;
2005-09-05 02:22:52 +04:00
2011-12-19 00:00:12 +04:00
/*
2016-02-08 06:40:51 +03:00
* The flags tell us whether we are doing unwritten extent conversions
2015-04-16 14:59:34 +03:00
* or an append transaction that updates the on - disk file size . These
* cases are the only cases where we should * potentially * be needing
2015-04-16 15:00:00 +03:00
* to update the VFS inode size .
2016-02-08 06:40:51 +03:00
*/
if ( flags = = 0 ) {
ASSERT ( offset + size < = i_size_read ( inode ) ) ;
return 0 ;
}
/*
2015-04-16 14:59:34 +03:00
* We need to update the in - core inode size here so that we don ' t end up
2015-04-16 15:00:00 +03:00
* with the on - disk inode size being outside the in - core inode size . We
* have no other method of updating EOF for AIO , so always do it here
* if necessary .
2015-04-16 15:03:07 +03:00
*
* We need to lock the test / set EOF update as we can be racing with
* other IO completions here to update the EOF . Failing to serialise
* here can result in EOF moving backwards and Bad Things Happen when
* that occurs .
2011-12-19 00:00:12 +04:00
*/
2016-02-08 06:40:51 +03:00
spin_lock ( & ip - > i_flags_lock ) ;
2015-02-02 02:02:09 +03:00
if ( offset + size > i_size_read ( inode ) )
i_size_write ( inode , offset + size ) ;
2016-02-08 06:40:51 +03:00
spin_unlock ( & ip - > i_flags_lock ) ;
2011-12-19 00:00:12 +04:00
2016-02-08 06:40:51 +03:00
if ( flags & XFS_DIO_FLAG_UNWRITTEN ) {
trace_xfs_end_io_direct_write_unwritten ( ip , offset , size ) ;
2010-07-19 01:17:11 +04:00
2016-02-08 06:40:51 +03:00
error = xfs_iomap_write_unwritten ( ip , offset , size ) ;
} else if ( flags & XFS_DIO_FLAG_APPEND ) {
struct xfs_trans * tp ;
2005-09-05 02:22:52 +04:00
2016-02-08 06:40:51 +03:00
trace_xfs_end_io_direct_write_append ( ip , offset , size ) ;
2015-06-04 02:18:53 +03:00
2016-02-08 06:40:51 +03:00
tp = xfs_trans_alloc ( mp , XFS_TRANS_FSYNC_TS ) ;
error = xfs_trans_reserve ( tp , & M_RES ( mp ) - > tr_fsyncts , 0 , 0 ) ;
if ( error ) {
xfs_trans_cancel ( tp ) ;
return error ;
}
error = xfs_setfilesize ( ip , tp , offset , size ) ;
2015-06-04 02:18:53 +03:00
}
2016-02-08 06:40:51 +03:00
return error ;
2015-06-04 02:18:53 +03:00
}
2016-02-08 06:40:51 +03:00
STATIC ssize_t
xfs_vm_direct_IO (
2015-06-04 02:19:15 +03:00
struct kiocb * iocb ,
struct iov_iter * iter ,
2016-02-08 06:40:51 +03:00
loff_t offset )
2015-06-04 02:19:15 +03:00
{
2016-02-08 06:40:51 +03:00
struct inode * inode = iocb - > ki_filp - > f_mapping - > host ;
dio_iodone_t * endio = NULL ;
int flags = 0 ;
2015-06-04 02:19:15 +03:00
struct block_device * bdev ;
2016-02-08 06:40:51 +03:00
if ( iov_iter_rw ( iter ) = = WRITE ) {
endio = xfs_end_io_direct_write ;
flags = DIO_ASYNC_EXTEND ;
}
if ( IS_DAX ( inode ) ) {
2015-06-04 02:19:15 +03:00
return dax_do_io ( iocb , inode , iter , offset ,
xfs_get_blocks_direct , endio , 0 ) ;
2016-02-08 06:40:51 +03:00
}
2015-06-04 02:19:15 +03:00
bdev = xfs_find_bdev_for_inode ( inode ) ;
return __blockdev_direct_IO ( iocb , inode , bdev , iter , offset ,
2016-02-08 06:40:51 +03:00
xfs_get_blocks_direct , endio , NULL , flags ) ;
2005-04-17 02:20:36 +04:00
}
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
/*
* Punch out the delalloc blocks we have already allocated .
*
* Don ' t bother with xfs_setattr given that nothing can have made it to disk yet
* as the page is still locked at this point .
*/
STATIC void
xfs_vm_kill_delalloc_range (
struct inode * inode ,
loff_t start ,
loff_t end )
{
struct xfs_inode * ip = XFS_I ( inode ) ;
xfs_fileoff_t start_fsb ;
xfs_fileoff_t end_fsb ;
int error ;
start_fsb = XFS_B_TO_FSB ( ip - > i_mount , start ) ;
end_fsb = XFS_B_TO_FSB ( ip - > i_mount , end ) ;
if ( end_fsb < = start_fsb )
return ;
xfs_ilock ( ip , XFS_ILOCK_EXCL ) ;
error = xfs_bmap_punch_delalloc_range ( ip , start_fsb ,
end_fsb - start_fsb ) ;
if ( error ) {
/* something screwed, just bail */
if ( ! XFS_FORCED_SHUTDOWN ( ip - > i_mount ) ) {
xfs_alert ( ip - > i_mount ,
" xfs_vm_write_failed: unable to clean up ino %lld " ,
ip - > i_ino ) ;
}
}
xfs_iunlock ( ip , XFS_ILOCK_EXCL ) ;
}
2010-06-14 13:17:31 +04:00
STATIC void
xfs_vm_write_failed (
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
struct inode * inode ,
struct page * page ,
loff_t pos ,
unsigned len )
2010-06-14 13:17:31 +04:00
{
2013-07-16 09:11:16 +04:00
loff_t block_offset ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
loff_t block_start ;
loff_t block_end ;
loff_t from = pos & ( PAGE_CACHE_SIZE - 1 ) ;
loff_t to = from + len ;
struct buffer_head * bh , * head ;
2016-03-15 03:42:44 +03:00
struct xfs_mount * mp = XFS_I ( inode ) - > i_mount ;
2010-06-14 13:17:31 +04:00
2013-07-16 09:11:16 +04:00
/*
* The request pos offset might be 32 or 64 bit , this is all fine
* on 64 - bit platform . However , for 64 - bit pos request on 32 - bit
* platform , the high 32 - bit will be masked off if we evaluate the
* block_offset via ( pos & PAGE_MASK ) because the PAGE_MASK is
* 0xfffff000 as an unsigned long , hence the result is incorrect
* which could cause the following ASSERT failed in most cases .
* In order to avoid this , we can evaluate the block_offset of the
* start of the page by using shifts rather than masks the mismatch
* problem .
*/
block_offset = ( pos > > PAGE_CACHE_SHIFT ) < < PAGE_CACHE_SHIFT ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
ASSERT ( block_offset + from = = pos ) ;
2010-11-30 07:14:39 +03:00
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
head = page_buffers ( page ) ;
block_start = 0 ;
for ( bh = head ; bh ! = head | | ! block_start ;
bh = bh - > b_this_page , block_start = block_end ,
block_offset + = bh - > b_size ) {
block_end = block_start + bh - > b_size ;
2010-11-30 07:14:39 +03:00
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
/* skip buffers before the write */
if ( block_end < = from )
continue ;
/* if the buffer is after the write, we're done */
if ( block_start > = to )
break ;
2016-02-08 07:00:02 +03:00
/*
* Process delalloc and unwritten buffers beyond EOF . We can
* encounter unwritten buffers in the event that a file has
* post - EOF unwritten extents and an extending write happens to
* fail ( e . g . , an unaligned write that also involves a delalloc
* to the same page ) .
*/
if ( ! buffer_delay ( bh ) & & ! buffer_unwritten ( bh ) )
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
continue ;
2016-03-15 03:42:44 +03:00
if ( ! xfs_mp_fail_writes ( mp ) & & ! buffer_new ( bh ) & &
block_offset < i_size_read ( inode ) )
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
continue ;
2016-02-08 07:00:02 +03:00
if ( buffer_delay ( bh ) )
xfs_vm_kill_delalloc_range ( inode , block_offset ,
block_offset + bh - > b_size ) ;
2014-04-14 12:11:58 +04:00
/*
* This buffer does not contain data anymore . make sure anyone
* who finds it knows that for certain .
*/
clear_buffer_delay ( bh ) ;
clear_buffer_uptodate ( bh ) ;
clear_buffer_mapped ( bh ) ;
clear_buffer_new ( bh ) ;
clear_buffer_dirty ( bh ) ;
2016-02-08 07:00:02 +03:00
clear_buffer_unwritten ( bh ) ;
2010-06-14 13:17:31 +04:00
}
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
2010-06-14 13:17:31 +04:00
}
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
/*
* This used to call block_write_begin ( ) , but it unlocks and releases the page
* on error , and we need that page to be able to punch stale delalloc blocks out
* on failure . hence we copy - n - waste it here and call xfs_vm_write_failed ( ) at
* the appropriate point .
*/
2006-03-14 05:26:27 +03:00
STATIC int
2007-10-16 12:25:06 +04:00
xfs_vm_write_begin (
2006-03-14 05:26:27 +03:00
struct file * file ,
2007-10-16 12:25:06 +04:00
struct address_space * mapping ,
loff_t pos ,
unsigned len ,
unsigned flags ,
struct page * * pagep ,
void * * fsdata )
2006-03-14 05:26:27 +03:00
{
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
pgoff_t index = pos > > PAGE_CACHE_SHIFT ;
struct page * page ;
int status ;
2016-03-15 03:42:44 +03:00
struct xfs_mount * mp = XFS_I ( mapping - > host ) - > i_mount ;
2010-06-04 13:29:58 +04:00
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
ASSERT ( len < = PAGE_CACHE_SIZE ) ;
2013-10-29 15:11:57 +04:00
page = grab_cache_page_write_begin ( mapping , index , flags ) ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
if ( ! page )
return - ENOMEM ;
status = __block_write_begin ( page , pos , len , xfs_get_blocks ) ;
2016-03-15 03:42:44 +03:00
if ( xfs_mp_fail_writes ( mp ) )
status = - EIO ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
if ( unlikely ( status ) ) {
struct inode * inode = mapping - > host ;
2014-04-14 12:13:29 +04:00
size_t isize = i_size_read ( inode ) ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
xfs_vm_write_failed ( inode , page , pos , len ) ;
unlock_page ( page ) ;
2014-04-14 12:13:29 +04:00
/*
* If the write is beyond EOF , we only want to kill blocks
* allocated in this write , not blocks that were previously
* written successfully .
*/
2016-03-15 03:42:44 +03:00
if ( xfs_mp_fail_writes ( mp ) )
isize = 0 ;
2014-04-14 12:13:29 +04:00
if ( pos + len > isize ) {
ssize_t start = max_t ( ssize_t , pos , isize ) ;
truncate_pagecache_range ( inode , start , pos + len ) ;
}
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
page_cache_release ( page ) ;
page = NULL ;
}
* pagep = page ;
return status ;
2010-06-14 13:17:31 +04:00
}
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
/*
2014-04-14 12:14:11 +04:00
* On failure , we only need to kill delalloc blocks beyond EOF in the range of
* this specific write because they will never be written . Previous writes
* beyond EOF where block allocation succeeded do not need to be trashed , so
* only new blocks from this write should be trashed . For blocks within
* EOF , generic_write_end ( ) zeros them so they are safe to leave alone and be
* written with all the other valid data .
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
*/
2010-06-14 13:17:31 +04:00
STATIC int
xfs_vm_write_end (
struct file * file ,
struct address_space * mapping ,
loff_t pos ,
unsigned len ,
unsigned copied ,
struct page * page ,
void * fsdata )
{
int ret ;
2010-06-04 13:29:58 +04:00
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
ASSERT ( len < = PAGE_CACHE_SIZE ) ;
2010-06-14 13:17:31 +04:00
ret = generic_write_end ( file , mapping , pos , len , copied , page , fsdata ) ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
if ( unlikely ( ret < len ) ) {
struct inode * inode = mapping - > host ;
size_t isize = i_size_read ( inode ) ;
loff_t to = pos + len ;
if ( to > isize ) {
2014-04-14 12:14:11 +04:00
/* only kill blocks in this write beyond EOF */
if ( pos > isize )
isize = pos ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
xfs_vm_kill_delalloc_range ( inode , isize , to ) ;
2014-04-14 12:14:11 +04:00
truncate_pagecache_range ( inode , isize , to ) ;
xfs: punch new delalloc blocks out of failed writes inside EOF.
When a partial write inside EOF fails, it can leave delayed
allocation blocks lying around because they don't get punched back
out. This leads to assert failures like:
XFS: Assertion failed: XFS_FORCED_SHUTDOWN(ip->i_mount) || ip->i_delayed_blks == 0, file: fs/xfs/xfs_super.c, line: 847
when evicting inodes from the cache. This can be trivially triggered
by xfstests 083, which takes between 5 and 15 executions on a 512
byte block size filesystem to trip over this. Debugging shows a
failed write due to ENOSPC calling xfs_vm_write_failed such as:
[ 5012.329024] ino 0xa0026: vwf to 0x17000, sze 0x1c85ae
and no action is taken on it. This leaves behind a delayed
allocation extent that has no page covering it and no data in it:
[ 5015.867162] ino 0xa0026: blks: 0x83 delay blocks 0x1, size 0x2538c0
[ 5015.868293] ext 0: off 0x4a, fsb 0x50306, len 0x1
[ 5015.869095] ext 1: off 0x4b, fsb 0x7899, len 0x6b
[ 5015.869900] ext 2: off 0xb6, fsb 0xffffffffe0008, len 0x1
^^^^^^^^^^^^^^^
[ 5015.871027] ext 3: off 0x36e, fsb 0x7a27, len 0xd
[ 5015.872206] ext 4: off 0x4cf, fsb 0x7a1d, len 0xa
So the delayed allocation extent is one block long at offset
0x16c00. Tracing shows that a bigger write:
xfs_file_buffered_write: size 0x1c85ae offset 0x959d count 0x1ca3f ioflags
allocates the block, and then fails with ENOSPC trying to allocate
the last block on the page, leading to a failed write with stale
delalloc blocks on it.
Because we've had an ENOSPC when trying to allocate 0x16e00, it
means that we are never goinge to call ->write_end on the page and
so the allocated new buffer will not get marked dirty or have the
buffer_new state cleared. In other works, what the above write is
supposed to end up with is this mapping for the page:
+------+------+------+------+------+------+------+------+
UMA UMA UMA UMA UMA UMA UND FAIL
where: U = uptodate
M = mapped
N = new
A = allocated
D = delalloc
FAIL = block we ENOSPC'd on.
and the key point being the buffer_new() state for the newly
allocated delayed allocation block. Except it doesn't - we're not
marking buffers new correctly.
That buffer_new() problem goes back to the xfs_iomap removal days,
where xfs_iomap() used to return a "new" status for any map with
newly allocated blocks, so that __xfs_get_blocks() could call
set_buffer_new() on it. We still have the "new" variable and the
check for it in the set_buffer_new() logic - except we never set it
now!
Hence that newly allocated delalloc block doesn't have the new flag
set on it, so when the write fails we cannot tell which blocks we
are supposed to punch out. WHy do we need the buffer_new flag? Well,
that's because we can have this case:
+------+------+------+------+------+------+------+------+
UMD UMD UMD UMD UMD UMD UND FAIL
where all the UMD buffers contain valid data from a previously
successful write() system call. We only want to punch the UND buffer
because that's the only one that we added in this write and it was
only this write that failed.
That implies that even the old buffer_new() logic was wrong -
because it would result in all those UMD buffers on the page having
set_buffer_new() called on them even though they aren't new. Hence
we shoul donly be calling set_buffer_new() for delalloc buffers that
were allocated (i.e. were a hole before xfs_iomap_write_delay() was
called).
So, fix this set_buffer_new logic according to how we need it to
work for handling failed writes correctly. Also, restore the new
buffer logic handling for blocks allocated via
xfs_iomap_write_direct(), because it should still set the buffer_new
flag appropriately for newly allocated blocks, too.
SO, now we have the buffer_new() being set appropriately in
__xfs_get_blocks(), we can detect the exact delalloc ranges that
we allocated in a failed write, and hence can now do a walk of the
buffers on a page to find them.
Except, it's not that easy. When block_write_begin() fails, it
unlocks and releases the page that we just had an error on, so we
can't use that page to handle errors anymore. We have to get access
to the page while it is still locked to walk the buffers. Hence we
have to open code block_write_begin() in xfs_vm_write_begin() to be
able to insert xfs_vm_write_failed() is the right place.
With that, we can pass the page and write range to
xfs_vm_write_failed() and walk the buffers on the page, looking for
delalloc buffers that are either new or beyond EOF and punch them
out. Handling buffers beyond EOF ensures we still handle the
existing case that xfs_vm_write_failed() handles.
Of special note is the truncate_pagecache() handling - that only
should be done for pages outside EOF - pages within EOF can still
contain valid, dirty data so we must not punch them out of the
cache.
That just leaves the xfs_vm_write_end() failure handling.
The only failure case here is that we didn't copy the entire range,
and generic_write_end() handles that by zeroing the region of the
page that wasn't copied, we don't have to punch out blocks within
the file because they are guaranteed to contain zeros. Hence we only
have to handle the existing "beyond EOF" case and don't need access
to the buffers on the page. Hence it remains largely unchanged.
Note that xfs_getbmap() can still trip over delalloc blocks beyond
EOF that are left there by speculative delayed allocation. Hence
this bug fix does not solve all known issues with bmap vs delalloc,
but it does fix all the the known accidental occurances of the
problem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
2012-04-27 13:45:21 +04:00
}
}
2010-06-04 13:29:58 +04:00
return ret ;
2006-03-14 05:26:27 +03:00
}
2005-04-17 02:20:36 +04:00
STATIC sector_t
2006-03-14 05:54:26 +03:00
xfs_vm_bmap (
2005-04-17 02:20:36 +04:00
struct address_space * mapping ,
sector_t block )
{
struct inode * inode = ( struct inode * ) mapping - > host ;
2007-08-29 04:58:01 +04:00
struct xfs_inode * ip = XFS_I ( inode ) ;
2005-04-17 02:20:36 +04:00
2010-06-24 05:57:09 +04:00
trace_xfs_vm_bmap ( XFS_I ( inode ) ) ;
2008-03-06 05:44:57 +03:00
xfs_ilock ( ip , XFS_IOLOCK_SHARED ) ;
2012-11-12 15:53:56 +04:00
filemap_write_and_wait ( mapping ) ;
2008-03-06 05:44:57 +03:00
xfs_iunlock ( ip , XFS_IOLOCK_SHARED ) ;
2006-03-29 04:44:40 +04:00
return generic_block_bmap ( mapping , block , xfs_get_blocks ) ;
2005-04-17 02:20:36 +04:00
}
STATIC int
2006-03-14 05:54:26 +03:00
xfs_vm_readpage (
2005-04-17 02:20:36 +04:00
struct file * unused ,
struct page * page )
{
2016-01-08 03:28:35 +03:00
trace_xfs_vm_readpage ( page - > mapping - > host , 1 ) ;
2006-03-29 04:44:40 +04:00
return mpage_readpage ( page , xfs_get_blocks ) ;
2005-04-17 02:20:36 +04:00
}
STATIC int
2006-03-14 05:54:26 +03:00
xfs_vm_readpages (
2005-04-17 02:20:36 +04:00
struct file * unused ,
struct address_space * mapping ,
struct list_head * pages ,
unsigned nr_pages )
{
2016-01-08 03:28:35 +03:00
trace_xfs_vm_readpages ( mapping - > host , nr_pages ) ;
2006-03-29 04:44:40 +04:00
return mpage_readpages ( mapping , pages , nr_pages , xfs_get_blocks ) ;
2005-04-17 02:20:36 +04:00
}
xfs: don't dirty buffers beyond EOF
generic/263 is failing fsx at this point with a page spanning
EOF that cannot be invalidated. The operations are:
1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes)
1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes)
1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes)
where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO
write attempts to invalidate the cached page over this range, it
fails with -EBUSY and so any attempt to do page invalidation fails.
The real question is this: Why can't that page be invalidated after
it has been written to disk and cleaned?
Well, there's data on the first two buffers in the page (1k block
size, 4k page), but the third buffer on the page (i.e. beyond EOF)
is failing drop_buffers because it's bh->b_state == 0x3, which is
BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say
what?
OK, set_buffer_dirty() is called on all buffers from
__set_page_buffers_dirty(), regardless of whether the buffer is
beyond EOF or not, which means that when we get to ->writepage,
we have buffers marked dirty beyond EOF that we need to clean.
So, we need to implement our own .set_page_dirty method that
doesn't dirty buffers beyond EOF.
This is messy because the buffer code is not meant to be shared
and it has interesting locking issues on the buffer dirty bits.
So just copy and paste it and then modify it to suit what we need.
Note: the solutions the other filesystems and generic block code use
of marking the buffers clean in ->writepage does not work for XFS.
It still leaves dirty buffers beyond EOF and invalidations still
fail. Hence rather than play whack-a-mole, this patch simply
prevents those buffers from being dirtied in the first place.
cc: <stable@kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02 06:12:51 +04:00
/*
* This is basically a copy of __set_page_dirty_buffers ( ) with one
* small tweak : buffers beyond EOF do not get marked dirty . If we mark them
* dirty , we ' ll never be able to clean them because we don ' t write buffers
* beyond EOF , and that means we can ' t invalidate pages that span EOF
* that have been marked dirty . Further , the dirty state can leak into
* the file interior if the file is extended , resulting in all sorts of
* bad things happening as the state does not match the underlying data .
*
* XXX : this really indicates that bufferheads in XFS need to die . Warts like
* this only exist because of bufferheads and how the generic code manages them .
*/
STATIC int
xfs_vm_set_page_dirty (
struct page * page )
{
struct address_space * mapping = page - > mapping ;
struct inode * inode = mapping - > host ;
loff_t end_offset ;
loff_t offset ;
int newly_dirty ;
if ( unlikely ( ! mapping ) )
return ! TestSetPageDirty ( page ) ;
end_offset = i_size_read ( inode ) ;
offset = page_offset ( page ) ;
spin_lock ( & mapping - > private_lock ) ;
if ( page_has_buffers ( page ) ) {
struct buffer_head * head = page_buffers ( page ) ;
struct buffer_head * bh = head ;
do {
if ( offset < end_offset )
set_buffer_dirty ( bh ) ;
bh = bh - > b_this_page ;
offset + = 1 < < inode - > i_blkbits ;
} while ( bh ! = head ) ;
}
memcg: add per cgroup dirty page accounting
When modifying PG_Dirty on cached file pages, update the new
MEM_CGROUP_STAT_DIRTY counter. This is done in the same places where
global NR_FILE_DIRTY is managed. The new memcg stat is visible in the
per memcg memory.stat cgroupfs file. The most recent past attempt at
this was http://thread.gmane.org/gmane.linux.kernel.cgroups/8632
The new accounting supports future efforts to add per cgroup dirty
page throttling and writeback. It also helps an administrator break
down a container's memory usage and provides evidence to understand
memcg oom kills (the new dirty count is included in memcg oom kill
messages).
The ability to move page accounting between memcg
(memory.move_charge_at_immigrate) makes this accounting more
complicated than the global counter. The existing
mem_cgroup_{begin,end}_page_stat() lock is used to serialize move
accounting with stat updates.
Typical update operation:
memcg = mem_cgroup_begin_page_stat(page)
if (TestSetPageDirty()) {
[...]
mem_cgroup_update_page_stat(memcg)
}
mem_cgroup_end_page_stat(memcg)
Summary of mem_cgroup_end_page_stat() overhead:
- Without CONFIG_MEMCG it's a no-op
- With CONFIG_MEMCG and no inter memcg task movement, it's just
rcu_read_lock()
- With CONFIG_MEMCG and inter memcg task movement, it's
rcu_read_lock() + spin_lock_irqsave()
A memcg parameter is added to several routines because their callers
now grab mem_cgroup_begin_page_stat() which returns the memcg later
needed by for mem_cgroup_update_page_stat().
Because mem_cgroup_begin_page_stat() may disable interrupts, some
adjustments are needed:
- move __mark_inode_dirty() from __set_page_dirty() to its caller.
__mark_inode_dirty() locking does not want interrupts disabled.
- use spin_lock_irqsave(tree_lock) rather than spin_lock_irq() in
__delete_from_page_cache(), replace_page_cache_page(),
invalidate_complete_page2(), and __remove_mapping().
text data bss dec hex filename
8925147 1774832 1785856 12485835 be84cb vmlinux-!CONFIG_MEMCG-before
8925339 1774832 1785856 12486027 be858b vmlinux-!CONFIG_MEMCG-after
+192 text bytes
8965977 1784992 1785856 12536825 bf4bf9 vmlinux-CONFIG_MEMCG-before
8966750 1784992 1785856 12537598 bf4efe vmlinux-CONFIG_MEMCG-after
+773 text bytes
Performance tests run on v4.0-rc1-36-g4f671fe2f952. Lower is better for
all metrics, they're all wall clock or cycle counts. The read and write
fault benchmarks just measure fault time, they do not include I/O time.
* CONFIG_MEMCG not set:
baseline patched
kbuild 1m25.030000(+-0.088% 3 samples) 1m25.426667(+-0.120% 3 samples)
dd write 100 MiB 0.859211561 +-15.10% 0.874162885 +-15.03%
dd write 200 MiB 1.670653105 +-17.87% 1.669384764 +-11.99%
dd write 1000 MiB 8.434691190 +-14.15% 8.474733215 +-14.77%
read fault cycles 254.0(+-0.000% 10 samples) 253.0(+-0.000% 10 samples)
write fault cycles 2021.2(+-3.070% 10 samples) 1984.5(+-1.036% 10 samples)
* CONFIG_MEMCG=y root_memcg:
baseline patched
kbuild 1m25.716667(+-0.105% 3 samples) 1m25.686667(+-0.153% 3 samples)
dd write 100 MiB 0.855650830 +-14.90% 0.887557919 +-14.90%
dd write 200 MiB 1.688322953 +-12.72% 1.667682724 +-13.33%
dd write 1000 MiB 8.418601605 +-14.30% 8.673532299 +-15.00%
read fault cycles 266.0(+-0.000% 10 samples) 266.0(+-0.000% 10 samples)
write fault cycles 2051.7(+-1.349% 10 samples) 2049.6(+-1.686% 10 samples)
* CONFIG_MEMCG=y non-root_memcg:
baseline patched
kbuild 1m26.120000(+-0.273% 3 samples) 1m25.763333(+-0.127% 3 samples)
dd write 100 MiB 0.861723964 +-15.25% 0.818129350 +-14.82%
dd write 200 MiB 1.669887569 +-13.30% 1.698645885 +-13.27%
dd write 1000 MiB 8.383191730 +-14.65% 8.351742280 +-14.52%
read fault cycles 265.7(+-0.172% 10 samples) 267.0(+-0.000% 10 samples)
write fault cycles 2070.6(+-1.512% 10 samples) 2084.4(+-2.148% 10 samples)
As expected anon page faults are not affected by this patch.
tj: Updated to apply on top of the recent cancel_dirty_page() changes.
Signed-off-by: Sha Zhengju <handai.szj@gmail.com>
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-23 00:13:16 +03:00
/*
2016-03-16 00:57:04 +03:00
* Lock out page - > mem_cgroup migration to keep PageDirty
* synchronized with per - memcg dirty page counters .
memcg: add per cgroup dirty page accounting
When modifying PG_Dirty on cached file pages, update the new
MEM_CGROUP_STAT_DIRTY counter. This is done in the same places where
global NR_FILE_DIRTY is managed. The new memcg stat is visible in the
per memcg memory.stat cgroupfs file. The most recent past attempt at
this was http://thread.gmane.org/gmane.linux.kernel.cgroups/8632
The new accounting supports future efforts to add per cgroup dirty
page throttling and writeback. It also helps an administrator break
down a container's memory usage and provides evidence to understand
memcg oom kills (the new dirty count is included in memcg oom kill
messages).
The ability to move page accounting between memcg
(memory.move_charge_at_immigrate) makes this accounting more
complicated than the global counter. The existing
mem_cgroup_{begin,end}_page_stat() lock is used to serialize move
accounting with stat updates.
Typical update operation:
memcg = mem_cgroup_begin_page_stat(page)
if (TestSetPageDirty()) {
[...]
mem_cgroup_update_page_stat(memcg)
}
mem_cgroup_end_page_stat(memcg)
Summary of mem_cgroup_end_page_stat() overhead:
- Without CONFIG_MEMCG it's a no-op
- With CONFIG_MEMCG and no inter memcg task movement, it's just
rcu_read_lock()
- With CONFIG_MEMCG and inter memcg task movement, it's
rcu_read_lock() + spin_lock_irqsave()
A memcg parameter is added to several routines because their callers
now grab mem_cgroup_begin_page_stat() which returns the memcg later
needed by for mem_cgroup_update_page_stat().
Because mem_cgroup_begin_page_stat() may disable interrupts, some
adjustments are needed:
- move __mark_inode_dirty() from __set_page_dirty() to its caller.
__mark_inode_dirty() locking does not want interrupts disabled.
- use spin_lock_irqsave(tree_lock) rather than spin_lock_irq() in
__delete_from_page_cache(), replace_page_cache_page(),
invalidate_complete_page2(), and __remove_mapping().
text data bss dec hex filename
8925147 1774832 1785856 12485835 be84cb vmlinux-!CONFIG_MEMCG-before
8925339 1774832 1785856 12486027 be858b vmlinux-!CONFIG_MEMCG-after
+192 text bytes
8965977 1784992 1785856 12536825 bf4bf9 vmlinux-CONFIG_MEMCG-before
8966750 1784992 1785856 12537598 bf4efe vmlinux-CONFIG_MEMCG-after
+773 text bytes
Performance tests run on v4.0-rc1-36-g4f671fe2f952. Lower is better for
all metrics, they're all wall clock or cycle counts. The read and write
fault benchmarks just measure fault time, they do not include I/O time.
* CONFIG_MEMCG not set:
baseline patched
kbuild 1m25.030000(+-0.088% 3 samples) 1m25.426667(+-0.120% 3 samples)
dd write 100 MiB 0.859211561 +-15.10% 0.874162885 +-15.03%
dd write 200 MiB 1.670653105 +-17.87% 1.669384764 +-11.99%
dd write 1000 MiB 8.434691190 +-14.15% 8.474733215 +-14.77%
read fault cycles 254.0(+-0.000% 10 samples) 253.0(+-0.000% 10 samples)
write fault cycles 2021.2(+-3.070% 10 samples) 1984.5(+-1.036% 10 samples)
* CONFIG_MEMCG=y root_memcg:
baseline patched
kbuild 1m25.716667(+-0.105% 3 samples) 1m25.686667(+-0.153% 3 samples)
dd write 100 MiB 0.855650830 +-14.90% 0.887557919 +-14.90%
dd write 200 MiB 1.688322953 +-12.72% 1.667682724 +-13.33%
dd write 1000 MiB 8.418601605 +-14.30% 8.673532299 +-15.00%
read fault cycles 266.0(+-0.000% 10 samples) 266.0(+-0.000% 10 samples)
write fault cycles 2051.7(+-1.349% 10 samples) 2049.6(+-1.686% 10 samples)
* CONFIG_MEMCG=y non-root_memcg:
baseline patched
kbuild 1m26.120000(+-0.273% 3 samples) 1m25.763333(+-0.127% 3 samples)
dd write 100 MiB 0.861723964 +-15.25% 0.818129350 +-14.82%
dd write 200 MiB 1.669887569 +-13.30% 1.698645885 +-13.27%
dd write 1000 MiB 8.383191730 +-14.65% 8.351742280 +-14.52%
read fault cycles 265.7(+-0.172% 10 samples) 267.0(+-0.000% 10 samples)
write fault cycles 2070.6(+-1.512% 10 samples) 2084.4(+-2.148% 10 samples)
As expected anon page faults are not affected by this patch.
tj: Updated to apply on top of the recent cancel_dirty_page() changes.
Signed-off-by: Sha Zhengju <handai.szj@gmail.com>
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-23 00:13:16 +03:00
*/
2016-03-16 00:57:22 +03:00
lock_page_memcg ( page ) ;
xfs: don't dirty buffers beyond EOF
generic/263 is failing fsx at this point with a page spanning
EOF that cannot be invalidated. The operations are:
1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes)
1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes)
1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes)
where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO
write attempts to invalidate the cached page over this range, it
fails with -EBUSY and so any attempt to do page invalidation fails.
The real question is this: Why can't that page be invalidated after
it has been written to disk and cleaned?
Well, there's data on the first two buffers in the page (1k block
size, 4k page), but the third buffer on the page (i.e. beyond EOF)
is failing drop_buffers because it's bh->b_state == 0x3, which is
BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say
what?
OK, set_buffer_dirty() is called on all buffers from
__set_page_buffers_dirty(), regardless of whether the buffer is
beyond EOF or not, which means that when we get to ->writepage,
we have buffers marked dirty beyond EOF that we need to clean.
So, we need to implement our own .set_page_dirty method that
doesn't dirty buffers beyond EOF.
This is messy because the buffer code is not meant to be shared
and it has interesting locking issues on the buffer dirty bits.
So just copy and paste it and then modify it to suit what we need.
Note: the solutions the other filesystems and generic block code use
of marking the buffers clean in ->writepage does not work for XFS.
It still leaves dirty buffers beyond EOF and invalidations still
fail. Hence rather than play whack-a-mole, this patch simply
prevents those buffers from being dirtied in the first place.
cc: <stable@kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02 06:12:51 +04:00
newly_dirty = ! TestSetPageDirty ( page ) ;
spin_unlock ( & mapping - > private_lock ) ;
if ( newly_dirty ) {
/* sigh - __set_page_dirty() is static, so copy it here, too */
unsigned long flags ;
spin_lock_irqsave ( & mapping - > tree_lock , flags ) ;
if ( page - > mapping ) { /* Race with truncate? */
WARN_ON_ONCE ( ! PageUptodate ( page ) ) ;
2016-03-16 00:57:22 +03:00
account_page_dirtied ( page , mapping ) ;
xfs: don't dirty buffers beyond EOF
generic/263 is failing fsx at this point with a page spanning
EOF that cannot be invalidated. The operations are:
1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes)
1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes)
1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes)
where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO
write attempts to invalidate the cached page over this range, it
fails with -EBUSY and so any attempt to do page invalidation fails.
The real question is this: Why can't that page be invalidated after
it has been written to disk and cleaned?
Well, there's data on the first two buffers in the page (1k block
size, 4k page), but the third buffer on the page (i.e. beyond EOF)
is failing drop_buffers because it's bh->b_state == 0x3, which is
BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say
what?
OK, set_buffer_dirty() is called on all buffers from
__set_page_buffers_dirty(), regardless of whether the buffer is
beyond EOF or not, which means that when we get to ->writepage,
we have buffers marked dirty beyond EOF that we need to clean.
So, we need to implement our own .set_page_dirty method that
doesn't dirty buffers beyond EOF.
This is messy because the buffer code is not meant to be shared
and it has interesting locking issues on the buffer dirty bits.
So just copy and paste it and then modify it to suit what we need.
Note: the solutions the other filesystems and generic block code use
of marking the buffers clean in ->writepage does not work for XFS.
It still leaves dirty buffers beyond EOF and invalidations still
fail. Hence rather than play whack-a-mole, this patch simply
prevents those buffers from being dirtied in the first place.
cc: <stable@kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02 06:12:51 +04:00
radix_tree_tag_set ( & mapping - > page_tree ,
page_index ( page ) , PAGECACHE_TAG_DIRTY ) ;
}
spin_unlock_irqrestore ( & mapping - > tree_lock , flags ) ;
}
2016-03-16 00:57:22 +03:00
unlock_page_memcg ( page ) ;
memcg: add per cgroup dirty page accounting
When modifying PG_Dirty on cached file pages, update the new
MEM_CGROUP_STAT_DIRTY counter. This is done in the same places where
global NR_FILE_DIRTY is managed. The new memcg stat is visible in the
per memcg memory.stat cgroupfs file. The most recent past attempt at
this was http://thread.gmane.org/gmane.linux.kernel.cgroups/8632
The new accounting supports future efforts to add per cgroup dirty
page throttling and writeback. It also helps an administrator break
down a container's memory usage and provides evidence to understand
memcg oom kills (the new dirty count is included in memcg oom kill
messages).
The ability to move page accounting between memcg
(memory.move_charge_at_immigrate) makes this accounting more
complicated than the global counter. The existing
mem_cgroup_{begin,end}_page_stat() lock is used to serialize move
accounting with stat updates.
Typical update operation:
memcg = mem_cgroup_begin_page_stat(page)
if (TestSetPageDirty()) {
[...]
mem_cgroup_update_page_stat(memcg)
}
mem_cgroup_end_page_stat(memcg)
Summary of mem_cgroup_end_page_stat() overhead:
- Without CONFIG_MEMCG it's a no-op
- With CONFIG_MEMCG and no inter memcg task movement, it's just
rcu_read_lock()
- With CONFIG_MEMCG and inter memcg task movement, it's
rcu_read_lock() + spin_lock_irqsave()
A memcg parameter is added to several routines because their callers
now grab mem_cgroup_begin_page_stat() which returns the memcg later
needed by for mem_cgroup_update_page_stat().
Because mem_cgroup_begin_page_stat() may disable interrupts, some
adjustments are needed:
- move __mark_inode_dirty() from __set_page_dirty() to its caller.
__mark_inode_dirty() locking does not want interrupts disabled.
- use spin_lock_irqsave(tree_lock) rather than spin_lock_irq() in
__delete_from_page_cache(), replace_page_cache_page(),
invalidate_complete_page2(), and __remove_mapping().
text data bss dec hex filename
8925147 1774832 1785856 12485835 be84cb vmlinux-!CONFIG_MEMCG-before
8925339 1774832 1785856 12486027 be858b vmlinux-!CONFIG_MEMCG-after
+192 text bytes
8965977 1784992 1785856 12536825 bf4bf9 vmlinux-CONFIG_MEMCG-before
8966750 1784992 1785856 12537598 bf4efe vmlinux-CONFIG_MEMCG-after
+773 text bytes
Performance tests run on v4.0-rc1-36-g4f671fe2f952. Lower is better for
all metrics, they're all wall clock or cycle counts. The read and write
fault benchmarks just measure fault time, they do not include I/O time.
* CONFIG_MEMCG not set:
baseline patched
kbuild 1m25.030000(+-0.088% 3 samples) 1m25.426667(+-0.120% 3 samples)
dd write 100 MiB 0.859211561 +-15.10% 0.874162885 +-15.03%
dd write 200 MiB 1.670653105 +-17.87% 1.669384764 +-11.99%
dd write 1000 MiB 8.434691190 +-14.15% 8.474733215 +-14.77%
read fault cycles 254.0(+-0.000% 10 samples) 253.0(+-0.000% 10 samples)
write fault cycles 2021.2(+-3.070% 10 samples) 1984.5(+-1.036% 10 samples)
* CONFIG_MEMCG=y root_memcg:
baseline patched
kbuild 1m25.716667(+-0.105% 3 samples) 1m25.686667(+-0.153% 3 samples)
dd write 100 MiB 0.855650830 +-14.90% 0.887557919 +-14.90%
dd write 200 MiB 1.688322953 +-12.72% 1.667682724 +-13.33%
dd write 1000 MiB 8.418601605 +-14.30% 8.673532299 +-15.00%
read fault cycles 266.0(+-0.000% 10 samples) 266.0(+-0.000% 10 samples)
write fault cycles 2051.7(+-1.349% 10 samples) 2049.6(+-1.686% 10 samples)
* CONFIG_MEMCG=y non-root_memcg:
baseline patched
kbuild 1m26.120000(+-0.273% 3 samples) 1m25.763333(+-0.127% 3 samples)
dd write 100 MiB 0.861723964 +-15.25% 0.818129350 +-14.82%
dd write 200 MiB 1.669887569 +-13.30% 1.698645885 +-13.27%
dd write 1000 MiB 8.383191730 +-14.65% 8.351742280 +-14.52%
read fault cycles 265.7(+-0.172% 10 samples) 267.0(+-0.000% 10 samples)
write fault cycles 2070.6(+-1.512% 10 samples) 2084.4(+-2.148% 10 samples)
As expected anon page faults are not affected by this patch.
tj: Updated to apply on top of the recent cancel_dirty_page() changes.
Signed-off-by: Sha Zhengju <handai.szj@gmail.com>
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-23 00:13:16 +03:00
if ( newly_dirty )
__mark_inode_dirty ( mapping - > host , I_DIRTY_PAGES ) ;
xfs: don't dirty buffers beyond EOF
generic/263 is failing fsx at this point with a page spanning
EOF that cannot be invalidated. The operations are:
1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes)
1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes)
1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes)
where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO
write attempts to invalidate the cached page over this range, it
fails with -EBUSY and so any attempt to do page invalidation fails.
The real question is this: Why can't that page be invalidated after
it has been written to disk and cleaned?
Well, there's data on the first two buffers in the page (1k block
size, 4k page), but the third buffer on the page (i.e. beyond EOF)
is failing drop_buffers because it's bh->b_state == 0x3, which is
BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say
what?
OK, set_buffer_dirty() is called on all buffers from
__set_page_buffers_dirty(), regardless of whether the buffer is
beyond EOF or not, which means that when we get to ->writepage,
we have buffers marked dirty beyond EOF that we need to clean.
So, we need to implement our own .set_page_dirty method that
doesn't dirty buffers beyond EOF.
This is messy because the buffer code is not meant to be shared
and it has interesting locking issues on the buffer dirty bits.
So just copy and paste it and then modify it to suit what we need.
Note: the solutions the other filesystems and generic block code use
of marking the buffers clean in ->writepage does not work for XFS.
It still leaves dirty buffers beyond EOF and invalidations still
fail. Hence rather than play whack-a-mole, this patch simply
prevents those buffers from being dirtied in the first place.
cc: <stable@kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02 06:12:51 +04:00
return newly_dirty ;
}
2006-06-28 15:26:44 +04:00
const struct address_space_operations xfs_address_space_operations = {
2006-03-14 05:54:26 +03:00
. readpage = xfs_vm_readpage ,
. readpages = xfs_vm_readpages ,
. writepage = xfs_vm_writepage ,
2006-06-09 09:27:16 +04:00
. writepages = xfs_vm_writepages ,
xfs: don't dirty buffers beyond EOF
generic/263 is failing fsx at this point with a page spanning
EOF that cannot be invalidated. The operations are:
1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes)
1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes)
1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes)
where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO
write attempts to invalidate the cached page over this range, it
fails with -EBUSY and so any attempt to do page invalidation fails.
The real question is this: Why can't that page be invalidated after
it has been written to disk and cleaned?
Well, there's data on the first two buffers in the page (1k block
size, 4k page), but the third buffer on the page (i.e. beyond EOF)
is failing drop_buffers because it's bh->b_state == 0x3, which is
BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say
what?
OK, set_buffer_dirty() is called on all buffers from
__set_page_buffers_dirty(), regardless of whether the buffer is
beyond EOF or not, which means that when we get to ->writepage,
we have buffers marked dirty beyond EOF that we need to clean.
So, we need to implement our own .set_page_dirty method that
doesn't dirty buffers beyond EOF.
This is messy because the buffer code is not meant to be shared
and it has interesting locking issues on the buffer dirty bits.
So just copy and paste it and then modify it to suit what we need.
Note: the solutions the other filesystems and generic block code use
of marking the buffers clean in ->writepage does not work for XFS.
It still leaves dirty buffers beyond EOF and invalidations still
fail. Hence rather than play whack-a-mole, this patch simply
prevents those buffers from being dirtied in the first place.
cc: <stable@kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-09-02 06:12:51 +04:00
. set_page_dirty = xfs_vm_set_page_dirty ,
2006-03-17 09:26:25 +03:00
. releasepage = xfs_vm_releasepage ,
. invalidatepage = xfs_vm_invalidatepage ,
2007-10-16 12:25:06 +04:00
. write_begin = xfs_vm_write_begin ,
2010-06-14 13:17:31 +04:00
. write_end = xfs_vm_write_end ,
2006-03-14 05:54:26 +03:00
. bmap = xfs_vm_bmap ,
. direct_IO = xfs_vm_direct_IO ,
2006-02-01 14:05:41 +03:00
. migratepage = buffer_migrate_page ,
2009-03-29 11:53:38 +04:00
. is_partially_uptodate = block_is_partially_uptodate ,
2009-09-16 13:50:16 +04:00
. error_remove_page = generic_error_remove_page ,
2005-04-17 02:20:36 +04:00
} ;