similar to: corrupt orphan inode list

Hello, last fsck says my /tmp and my /home files system has errors, here is the log from fsck using the read-only option: How to recover from this savely? How to avoid this in future? i am using kernel 2.4.18 with the acl-patches from acl.bestbits.at and the patches for the fileutils and e2fsprogs. If you need more informations please mail.

Hello, last fsck says my /tmp and my /home files system has errors, here is the log from fsck using the read-only option: How to recover from this savely? How to avoid this in future? i am using kernel 2.4.18 with the acl-patches from acl.bestbits.at and the patches for the fileutils and e2fsprogs. If you need more informations please mail.

Stephen, OK, I can now reproduce this hang at will, purely by pulling the plug on my desktop when logged in and then rebooting - its a gnome desktop box with few partitions and ext3 on all of them, so I guess its getting a pile of gnome or ssh related sockets kept in /tmp which is on root To recap, when the machine is suffering from this, it hangs at the point of mounting the root filesystem

On Fri, Apr 18, 2014 at 06:56:57PM +0200, Patrik Horn?k wrote: > > yesterday I experienced following problem with my ext3 filesystem: > > - I had ext3 filesystem of the size of a few TB with journal. I correctly > unmounted it and it was marked clean. > > - I then ran fsck.etx3 -f on it and it did not find any problem. > > - After increasing size of its LVM volume by

Hi, it seems you got it right! I don't know if you read email I sent you before posting to the mailing list, but I accidentally diagnosed the cause... :) I've noticed that inodes fsck warned me about, at least ones that I checked, all have all four timestamps latest in 2010... The filesystem has maximum 1281998848 inodes, which is timestamp in august 2010. I don't know how it got

Hello, yesterday I experienced following problem with my ext3 filesystem: - I had ext3 filesystem of the size of a few TB with journal. I correctly unmounted it and it was marked clean. - I then ran fsck.etx3 -f on it and it did not find any problem. - After increasing size of its LVM volume by 1.5 TB I resized the filesystem by resize2fs lvm_volume and it finished without problem. - But

Greetings! Need your help fellow penguins! Strange behavior with fsck.ext3: how to remove a long orphaned inode list? After copying data over from one old RAID to another new RAID with rsync, the dump command would not complete because of filesystem errors on the new RAID. So I ran fsck.ext3 with the -y option and it would just run in an infinite loop restarting itself and then trying to correct

On 2013-08-29, at 7:48 PM, Richards, Paul Franklin wrote: > Strange behavior with fsck.ext3: how to remove a long orphaned inode list? > > After copying data over from one old RAID to another new RAID with rsync, the dump command would not complete because of filesystem errors on the new RAID. So I ran fsck.ext3 with the -y option and it would just run in an infinite loop restarting

Hallo List, after rebooting one of our systems one of the ext3 filesystems, that was cleanly unmounted, fsck stopped the boot process due to critical errors in that filesystem. Running fsck -y manually returned, that one of the i-nodes is "too big" an was truncated. After this about three million i-nodes were orphaned an moved to lost+found. # strings /sbin/e2fsck | grep -i

Any recommendations for tools to diagnose and recover problems on an ext4 file system? In particular: root@jessie01:~# mount -o ro /dev/markov02/root /mnt/markov02 mount: wrong fs type, bad option, bad superblock on /dev/mapper/markov02-root, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. and e2fsck

Hello, yesterday I experienced following problem with my ext3 filesystem: - I had ext3 filesystem of the size of a few TB with journal. I correctly unmounted it and it was marked clean. - I then ran fsck.etx3 -f on it and it did not find any problem. - After increasing size of its LVM volume by 1.5 TB I resized the filesystem by resize2fs lvm_volume and it finished without problem. - But

Hi btrfs-team/-users, I do observe a strange behavior upon booting of my openSUSE 12.1 system ( kernel 3.1.10-1.9-desktop; x86_64 ) with btrfsprogs-0.19-43.7.1.x86_64 utils installed: The system has two btrfs-vols: root(sda7) & home(sda8) and had been created during system setup of openSUSE 12.1: # btrfs filesystem show Label: none uuid: a288fcff-28c8-4764-8efe-1e0cb205d588

Hi, after my X froze i had a fs inconsistency after the journal replay [...] EXT3-fs: 03:06: 1 orphan inode deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 64k freed INIT: version 2.78 booting Loading /etc/console-tools/default.kmap.gz Activating swap... Adding Swap: 264560k

Hi, i am seeing something interesting since the upgrade to 2.2.19/0.0.7a - I am experimenting with the am930 wireless driver and i am crashing on module exit. Everytime i reboot afterwards the var fs on /dev/hda8 is inconsistent [...] Checking all file systems... Parallelizing fsck version 1.21-WIP (01-Jun-2001) /dev/hda7: recovering journal /dev/hda7: clean, 39160/320640 files, 354596/640702

The messages btrfs: unlinked 123 orphans btrfs: truncated 456 orphans are not useful to regular users and raise questions whether there are problems with the filesystem. Signed-off-by: David Sterba <dsterba@suse.cz> --- fs/btrfs/inode.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 315a515..41a4d9c 100644 ---

Hi, I've seen a problem where on recovery after a crash the orphan cleanup code clears the read_only bit and does not reset it. This causes the the fsck to drop to the "fix filesystem" prompt simply because the root filesystem is now mounted rw. It looks like this: Creating rootdevice Mounting rootfilesystem EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs:

On Sat, Apr 19, 2014 at 05:42:12PM +0200, Patrik Horník wrote: > > Please confirm that this is fully correct solution (for my purpose, not > elegant clean way for official fix) and it has no negative consequences. It > seems that way but I did not analyze all code paths the fixed code is in. Yes, that's a fine solution. What I'll probably do is disable the check if

well, the next place to go, if fsck isn't enough would be to to try debugfs(1) man debugfs. On Wed, Nov 18, 2015 at 8:39 PM, Boylan, Ross <Ross.Boylan@ucsf.edu> wrote: > I guess some of the trouble was that the virtual disk was mounted > read-only at the VM level. When I mounted read/write I was able to do > fsck, which gave messages about replaying the logs and a couple

Is there a reason why an ext3 root partition cannot be copied to an alternate partition using the "dd" command? The dd is copying the mounted root partition into an alternate partition that is not mounted. The dd returns success, but the fsck on that partition fails with errors as follows: ----------------- fsck 1.37 (21-Mar-2005) /dev/Active_Update/root2: recovering journal

Hello Eric, thank you for the quick reply and the explanations. > dumpe2fs -h output might show us that. Filesystem volume name: <none> Last mounted on: /opt/ssd Filesystem UUID: 75d6aae6-1746-4260-994b-148dfdb5af95 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype