similar to: e2fsck errors after lvextend when trying to resize2fs

Hi. I'm attempting to setup a box here to be a file-server for all my data. I'm attempting to resize an ext3 partition to demonstrate this capability to myself before fully committing to this system as the primary data storage. I'm having some problems resizing an ext3 filesystem after I've resized the underlying logical volume. Following the ext3 resize, fsck spits out lots

On Sun, Jun 01, 2014 at 11:24:51PM -0400, Theodore Ts'o wrote: > > The "get root inode failed" is rather unfortunate. Heh, I like your understatement. :) I think this helps answer part of my questions in my second email: I should probably try to preserve changes from last backup before getting too deep into a tricky e2fsck. At one point the fs was still mountable, so I

hi, just wanted to mention that using 1.36-rc1 fixes the following bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144771 thanks to benjamin scott for the hint, and theodore ts'o for fixing. building a source and binary rpm with the provided spec file works flawlessly under fc3 (just had to remove -rc1 from the archive name and Version: in the spec file). if you are replying to

Hi, I've installed a few Fedora Core 4 and Fedora Core 5 recently, and found that the new ext3 file systems created with new mkfs.ext3(1.38+) has one more field than EXT3 created with old mkfs.ext3(1.34-), even the latter's dir_index feature was turned on and file systems were upgraded with "e2fsck -y -f -D" command. I have three questions thereafter: 1) what does the

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

On Sun, Jun 01, 2014 at 08:54:24PM -0700, Keith Keller wrote: > > Heh, I like your understatement. :) I think this helps answer part of > my questions in my second email: I should probably try to preserve > changes from last backup before getting too deep into a tricky e2fsck. > At one point the fs was still mountable, so I could have tried to copy > files off first. (In a

I've been thinking recently that we should re-enable DIR_INDEX in mke2fs by default. When it first came out, we had done this and were bitten by a few bugs in the code. However, this code has been in heavy use for several thousand filesystem years in Lustre, if not elsewhere, and I'm inclined to think it is pretty safe these days. Likewise, RHEL/FC have had RESIZE_INODE as a standard

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

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

Helping a friend fix a computer that was having severe, weird troubles. Reformatted (from XP) and installed Fedora. Install went ok, on first boot, however, filesystem was READONLY for some reason. Knew hard drive was suspect, so I e2fsck'd it over and over all night long, fall asleep next to the computer. This morning, Fedora boots fine, login not a problem, so I shut down and fsck it again,

Hi, on all of my CentOS7 VMs on different hypervisors the config file e2fsck.conf contains the line broken_system_clock = 1 I found this because on all of them, the root partition was not checked triggered by interval setting with tune2fs. Do you see similiar /default/ settings on your machines? Is it an issue only on VMs? I have no CentOS7 host on bare metal to compare. Thanks and cheers,

SUMMARY We are getting many ``Free blocks count wrong for group'' errors when running e2fsck on a 245-GB ext3 filesystem. This is when the file system is cleanly unmounted on a relatively quiet system to do a resize. From reading other messages here, my suspicion is that this is because we have e2fsprogs 1.32. Questions: * Should we use e2fsck/e2fsprogs 1.36 and will that probably

Hi, just to do nothing wrong: for lustre 1.6.0.1 e2fsprogs version: 1.39.cfs8 is recommended. Can I assume that I can also better use the most recent version which is recommended for 1.6.4.1 which is e2fsprogs version: 1.40.2-cfs1 Harald -- Harald van Pee Helmholtz-Institut fuer Strahlen- und Kernphysik der Universitaet Bonn

Hi, I'm about to roll out a whole bunch of Redhat Enterprise 4 workstations and have run into problems cloning from the original. Normally I would use ghost (v7.5) because it does a nice job when cloning to a different sized disk.Unfortunately it comes up with read error 29004. Looking around it seems that Symantec don't support Fedora Core 3 (with Ghost v.8 - don't know if v.9 works

Hello, We have an IA64 cluster with 64K kernel page size and we use lustre 1.4.8.1 and e2fsprogs-1.39cfs8. We meet the following problem : 1. I Create a Lustre file system, then start this file system and mount it on a client node 2. On this client node, I copy 2 files in my /mnt/lustre 3. I umount Lustre file system on this client node then stop Lustre file system 4. I use then :

hi, i have a tricky situation here and and don't know where to start with the solution. i happened to set up a linux system, but i had to install the base system on another machine. i used e2fsprogs 1.30-WIP (30-Sep-2002) for this. now the machine is up and running, but i have to use e2fsprogs 1.27 (8-Mar-2002). it's a debian system and i wanted to stay sane & stable, hence using

Hi Bodo and Ted, Thank you both for your responses; they confirm what I thought might be the case. Knowing that I can try to proceed with your suggestions. I do have some followup questions for you: On Sun, Jun 01, 2014 at 09:05:09PM -0400, Theodore Ts'o wrote: > Unfortunately, there has been a huge number of bug fixes for ext4's > online resize since 2.6.32 and 1.42.11.

(There really doesn't seem to be a dedicated e2fsprogs list, so this was the next-best place I could find. I don't place much faith in the sourceforge forums..) The filesystem in question is a 480 gig ext3 partition, on a hardware RAID5 controller. It's approximately 90% full, with something like 115K files. Kernel 2.4.20-pre4, on a Duron 900. As I type this, e2fsck has used up

Hi guys, I''ve seen this post regarding "lvm resize" and this contains all the information I need to resize a disk inside domU : http://lists.xensource.com/archives/html/xen-users/2006-11/msg00019.html >From this post: "With this I can extend the LVs in the Dom0, and either shutdown the DomU and resize2fs from Dom0 or even (tested on test VMs and low-use