| bugzilla-daemon |
| Apr 15, 3:17 pm 2010 |
| bugzilla-daemon |
| Apr 15, 3:31 pm 2010 |
| bugzilla-daemon | [Bug 15792] ext4_inode_inode->i_flags modification is racy
https://bugzilla.kernel.org/show_bug.cgi?id=15792
--- Comment #4 from Dmitry Monakhov <dmonakhov@openvz.org> 2010-04-15 22:52:22 ---
Most interesting part is last lines
[61] [2] truncate clr s:737987 d:737987 b:104 fl:80000
[62] [0] clr ext4_inode_blocks_set b:104 fl:480000 bit:40000
[63] [2] trunc_ext begin s:737987 d:737987 b:104 fl:480000 ml:1
I.E.
CPU2: is doing EXT4_I(inode)->i_flags &= ~EXT4_EOFBLOCKS_FL
CPU0: is doung ei->i_flags &= ~EXT4_HUGE_FILE_FL
CPU2: Wow ...
| Apr 15, 3:52 pm 2010 |
| bugzilla-daemon |
| Apr 15, 3:54 pm 2010 |
| bugzilla-daemon |
| Apr 15, 3:13 pm 2010 |
| bugzilla-daemon |
| Apr 15, 3:40 pm 2010 |
| bugzilla-daemon |
| Apr 15, 3:39 pm 2010 |
| Jeff Moyer | Re: [PATCH 0/4 v3] ext3/4: enhance fsync performance whe ...
Did you use the fs_mark command line I (think I) had posted? What
storage were you using?
I took Vivek's iostest and modified the mixed workload to do buffered
random reader, buffered sequential reader, and buffered writer for all
of 1, 2, 4, 8 and 16 threads each.
The initial problem was reported against iozone, which can show the
problem quite easily when run like so:
iozone -s 64 -e -f /mnt/test/iozone.0 -i 0 -+n
You can also just run iozone in auto mode, but that can take quite ...
| Apr 15, 6:05 am 2010 |
| bugzilla-daemon |
| Apr 15, 1:45 am 2010 |
| tytso | Re: [PATCH 2/2] ext4: fix inode bitmaps manipulation in ...
This is what I dropped into the ext4 patch queue. It fixes up some
spelling errors, and a few other minor changes.
- Ted
ext4: clean up inode bitmaps manipulation in ext4_free_inode
From: Dmitry Monakhov <dmonakhov@openvz.org>
- Reorganize locking scheme to batch two atomic operation in to one.
This also allow us to state what healthy group must obey following rule
ext4_free_inodes_count(sb, gdp) == ext4_count_free(inode_bitmap, NUM);
- Fix possible undefined pointer ...
| Apr 14, 5:12 pm 2010 |
| Jan Kara | Re: ext34_free_inode's mess
I've looked at it: So the problem is the other way around (I always
confuse this). The inode is properly deleted but the bit remains set
in the bitmap. What is strange is that group descriptor counts are
correct so it's really only the bitmap bit that is wrong. I've looked
through the inode allocation and freeing code back and forth but I could
not find a place where this could realistically happen.
So just for record:
Inode has mtime = ctime = atime = dtime (so it was really deleted), ...
| Apr 15, 2:39 pm 2010 |
| Dmitry Monakhov | Re: ext34_free_inode's mess
I will, but for now i'm working on fix for OOPS
from fs/ext4/extents.c:3479 due to ex == NULL
Ok, if we know that any error result in EIO or panic when let's just
call it style cleanup(simplification), imho new code is more readable.
--
| Apr 15, 3:01 pm 2010 |
| Andi Kleen |
| Apr 15, 8:14 am 2010 |
| Dmitry Monakhov | Re: [PATCH] ext4: Do not zeroout uninitialized extents b ...
Yepp. Indeed function are almost identical, and sadly i've missed
Other useful test is to run fsstress with boosted write/fallocate
probability on small(1Gb) filesystem
xfstests/ltp/fsstress -p10 -z -f mkdir=1 -f creat=1 -f write=10 \
-f resrvsp=10 -n999999999 &
sleep 100
killall -9 fsstress
We have to update may_zeroout since orig extent was changed.
+ may_zeroout = ee_block + ee_len <= eof_block;
I've attached incremental patch for you.
In fact, this ...
| Apr 15, 2:20 am 2010 |
| Akira Fujita | Re: EXT4_IOC_MOVE_EXT file corruption!
Hi Darrick,
I couldn't reproduce this problem, somehow.
My environment is:
Arch: i386
Kernel: 2.6.34-rc3
e2fsprogs: 1.41.11
Mount option: delalloc, data=ordered, async
Block size: 4KB
Partition size: 100GB
Is there any difference in your case?
And how long does this file corruption take to be detected?
I ran below program all day long, but problem did not occur.
---
#!/bin/bash
TARGET="/mnt/mp1/TEST/linux-2.6.34-rc3"
ORIG="/mnt/mp1/TEST/linux-2.6.34-rc3-orig"
cp -pRdu ...
| Apr 15, 1:27 am 2010 |
| Darrick J. Wong | Re: EXT4_IOC_MOVE_EXT file corruption!
Hmm. I was running with 2.6.34-rc3 on x86-64, same block size, though with a
2TB mdraid0. It usually took a few hours to reproduce, though I've noticed
that if I kick off at least as many e4defrags and e4frags, it will show up much
Hmm... I don't ever see the OOM killer.
I've now seen this show up, just once:
[267630.741537] ------------[ cut here ]------------
[267630.746247] kernel BUG at /home/djwong/linux-2.6.34-rc3-fs/fs/ext4/extents.c:1922!
[267630.753903] invalid opcode: 0000 [#3] ...
| Apr 15, 12:17 pm 2010 |
| Greg Freemyer | Re: EXT4_IOC_MOVE_EXT file corruption!
If its not reproducible on a simple disk, it could be a bug in the
barrier code for mdraid.
But I think raid0 support for barriers has been around for a long time.
Greg
--
| Apr 15, 12:25 pm 2010 |
