| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This allows us to refactor the procfs code, which saves a bit of
compiled space. More importantly it isolates most of the procfs
support code into a single file, so it's easier to #ifdef it out if
the proc file system has been disabled.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Joe Maples <joe@frap129.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently it is possible to lose whole file system block worth of data
when we hit the specific interaction with unwritten and delayed extents
in status extent tree.
The problem is that when we insert delayed extent into extent status
tree the only way to get rid of it is when we write out delayed buffer.
However there is a limitation in the extent status tree implementation
so that when inserting unwritten extent should there be even a single
delayed block the whole unwritten extent would be marked as delayed.
At this point, there is no way to get rid of the delayed extents,
because there are no delayed buffers to write out. So when a we write
into said unwritten extent we will convert it to written, but it still
remains delayed.
When we try to write into that block later ext4_da_map_blocks() will set
the buffer new and delayed and map it to invalid block which causes
the rest of the block to be zeroed loosing already written data.
For now we can fix this by simply not allowing to set delayed status on
written extent in the extent status tree. Also add WARN_ON() to make
sure that we notice if this happens in the future.
This problem can be easily reproduced by running the following xfs_io.
xfs_io -f -c "pwrite -S 0xaa 4096 2048" \
-c "falloc 0 131072" \
-c "pwrite -S 0xbb 65536 2048" \
-c "fsync" /mnt/test/fff
echo 3 > /proc/sys/vm/drop_caches
xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff
This can be theoretically also reproduced by at random by running fsx,
but it's not very reliable, though on machines with bigger page size
(like ppc) this can be seen more often (especially xfstest generic/127)
Change-Id: I0ba800f68cf35a0137a5c5b0903017e08bc6f814
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@google.com>
Cc: stable@vger.kernel.org
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Between 3.10 and 3.18, the abstraction to scan for objects in the slab
cache which can be freed when the system is under memory pressure
changed. When I backported the ext4 code from 3.18 to the 3.10
kernel, I didn't get the return value required by the calling
conventions for the scan function correct, which could potentially
cause the memory reclaimer to loop indefinitely.
Change-Id: I1712fedf96fd91c911fb4d019d7ef76f6c4c1808
Signed-off-by: "Theodore Ts'o" <tytso@google.com>
|
| |
|
|
|
|
| |
Older kernels don't pass in a gfp_flags argument.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
| |
|
|
| |
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
|
| | |
|
| | |
|
| |
|
