<?xml version="1.0"?>
<atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns:html="http://www.w3.org/1999/xhtml">
  <atom:id>http://bertrand.gotpike.org/atom/start/2006-07-06/1</atom:id>
  <atom:title type="text">Bertrand LUPART :: reiserfsck --rebuild-tree and when backup saves your life</atom:title>
  <atom:updated>2026-06-04T14:51:19-04:00</atom:updated>
  <atom:link href="http://bertrand.gotpike.org/atom/start/2006-07-06/1" type="application/atom+xml"></atom:link>
  <atom:link href="http://bertrand.gotpike.org/space/start/2006-07-06/1" type="text/html"></atom:link>
  <atom:link href="http://bertrand.gotpike.org/rss/start/2006-07-06/1" type="application/rss+xml"></atom:link>
  <atom:generator uri="http://modules.gotpike.org/blahblah/Public.Syndication.ATOM" version="0.1">Public.Syndication.ATOM (Pike v8.0 release 702)</atom:generator>
  <atom:icon>http://bertrand.gotpike.org/favicon.ico</atom:icon>
  <atom:logo>http://bertrand.gotpike.org/0</atom:logo>
  <atom:subtitle type="xhtml"><html:div xmlns:html="http://www.w3.org/1999/xhtml"><html:p>After a powerfailure on my main file server, reiserfsck said some errors was found on a reiserfs partition, and <html:b class="bold">reiserfsck --rebuild-tree</html:b> was required.</html:p><html:p class="paragraph"/>
Off course, RAID 1 doesn't help in this case.<html:p class="paragraph"/>
The reiserfsck man page says you'd better backup your data before proceeding with <html:b class="bold">--rebuild-tree</html:b>.<html:p class="paragraph"/>
__Believe them__.<html:p class="paragraph"/>
Following this advice, i hopefully made a last backup before proceeding. The reiserfs partition was perfectly readable, except some files.<html:p class="paragraph"/>
Crawling the web, i learned on multiple sites that until <html:b class="bold">reiserfsck --rebuild-tree</html:b> hasn't finished it's job, the partition was unusable at all.<html:p class="paragraph"/>
This operation really takes a long time. Don't estimate the time remaining on the number on remaining blocks and the blocks/seconds. Mine was stuck for many hours on pass #2, eating as much as CPU as possible.<html:p class="paragraph"/>
Waiting for more than 12 hours for repairing a 200GB partition was fruitless: it ended up saying there were not enough space left on the drive. Not only the drive had a powerfailure while writing data, but some people here were uploading lots of data and there were very little space left (around 5MB). That's something like Murphy's law.<html:p class="paragraph"/>
The backup was put in place, i strongly believed the original reiserfs partition were lost forever. I better understand now the amount of blocks reserved for root on ext2/ext3 filesystems. I think i'll have a look if this kind of option is available on reiser, too.<html:p class="paragraph"/>
I relaunched the check, mostly for educational purpose. Noone were complaining about lack of data nor data corruption on the backup.<html:p class="paragraph"/>
It runned all the night, and on the next morning the drive was <html:b class="bold">totally fixed</html:b>.<html:p class="paragraph"/>
OK, <html:b class="bold">reiserfsck --rebuild-tree</html:b> did it's job. Thanx to all reiserfs crew.&#xD;
It didn't ate data, but it took almost 24 hours to do that, an amount of time i couldn't make my users wait for.<html:p class="paragraph"/>
I discovered i'm now too old to live with the fsck adrenalin :) I hereby promise to make stronger backups now.<html:p class="paragraph"/>
Better spend some minutes a day backuping and making sure it's backuped than loose many hours of your life and hours/weeks/month/years of others people work on a power/hard drive failure.&#xD;
</html:div></atom:subtitle>
</atom:feed>
