All of lore.kernel.org
 help / color / mirror / Atom feed
* reiserfsprogs: options for recovering from reiserfsck/"Not enough allocable blocks"
@ 2007-01-23 13:29 sean finney
       [not found] ` <200701231919.37775.vs@namesys.com>
  0 siblings, 1 reply; 2+ messages in thread
From: sean finney @ 2007-01-23 13:29 UTC (permalink / raw)
  To: reiserfs-list

[-- Attachment #1: Type: text/plain, Size: 3665 bytes --]

hi folks,

first, some background:

the server:

reiserfsprogs-3.6.19-1mdk
Mandrakelinux release 10.2 (Limited Edition 2005) for i586
Linux 2.6.11-6mdk i686

the partition in question:

~250 GB md(raid1)/lvm reisers partition.  

what happened:

during all that crazy cross-europe stormy weather last week, there was a
power outage and this server came up with some filesystem problems.  the
filesystem mounted, but some files couldn't be deleted/listed/etc.
fscking led to "you must run with rebuild-tree (cringe)", and re-running
it gave the following:

(sorry for the line-wrapping) 

[root@nnnn /]# fsck.reiserfs --rebuild-tree /dev/mapper/vg0-backup
reiserfsck 3.6.19 (2003 www.namesys.com)

*************************************************************
** Do not  run  the  program  with  --rebuild-tree  unless **

<snip>

Will rebuild the filesystem (/dev/mapper/vg0-backup) tree
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you
do):Yes
Replaying journal..
Reiserfs journal '/dev/mapper/vg0-backup' in blocks [18..8211]: 0
transactions replayed
###########
reiserfsck --rebuild-tree started at Tue Jan 23 10:32:54 2007
###########

Pass 0:
####### Pass 0 #######
Loading on-disk bitmap .. ok, 73257983 blocks marked used
Skipping 10446 blocks (super block, journal, bitmaps) 73247537 blocks
will be read
0%block 1444048: The number of items (1792) is incorrect, should be (1)
- corrected
block 1444048: The free space (38084) is incorrect, should be (4048) -
correctedpass0: vpf-10110: block 1444048, item (0): Unknown item type
found [808466737 667936 0x421117 ??? (15)] - deleted
block 1584107: The number of items (1536) is incorrect, should be (1) -
corrected

<snip maybe 200 or so entries>

block 73233074: The free space (749) is incorrect, should be (4072) -
corrected
                                              left 0, 9774 /sec
2 directory entries were hashed with not set hash.
8277276 directory entries were hashed with "r5" hash.
        "r5" hash is selected
Flushing..finished
        Read blocks (but not data blocks) 73247537
                Leaves among those 308680
                        - leaves all contents of which could not be
saved and deleted 29
                Objectids found 2876806

Pass 1 (will try to insert 308651 leaves):
####### Pass 1 #######
Looking for allocable blocks .. finished
0%....20%....40%....60%....80%....pass1: block 72549223, item 0, entry
60: The entry "continuous_measuremunt_20021031150614.txt" of the
[3326546 6081821 0xd2c5200 DIR (3)] is hashed with not set whereas
proper hash is "r5" - deleted
Not enough allocable blocks, checking bitmap...there are 1 allocable
blocks, btwout of disk space
Aborted (core dumped)



and so goes the saga.  being a good netizen, i've done some preliminary
googling before coming to you.  it seems there are two common
suggestions for when this happens:

(1) extend the device (and the fs?) and re-run.  unfortunately this
isn't really an option for me as that's pretty much all the disk space
on the system, and it's in LVM on an existing raid1 device (which would
really complicate things and i've had bad experiences with removing
logical volumes from an LVM volume group at a later point)

(2) reiserfsprogs 3.6.20, which may have a fix?  doesn't look released
yet, and i'm not sure how stable/dangerous it is.

also, i've heard mention of --scan-whole-partition.  would that be
advisable in this situation with 3.6.19?  are there any other
suggestions?

any help would be much appreciated,
	sean



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: reiserfsprogs: options for recovering from reiserfsck/"Not enough allocable blocks"
       [not found] ` <200701231919.37775.vs@namesys.com>
@ 2007-01-23 16:05   ` sean finney
  0 siblings, 0 replies; 2+ messages in thread
From: sean finney @ 2007-01-23 16:05 UTC (permalink / raw)
  To: Vladimir V. Saveliev; +Cc: reiserfs-list

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

hi vladimir,

On Tue, 2007-01-23 at 19:19 +0300, Vladimir V. Saveliev wrote:
> You should setup a linear raid (IMPORTANT: with no persistent super block) of /dev/mapper/vg0-backup and some spare device.
> Spare device does not have to be big. I do not think that you can not find 50mb of disk space to create a loop device on that space.
> Then you have to run --rebuild-sb and --rebuild-tree
> 
> See more details at http://www.mail-archive.com/reiserfs-list@namesys.com/msg21597.html

thanks for this.  it's less complicated than i thought.  i'll report
back tomorrow morning/afternoon after i've had the chance to run it.

> > (2) reiserfsprogs 3.6.20, which may have a fix?  doesn't look released
> > yet, and i'm not sure how stable/dangerous it is.
> > 
> 3.6.20 does not have a fix for that bug.
> 
> > also, i've heard mention of --scan-whole-partition.  would that be
> > advisable in this situation with 3.6.19?  
> 
> no

thanks for the clarifications on these, saves me some time and possible
fs corruption :)



	sean

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-01-23 16:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-23 13:29 reiserfsprogs: options for recovering from reiserfsck/"Not enough allocable blocks" sean finney
     [not found] ` <200701231919.37775.vs@namesys.com>
2007-01-23 16:05   ` sean finney

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.