similar to: Corruption when no space left on device.

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

Fix "h_buffer_credits<0" assert failure during truncate. The bug occurs when the "i_blocks" count in the file's inode overflows past 2^31. That works fine most of the time, because i_blocks is an unsigned long, and should go up to 2^32; but there's a place in truncate where ext3 calculates the size of the next transaction chunk for the delete, and that mistakenly

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

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]

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

Hi-- We've been observing some consistent filesystem corruption under ext3. The problem is that a directory created by one of our applications vanishes for some reason. The directory is created on installation the application. The files it contains are written infrequently (days to months) and read as part of every user command. The directory is under /etc and always has the same path.

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

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?

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.

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

A couple of years ago there was a discussion on lkml under the thread 'PATCH - ext2fs privacy (i.e. secure deletion) patch' about zapping deleted data in the filesystem as a security mechanism. The discussion wandered off into how 'chattr +s' could be implemented and whether encrypting filesystems wouldn't be a better solution to the problem. I've been maintaining a

(sort-of xposted from linux-kernel) Hi, I am wondering how to interpret this error message, which popped up on a 2.4.26 SMP x86 box two days ago: EXT2-fs: corrupt root inode, run e2fsck init_special_inode: bogus imode (37316) EXT2-fs: corrupt root inode, run e2fsck init_special_inode: bogus imode (37316) EXT2-fs: corrupt root inode, run e2fsck The problem is, the error message doesn't

I have been using ext3 filesystem from 2.4.17 kernel in the default "ordered" mode on an 64 MB SanDisk compactflash. The disk itself was used on NationalGeode embedded board. The following entry was used in fstab (I know, may be stupid, but should not crash the filesystem?) /dev/hda1 / ext2 defaults,sync 1 1 After the board is switched off, it does not boot

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I got an IDE-drive which decided to get broken. Part of the extended partition table was lost, but I was able to recover it, so I could reach the ext3 filesystem with a size of about 135 GB. I made a copy of it (luckily the ISP doesn't seem to need the broken drive urgently hehe) and ran fsck on that copy. The first time I ran fsck I

Hi, I'm working with Prof. Zadok on versionfs, a stackable versioning file system. I face some problems with the unlink operation on ext3 with htree. On an unlink, I make a copy of the file (version/backup) and unlink the original file. But some files that have been unlinked are "linked back" to another file. For example, on deleting the file 'foo', the file itself is

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

Hello all, I recently ran over following issue ( the description is out of necessity bit lengthy): I have corrupted partition with ext3 filesystem oni t, fortunately enough partition was mirrored, so that I was able to dd the the mirroed partiton to the file like this: dd bs=512 if=/dev/<where_the_mirrored_partition_is> of=some_file and write the content to the primary partition like this:

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.