FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EXT3 Users

 
 
LinkBack Thread Tools
 
Old 04-02-2010, 10:08 PM
Morty
 
Default e2fsck: aborted

I've got an FS at $WORK that's giving a whole lot of fsck errors. It
starts like so:

fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
archive contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one
inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 163841: 101019648
Multiply-claimed block(s) in inode 163842: 101019649 101019650
101019651 101019652 101019653 101019654 101019655
Multiply-claimed block(s) in inode 163843: 101019656 101019657
101019658 101019659 101019660 101019661 101019662 101019663 101019664
101019665 101019666 101019667 101019668 101019669 101019670 101019671
101019672 101019673 101019674 101019675 101019676 101019677 101019678
101019679 101019680 101019681 101019682 101019683 101019684 101019685
101019686 101019687 101019688 101019689 101019690 101019691 101019692
101019693 101019694 101019695 101019696 101019697 101019698 101019699
101019700 101019701 101019702 101019703 101019704 101019705 101019706
101019707 101019708 101019709 101019710 101019711 101019712 101019713
101019714 101019715 101019716 101019717 101019718 101019719 101019720
101019721 101019722 101019723 101019724 101019725 101019726 101019727
101019728 101019729 101019730 101019731 101019732 101019733 101019734
101019735 101019736 101019737 101019738 101019739 101019740 101019741
101019742 101019743 101019744 101019745 101019746
[snip]

After a while of this, I get the following error:

e2fsck: Can't allocate block element
e2fsck: aborted

Google says the error relates to process memory size required for
large FSs. The FS here is a 1TB FS, created before I started using
largefile and largefile4 for large FSs. When I mount it, some data
seems to be lost. Anything I can do other than recover from backup?

- Morty

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 04-16-2010, 03:50 AM
Christian Kujau
 
Default e2fsck: aborted

A bit late, but....

On Fri, 2 Apr 2010 at 18:08, Morty wrote:
> e2fsck: Can't allocate block element
> e2fsck: aborted
>
> Google says the error relates to process memory size required for
> large FSs. The FS here is a 1TB FS, created before I started using

How many inodes are on this filesystem? See
http://lkml.org/lkml/2003/2/7/95 for some estimates. Maybe adding more
RAM/switching to 64bit (if not already done) might help.

Christian.
--
BOFH excuse #205:

Quantum dynamics are affecting the transistors

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 05-28-2010, 05:22 AM
"J.B. Nicholson-Owens"
 
Default e2fsck: aborted

Morty wrote:

Google says the error relates to process memory size required for
large FSs. The FS here is a 1TB FS, created before I started using
largefile and largefile4 for large FSs. When I mount it, some data
seems to be lost. Anything I can do other than recover from backup?


I too just experienced this with a 1TB EXT3 filesystem I can't mount.
I'm using Fedora GNU/Linux 13 on a 64-bit AMD system with 4GB RAM
(around 3.6GiB of RAM is visible according to the system monitor program
one runs via System -> About This Computer). I'm running Linux kernel
2.6.33.4-95.fc13.x86_64 (a Fedora kernel package).


I'm using the fsck that came with Fedora 13 (plus all of its updates):

$ rpm -qi e2fsprogs
Name : e2fsprogs Relocations: (not relocatable)
Version : 1.41.10 Vendor: Fedora Project
Release : 6.fc13 Build Date: Mon 15 Mar 2010
10:53:30 AM CDT
Install Date: Wed 07 Apr 2010 02:17:41 PM CDT Build Host:
xb-01.phx2.fedoraproject.org
Group : System Environment/Base Source RPM:
e2fsprogs-1.41.10-6.fc13.src.rpm

Size : 1943069 License: GPLv2
Signature : RSA/8, Mon 15 Mar 2010 11:17:10 AM CDT, Key ID
7edc6ad6e8e40fde




I tried to run

$ sudo fsck.ext3 -y -C0 /dev/sdc1

(-C0 because I wanted to see how far this would go and -y because I got
tired of answering "y"es to all the questions)


fsck aborted itself. I tried looking up this error response and reading
e2fsck.config manpage and then I added a config file:


$ cat /etc/e2fsck.conf
[scratch_files]
numdirs_threshold = 2
directory = /var/cache/e2fsck
dirinfo = true
icount = true

followed by re-running the fsck command above. There's over 780GiB free
on / (where the scratch directory is mounted), plenty of room to let
fsck avoid using RAM.


Both times the fsck process gets to 70% completion and starts a long
process of relocating data. That ends with:


[...thousands of lines like the following...]
Relocating group 7451's block bitmap from 244154368 to 244154626...
Relocating group 7451's inode bitmap from 244154369 to 244154627...
Relocating group 7451's inode table from 244154370 to 244154628...
Relocating group 7452's block bitmap from 244187136 to 244187394...
Relocating group 7452's inode bitmap from 244187137 to 244187395...
Relocating group 7452's inode table from 244187138 to 244187396...
e2fsck: aborted

and I'm still left with a volume I can't mount.

