similar to: [PATCH] Fix signed use of i_blocks in ext3 truncate

Hello I found that after defrag a file, the corresponding inode's i_blocks become incorrect. I hope following description address the real reason. i_blocks is decreased in 'btrfs_drop_extents' when something are drop/truncated and 'run_delalloc_range' calls 'btrfs_drop_extents' at first place, so 'run_delalloc_range' may decrease the i_blocks.

I have many systems running current ext3 code. Some of them have hardware problems that lead to frequent reboots, and the journal recovery has worked excellently. However, on the periodic forced fsck on supposedly recovered and clean filesystems, I've many times seen fsck report that i_blocks is too large in one or more inodes. I suspect that i_blocks is somehow escaping proper restoration

Hi all, I'm running ext3 with Linux 2.4.19pre5aa2 (and thus ext3 0.9.17) and e2fsprogs 1.27 on an x86 laptop with an IDE disk (with DMA enabled). The partition in question was mounted with the data=journal and nosuid options set. All the partitions are set to be fscked on bootup every 30 days (although I don't think this is strictely necessary, better safe than sorry). ext3 has been

This fixes the "i_blocks went wrong when the disk filled up" problem. In ext3_new_block() we increment i_blocks early, so the quota operation can be performed outside lock_super(). But if the block allocation ends up failing, we forget to undo the allocation. This is not a serious bug, and probably does not warrant an upgrade for production machines. Its effects are: 1) errors are

I tried it on loop. 1. mount /dev/loop0 /mnt/test -t ext3 2. cp files to 100% full 3. umount /mnt/test 4. fsck.ext3 -f /dev/loop0 Inode xxxxx, i_blocks is xxx, should be yyy. Fix?

Hi, (I'm not subscribed to ext3-users, please CC: me) Kernel: 2.4.18. I've just converted a 100(ish) MiB ext2 filesystem to ext3 (umount, tune2fs -j, e2fsck, mount) and it seems to be happy, except... As a test, I then filled the filesystem up, lastly copying /usr/bin (as root, so the filesystem became brim full). I then umounted it, and ran e2fsck -n -f /dev/hda6, and got the

Has anyone tried LFS (ie >2G files support) and Ext3 together? Are there good reasons why this should/should not work? I see the RH enterprise kernel patch set specifically does not attempt both lfs and ext3, but the lfs patches themselves touch some reasonably localised parts of ext2, so I would hope (without having dived in there to test), that the ext3 changes would mirror that

I appear to have a broken filesystem on this box to the point where I am probably going to rebuild the system since I have lost trust in it.... I was wondering if there was any reasonable postmortum work I could do on it before it gets rebuilt. History is that the laptop has a much mauled partition set on it - initially it came with 100% win2k, I then shrunk that and added linux (a RH71 install

Al writes: > On Thu, 22 Mar 2001, Andreas Dilger wrote: > > If this is the case, then all of the other zero initializations can be > > removed as well. I figured that if most of the fields were being > > zeroed, then ones _not_ being zeroed would lead to this problem. > > Other zero initializations in inode->u certainly can be > removed, but whether it's

/an ocfs2 bug: a truncate races with ocfs2_get_block(...,0). 1) 'dd' is doing a truncate, clearing the page cache and reset inode size./ /2) between clearing page cache and resizing inode, a read comes and create a / /new page and insert it to page cache./ /3) the read(from `cat`) set buffer head in the new page as mapped but doesn't increase / /ip_mmu_private in ocfs2_get_block()

I'm constructing a raid 5 of 3 160gb sata drives. They're connected to a promise sx4 150 card, using the kernel drives (not promise's binary only drivers). the raid builds fine, as does creation of the ext3 filesystem. however, if i then run e2fsck (with the -f option since the filesystem is brand new) i get thousands of these type of errors: Inode 15461 has imagic flag set.

use i_size_read() instead of accessing inode->i_size directly. Signed-off-by: Wengang Wang <wen.gang.wang at oracle.com> -- diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index b2c52b3..4491851 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -1920,7 +1920,7 @@ int ocfs2_write_end_nolock(struct address_space *mapping, out_write_size: pos += copied; - if (pos >

Hi all, Apologies but this is going to be a long post. I get a corruption sometime when I do a $sudo shutdown -r now This is on an ubuntu 8.10 machine. The only way to resolve the same I know is to do a sudo fsck -y /dev/sdb7 This is the output I got when I ran fsck through the Live CD $ sudo fsck -y /dev/sdb7 fsck 1.41.3 (12-Oct-2008) e2fsck 1.41.3 (12-Oct-2008) /dev/sdb7 contains a file

Hi, Apologies, this is going to be quite long - I'm going to provide as much info as possible. I'm running a system with ext3 fs on software RAID. The RAID set-up is as shown below: jlm@nijinsky:~$ cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md0 : active raid1 hdc1[1] hda1[0] 96256 blocks [2/2] [UU] md5 : active raid1 hdk1[1] hde1[0]

I have a 1.5 TB (1,475,720,773,632) partition that I wanted to convert from ext4 to btrfs. It is currently used as / for ubuntu 10.10. I booted into 11.04 beta2 and tried a ''btrfs-convert /dev/sdc1'', but after about 20 minutes it segfaulted. I performed a: sck.ext4 -cDfty -C 0 /dev/sdc1 After everything was clean, I downloaded the debugging symbols for btrfs-convert and

Hi all! Several times now I have seen the following: fsck-ing the ext3 fs I get hundreds (if not thousands) of messages: Indoe NNNN, i_blocks is K, should be (K-8). FIXED: Interestingly the difference is *always* *always* *always* 8. Can someone explain me what was going on? Why this? Thanks a lot and all the best Norbert

Hi all I am having some trouble using the ext2online utility, I have reduced the problem down to its simplist form, and it goes soemthing like this: Start with a regular msdos labelled disk (I have tried lvm volumes): Command (m for help): p Disk /dev/sdb: 18.3 GB, 18351967232 bytes 64 heads, 32 sectors/track, 17501 cylinders Units = cylinders of 2048 * 512 = 1048576 bytes Device Boot

Hi, ext3-0.9.18 is now available for 2.4.19-pre8. Some of the fixes in this release are already in the 2.4.19-pre8, but there are some important new fixes in the patch and users are encouraged to upgrade. This release fixes all known outstanding bug reports. The full patch against linux-2.4.19-pre8, and a tarball of the individual fixes in this patch set, is now propagating to

If I try to write to a file when the partition is full, the inode seems to get a little corrupted. For the inode I tried to write to, i_blocks gets a wrong value. I'm not sure if this is ext3 specific, it probably is the same with ext2 or maybe even some other fs, I only tested it with ext3. One weird thing I noticed when I last tried it was that for some time df said there was no free

Hi, why is there a window between statements "err = ext3_journal_get_write_access(handle, this_bh);" and "ext3_journal_dirty_metadata(handle, this_bh);" ? In my test, there is an error in journal_dirty_metadata: jh is null thanks! D.Yang April 1, 2004