01 Jul, 2013
1 commit
-
Subtracting the number of the first data block places the superblock
backups one block too early, corrupting the file system. When the block
size is larger than 1K, the first data block is 0, so the subtraction
has no effect and no corruption occurs.Signed-off-by: Maarten ter Huurne
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Jan Kara
CC: stable@vger.kernel.org
17 Jun, 2013
1 commit
-
This patch removed several unused variables.
Signed-off-by: Jon Ernst
Signed-off-by: "Theodore Ts'o"
06 Jun, 2013
1 commit
-
Check the group number for sanity earilier, before calling routines
such as ext4_bg_has_super() or ext4_group_overhead_blocks().Reported-by: Jonathan Salwan
Signed-off-by: "Theodore Ts'o"
22 Apr, 2013
2 commits
-
Addresses-Red-Hat-Bugzilla: #913245
Reported-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Carlos Maiolino
Cc: stable@vger.kernel.org -
Commit fb0a387dcdc restricts block allocations for indirect-mapped
files to block groups less than s_blockfile_groups. However, the
online resizing code wasn't setting s_blockfile_groups, so the newly
added block groups were not available for non-extent mapped files.Reported-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
04 Apr, 2013
1 commit
-
Currently on many places in ext4 we're using
ext4_get_group_no_and_offset() even though we're only interested in
knowing the block group of the particular block, not the offset within
the block group so we can use more efficient way to compute block
group.This patch introduces ext4_get_group_number() which computes block
group for a given block much more efficiently. Use this function
instead of ext4_get_group_no_and_offset() everywhere where we're only
interested in knowing the block group.Signed-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
12 Mar, 2013
1 commit
-
A user who was using a 8TB+ file system and with a very large flexbg
size (> 65536) could cause the atomic_t used in the struct flex_groups
to overflow. This was detected by PaX security patchset:http://forums.grsecurity.net/viewtopic.php?f=3&t=3289&p=12551#p12551
This bug was introduced in commit 9f24e4208f7e, so it's been around
since 2.6.30. :-(Fix this by using an atomic64_t for struct orlav_stats's
free_clusters.Signed-off-by: "Theodore Ts'o"
Reviewed-by: Lukas Czerner
Cc: stable@vger.kernel.org
03 Mar, 2013
1 commit
-
We're using macro EXT4_B2C() to convert number of blocks to number of
clusters for bigalloc file systems. However, we should be using
EXT4_NUM_B2C().Signed-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
09 Feb, 2013
1 commit
-
So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.The recommended way for finding the longer-running handles is:
T=/sys/kernel/debug/tracing
EVENT=$T/events/jbd2/jbd2_handle_stats
echo "interval > 5" > $EVENT/filter
echo 1 > $EVENT/enable./run-my-fs-benchmark
cat $T/trace > /tmp/problem-handles
This will list handles that were active for longer than 20ms. Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation. Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:postmark-2917 [000] .... 196.435786: jbd2_handle_stats: dev 254,32
tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
dirtied_blocks 0Signed-off-by: "Theodore Ts'o"
13 Jan, 2013
3 commits
-
After we have finished extending the file system, we need to trigger a
the lazy inode table thread to zero out the inode tables.Signed-off-by: "Theodore Ts'o"
-
Because the function 'sb_getblk' seldomly fails to return NULL
value,it will be better to use 'unlikely' to optimize it.Signed-off-by: Wang Shilong
Signed-off-by: "Theodore Ts'o" -
The only reason for sb_getblk() failing is if it can't allocate the
buffer_head. So ENOMEM is more appropriate than EIO. In addition,
make sure that the file system is marked as being inconsistent if
sb_getblk() fails.Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
09 Nov, 2012
1 commit
-
ext4_handle_release_buffer() was intended to remove journal
write access from a buffer, but it doesn't actually do anything
at all other than add a BUFFER_TRACE point, but it's not reliably
used for that either. Remove all the associated dead code.Signed-off-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Carlos Maiolino
22 Oct, 2012
1 commit
-
In mke2fs, we only checksum the whole bitmap block and it is right.
While in the kernel, we use EXT4_BLOCKS_PER_GROUP to indicate the
size of the checksumed bitmap which is wrong when we enable bigalloc.
The right size should be EXT4_CLUSTERS_PER_GROUP and this patch fixes
it.Also as every caller of ext4_block_bitmap_csum_set and
ext4_block_bitmap_csum_verify pass in EXT4_BLOCKS_PER_GROUP(sb)/8,
we'd better removes this parameter and sets it in the function itself.Signed-off-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Lukas Czerner
Cc: stable@vger.kernel.org
26 Sep, 2012
2 commits
-
When performing an online resize, we add a bunch of groups at one time
in ext4_flex_group_add, so in most cases a lot of group descriptors
will be in the same group block. But in the end of this function,
update_backups will be called for every group descriptor and the same
block will be copied and journalled again and again. It is really a
waste.Fix things so we only update a particular bg descriptor block once and
skip subsequent updates of the same block.Signed-off-by: Tao Ma
Signed-off-by: "Theodore Ts'o" -
bh_submit_read() is responsible for unlock bh on endio. In addition,
we need to use bh_uptodate_or_lock() to avoid races.Signed-off-by: Dmitry Monakhov
Signed-off-by: "Theodore Ts'o"
20 Sep, 2012
1 commit
-
The update_backups() function is used to backup all the metadata
blocks, so we should not take it for granted that 'data' is pointed to
a super block and use ext4_superblock_csum_set to calculate the
checksum there. In case where the data is a group descriptor block,
it will corrupt the last group descriptor, and then e2fsck will
complain about it it.As all the metadata checksums should already be OK when we do the
backup, remove the wrong ext4_superblock_csum_set and it should be
just fine.Reported-by: "Theodore Ts'o"
Signed-off-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
19 Sep, 2012
1 commit
-
Commit 1c6bd7173d66b3 introduced a regression where an online resize
operation which did not change the number of block groups would fail,
i.e:mke2fs -t /dev/vdc 60000
mount /dev/vdc
resize2fs /dev/vdc 60001This was due to a bug in the logic regarding when to try converting
the filesystem to use meta_bg.Also fix up a number of other minor issues with the online resizing
code: (a) Fix a sparse warning; (b) only check to make sure the device
is large enough once, instead of multiple times through the resize
loop.Signed-off-by: "Theodore Ts'o"
13 Sep, 2012
3 commits
-
For very long online resizes, a periodic update to the console log is
helpful for debugging and for progress reporting.Signed-off-by: "Theodore Ts'o"
-
If we have run out of reserved gdt blocks, then clear the resize_inode
feature and enable the meta_bg feature, so that we can continue
resizing the file system seamlessly.Signed-off-by: "Theodore Ts'o"
-
Set bg_itable_unused for file systems that have uninit_bg enabled.
This will speed up the first e2fsck run after the file system is
resized.Signed-off-by: "Theodore Ts'o"
05 Sep, 2012
7 commits
-
This patch adds support for resizing file systems with the meta_bg and
64bit features.[ Added a fix by tytso to fix a divide by zero when resizing a
filesystem from 14 TB to 18TB. Also fixed overhead accounting for
meta_bg file systems.]Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o" -
Previously we allocated the s_group_info array with enough space for
any future possible growth of the file system via online resize. This
is unfortunate because it wastes memory, and it doesn't work for the
meta_bg scheme, since there is no limit based on the number of
reserved gdt blocks. So add the code to grow the s_group_info array
as needed.Signed-off-by: "Theodore Ts'o"
-
Previously, we allocated the s_flex_groups array to the maximum size
that the file system could be resized. There was two problems with
this approach. First, it wasted memory in the common case where the
file system was not resized. Secondly, once we start allowing online
resizing using the meta_bg scheme, there is no maximum size that the
file system can be resized. So instead, we need to grow the
s_flex_groups at inline resize time.Signed-off-by: "Theodore Ts'o"
-
The resize code was needlessly writing the backup block group
descriptor blocks multiple times (once per block group) during an
online resize.Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org -
The resize code was copying blocks at the beginning of each block
group in order to copy the superblock and block group descriptor table
(gdt) blocks. This was, unfortunately, being done even for block
groups that did not have super blocks or gdt blocks. This is a
complete waste of perfectly good I/O bandwidth, to skip writing those
blocks for sparse bg's.Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org -
Avoid changing o_blocks_count, since it is used later when reporting
old blocks count in debug mode.Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o" -
If the last group does not have enough space for group tables, ignore
it instead of calling BUG_ON().Reported-by: Daniel Drake
Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
23 Jul, 2012
2 commits
-
The '__ext4_handle_dirty_metadata()' does not need the 'now' argument
anymore and we can kill it.Signed-off-by: Artem Bityutskiy
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Jan Kara -
Signed-off-by: "Theodore Ts'o"
10 Jul, 2012
1 commit
-
Commit f975d6bcc7a introduced bug which caused ext4_statfs() to
miscalculate the number of file system overhead blocks. This causes
the f_blocks field in the statfs structure to be larger than it should
be. This would in turn cause the "df" output to show the number of
data blocks in the file system and the number of data blocks used to
be larger than they should be.Signed-off-by: "Theodore Ts'o"
Cc: stable@kernel.org
29 May, 2012
2 commits
-
The b_data field of the buffer_head is already a char *, so there's no
point casting it to a char *.Signed-off-by: "Theodore Ts'o"
-
In alloc_flex_gd(), when flexbg_size is large, kmalloc size would
overflow and flex_gd->groups would point to a buffer smaller than
expected, causing OOB accesses when it is used.Note that in ext4_resize_fs(), flexbg_size is calculated using
sbi->s_log_groups_per_flex, which is read from the disk and only bounded
to [1, 31]. The patch returns NULL for too large flexbg_size.Reviewed-by: Eric Sandeen
Signed-off-by: Haogang Chen
Signed-off-by: "Theodore Ts'o"
Cc: stable@kernel.org
30 Apr, 2012
4 commits
-
metadata_csum supersedes uninit_bg. Convert the ROCOMPAT uninit_bg
flag check to a helper function that covers both, and make the
checksum calculation algorithm use either crc16 or the metadata_csum
chosen algorithm depending on which flag is set. Print a warning if
we try to mount a filesystem with both feature flags set.Signed-off-by: Darrick J. Wong
Signed-off-by: "Theodore Ts'o" -
Compute and verify the checksum of the block bitmap; this checksum is
stored in the block group descriptor.Signed-off-by: Darrick J. Wong
Signed-off-by: "Theodore Ts'o" -
Compute and verify the checksum of the inode bitmap; the checkum is
stored in the block group descriptor.Signed-off-by: Darrick J. Wong
Signed-off-by: "Theodore Ts'o" -
Calculate and verify the superblock checksum. Since the UUID and
block group number are embedded in each copy of the superblock, we
need only checksum the entire block. Refactor some of the code to
eliminate open-coding of the checksum update call.Signed-off-by: Darrick J. Wong
Signed-off-by: "Theodore Ts'o"
21 Mar, 2012
1 commit
-
When we're doing an online resize of an ext4 filesystem, we need to
update the free inode and block counts in the superblock so that fsck
doesn't complain.Signed-off-by: Darrick J. Wong
Signed-off-by: "Theodore Ts'o"
20 Mar, 2012
1 commit
-
Signed-off-by: "Theodore Ts'o"
21 Feb, 2012
1 commit
-
When resizing file system in the way that the new size of the file
system is still in the same group (no new groups are added), then we can
hit a BUG_ON in ext4_alloc_group_tables()BUG_ON(flex_gd->count == 0 || group_data == NULL);
because flex_gd->count is zero. The reason is the missing check for such
case, so the code always extend the last group fully and then attempt to
add more groups, but at that time n_blocks_count is actually smaller
than o_blocks_count.It can be easily reproduced like this:
mkfs.ext4 -b 4096 /dev/sda 30M
mount /dev/sda /mnt/test
resize2fs /dev/sda 50MFix this by checking whether the resize happens within the singe group
and only add that many blocks into the last group to satisfy user
request. Then o_blocks_count == n_blocks_count and the resize will exit
successfully without and attempt to add more groups into the fs.Also fix mixing together block number and blocks count which might be
confusing and can easily lead to off-by-one errors (but it is actually
not the case here since the two occurrence of this mix-up will cancel
each other).Signed-off-by: Lukas Czerner
Reported-by: Milan Broz
Reviewed-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"