I was surprised that even though I specified I wanted the fsck to use
the scratch directory the files in the scratch directory aren't very
large and all of my remaining RAM is still used by fsck. It's as if
using the scratch directory only made the process run slower but didn't
change anything to do with (what I'm reading) is the main problem--not
enough RAM to hold the data fsck needs while it runs.


I can't add more RAM to the system, 4GB is its max.

Has there been any improvement on doing fsck on large volumes (where
"large" means larger than what fsck can work with in available system
RAM)? I'd gladly trade repair time and disk space for an fsck that
worked. Any ideas on how I can get fsck to run and actually fix this
volume would be welcome.


Thanks.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 05-28-2010, 11:22 PM
Andreas Dilger
 
Default e2fsck: aborted

On 2010-05-27, at 23:22, J.B. Nicholson-Owens wrote:
> Morty wrote:
>> Google says the error relates to process memory size required for
>> large FSs. The FS here is a 1TB FS, created before I started using
>> largefile and largefile4 for large FSs. When I mount it, some data
>> seems to be lost. Anything I can do other than recover from backup?
>
> I too just experienced this with a 1TB EXT3 filesystem I can't mount. I'm using Fedora GNU/Linux 13 on a 64-bit AMD system with 4GB RAM (around 3.6GiB of RAM is visible according to the system monitor program one runs via System -> About This Computer). I'm running Linux kernel 2.6.33.4-95.fc13.x86_64 (a Fedora kernel package).

I can't imagine that there is a shortage of RAM for a 1TB filesystem. We run e2fsck on 3x 8TB filesystems with only 2GB of RAM.

> Both times the fsck process gets to 70% completion and starts a long process of relocating data. That ends with:
>
> [...thousands of lines like the following...]
> Relocating group 7451's block bitmap from 244154368 to 244154626...
> Relocating group 7451's inode bitmap from 244154369 to 244154627...
> Relocating group 7451's inode table from 244154370 to 244154628...
> Relocating group 7452's block bitmap from 244187136 to 244187394...
> Relocating group 7452's inode bitmap from 244187137 to 244187395...
> Relocating group 7452's inode table from 244187138 to 244187396...
> e2fsck: aborted

What is more important to know is why it thinks the block/inode bitmaps and
inode table need to be relocated in the first place. That is a pretty serious/significant problem that should normally never been seen, since the bitmaps never move, and there are backups of all the group descriptors (that say where the bitmaps are located).

> and I'm still left with a volume I can't mount.

Did you do something like resize your filesystem before having this problem?

Cheers, Andreas






_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 05-28-2010, 11:49 PM
"J.B. Nicholson-Owens"
 
Default e2fsck: aborted

Andreas Dilger wrote:

What is more important to know is why it thinks the block/inode
bitmaps and inode table need to be relocated in the first place. That
is a pretty serious/significant problem that should normally never
been seen, since the bitmaps never move, and there are backups of all
the group descriptors (that say where the bitmaps are located).


I was unaware this was such a serious issue. Unfortunately I have no
helpful information to offer.


Did you do something like resize your filesystem before having this
problem?


No resizing at all; this drive has always had one volume on it at max
size (1TB minus whatever ext3 needs for its own bookkeeping).


I used to have this drive mounted in another computer running gNewSense
(latest + updates) but I thought I'd detach it and put the drive on this
64-bit 4GB machine.

Does it matter that the other system was a 32-bit system? Would it be
wise to attempt fsck on a 32-bit machine?

Thanks for your input.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 
Old 05-29-2010, 02:47 AM
Andreas Dilger
 
Default e2fsck: aborted

On 2010-05-28, at 17:49, J.B. Nicholson-Owens wrote:
> Andreas Dilger wrote:
>> What is more important to know is why it thinks the block/inode
>> bitmaps and inode table need to be relocated in the first place. That
>> is a pretty serious/significant problem that should normally never
>> been seen, since the bitmaps never move, and there are backups of all
>> the group descriptors (that say where the bitmaps are located).
>
> I was unaware this was such a serious issue. Unfortunately I have no
> helpful information to offer.

Unless you have the original output from the first e2fsck run, it will be quite difficult to determine what actually went wrong here.

>> Did you do something like resize your filesystem before having this
>> problem?
>
> No resizing at all; this drive has always had one volume on it at max size (1TB minus whatever ext3 needs for its own bookkeeping).
>
> I used to have this drive mounted in another computer running gNewSense
> (latest + updates) but I thought I'd detach it and put the drive on this
> 64-bit 4GB machine.
>
> Does it matter that the other system was a 32-bit system? Would it be
> wise to attempt fsck on a 32-bit machine?

It shouldn't make any difference, but it isn't impossible that there is some kind of bug involved, since I doubt this gets tested all too often. That said, it seems unlikely, since I'm sure it _does_ happen often enough that it would be reported. It wouldn't hurt to give it a try on the original 32-bit system, but I fear that even if that were the cause the later e2fsck runs may have changed the filesystem enough that it will be hard to recover.


Cheers, Andreas






_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
 

Thread Tools




All times are GMT. The time now is 07:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org