When a new block bitmap is read from disk in read_block_bitmap()
there are a few bits that should ALWAYS be set. In particular,
the blocks given corresponding to block bitmap, inode bitmap and inode tables.
Validate the block bitmap against these blocks.
Signed-off-by: Aneesh Kumar K.V [EMAIL
When a new block bitmap is read from disk in read_block_bitmap()
there are a few bits that should ALWAYS be set. In particular,
the blocks given corresponding to block bitmap, inode bitmap and inode tables.
Validate the block bitmap against these blocks.
Signed-off-by: Aneesh Kumar K.V [EMAIL
Please ignore previous patch, it has an issue with operator precedence
in ext3_get_grp_metacluster(), try this instead:
Signed-off-by: Abhishek Rai [EMAIL PROTECTED]
diff -uprdN linux-2.6.23mm1-clean/fs/ext3/balloc.c
linux-2.6.23mm1-ext3mc/fs/ext3/balloc.c
---
On Nov 10, 2007 05:10 -0700, Andreas Dilger wrote:
Attached is a test image for extended attribute block checking.
This small image contains a number of different kinds of corruptions
(bad magic, bad checksum, empty block, bad EA block number), as well
as an old-format (v1) EA, and a valid v2
Andreas,
Thanks for the great review. I've hopefully addressed all your concerns.
Please find my responses inline followed by an updated patch.
On Nov 9, 2007 11:52 PM, Andreas Dilger [EMAIL PROTECTED] wrote:
On Nov 09, 2007 17:33 -0800, Abhishek Rai wrote:
Benchmark 5: fsck
Description:
The patch titled
Forbid user to change file flags on quota files
has been removed from the -mm tree. Its filename was
forbid-user-to-change-file-flags-on-quota-files.patch
This patch was dropped because it was merged into mainline or a subsystem tree
I ran into a potential overflow in ext4_mb_scan_aligned,
and went looking for others in mballoc. This patch hits a
few spots, compile-tested only at this point, comments welcome.
This patch:
changes fe_len to an int, I don't think we need it to be a long,
looking at how it's used (should it
On Fri, 16 Nov 2007 11:47:27 +0900 Hisashi Hifumi [EMAIL PROTECTED] wrote:
Currently fdatasync is identical to fsync in ext3,4.
I think fdatasync should skip journal flush in data=ordered and
data=writeback mode
because this syscall is not required to synchronize the metadata.
I suppose so.
Hi.
Currently fdatasync is identical to fsync in ext3,4.
I think fdatasync should skip journal flush in data=ordered and data=writeback
mode
because this syscall is not required to synchronize the metadata.
My patch as below is similar to the approach of GFS2's fsync code(gfs2_fsync).
Thanks.
On Fri, 16 November 2007 11:47:27 +0900, Hisashi Hifumi wrote:
diff -Nrup linux-2.6.24-rc2.org/fs/ext3/fsync.c
linux-2.6.24-rc2/fs/ext3/fsync.c
--- linux-2.6.24-rc2.org/fs/ext3/fsync.c 2007-11-07 06:57:46.0
+0900
+++ linux-2.6.24-rc2/fs/ext3/fsync.c 2007-11-15
On Thu, 15 Nov 2007 22:47:40 -0500 Wendy Cheng [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Fri, 16 Nov 2007 11:47:27 +0900 Hisashi Hifumi [EMAIL PROTECTED] wrote:
Currently fdatasync is identical to fsync in ext3,4.
I think fdatasync should skip journal flush in data=ordered
On Thu, 15 November 2007 18:59:19 -0800, Andrew Morton wrote:
On Fri, 16 Nov 2007 11:47:27 +0900 Hisashi Hifumi [EMAIL PROTECTED] wrote:
Currently fdatasync is identical to fsync in ext3,4.
I think fdatasync should skip journal flush in data=ordered and
data=writeback mode
because this
Eric Sandeen wrote:
I ran into a potential overflow in ext4_mb_scan_aligned,
and went looking for others in mballoc. This patch hits a
few spots, compile-tested only at this point, comments welcome.
This patch:
... introduces a 64-bit divide. Oops... will fix that up resend.
-Eric
-
13 matches
Mail list logo
