diff options
author | Joel Becker <joel.becker@oracle.com> | 2010-07-01 15:13:31 -0700 |
---|---|---|
committer | Joel Becker <joel.becker@oracle.com> | 2010-07-08 13:25:35 -0700 |
commit | 5693486bad2bc2ac585a2c24f7e2f3964b478df9 (patch) | |
tree | 03d61d72c1b73bbf0b049bf0328f8e0c69f35a43 /fs/eventpoll.c | |
parent | a4bfb4cf11fd2211b788af59dc8a8b4394bca227 (diff) |
ocfs2: Zero the tail cluster when extending past i_size.
ocfs2's allocation unit is the cluster. This can be larger than a block
or even a memory page. This means that a file may have many blocks in
its last extent that are beyond the block containing i_size. There also
may be more unwritten extents after that.
When ocfs2 grows a file, it zeros the entire cluster in order to ensure
future i_size growth will see cleared blocks. Unfortunately,
block_write_full_page() drops the pages past i_size. This means that
ocfs2 is actually leaking garbage data into the tail end of that last
cluster. This is a bug.
We adjust ocfs2_write_begin_nolock() and ocfs2_extend_file() to detect
when a write or truncate is past i_size. They will use
ocfs2_zero_extend() to ensure the data is properly zeroed.
Older versions of ocfs2_zero_extend() simply zeroed every block between
i_size and the zeroing position. This presumes three things:
1) There is allocation for all of these blocks.
2) The extents are not unwritten.
3) The extents are not refcounted.
(1) and (2) hold true for non-sparse filesystems, which used to be the
only users of ocfs2_zero_extend(). (3) is another bug.
Since we're now using ocfs2_zero_extend() for sparse filesystems as
well, we teach ocfs2_zero_extend() to check every extent between
i_size and the zeroing position. If the extent is unwritten, it is
ignored. If it is refcounted, it is CoWed. Then it is zeroed.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Cc: stable@kernel.org
Diffstat (limited to 'fs/eventpoll.c')
0 files changed, 0 insertions, 0 deletions