From: Sven Heinicke <sven@research.nj.nec.com>
To: linux-kernel@vger.kernel.org
Subject: ReiserFS and RAID5
Date: Thu, 24 Jan 2002 13:46:07 -0500 (EST) [thread overview]
Message-ID: <15440.22127.875361.718680@abasin.nj.nec.com> (raw)
We had a drive go bad on a RAID5 with reiserfs on it. The file system
was built with reiserfsprogs-3.x.0h tools and the systems was running
Linux 2.4.13. As we had an issue it will be updated to the latest
kernel, it had been stable up to now.
A drive failed and left the partition in a funk. When I ran ls in the
RAID directory it would freeze up the ls (I suspect in a hardware wait
of some kind). I uncommented the partition from the fstab file then
tied to shut down the system, but that froze up that system and I hit
the reset key.
The system came up, the raid started rebuilding itsself with the spare
drive. I tried to mount the drive and it didn't mount. I updated my
reiserfs tools to reiserfsprogs-3.x.0j. I ran reiserfsck on the
partition, I wish I kept the exact error message but didn't, it said
something was wrong with the tree and segfaulted. I then ran it with
--rebuild-tree and went home.
The next morning the raid rebuild and the fsck was finished (should of
I waited for the raid rebuild to finish before running reiserfsck?).
I mounted the disk read only. The df command reported 1% full when
before it was like 35% full.
But, all was not lost. inspecting the partition all the data seemed
to be good. We hurriedly we copied the files to another partition,
took another night, oddly one directory didn't get copied.
Then some testing:
1. umounted to mounted /mnt/raid0 a coupld of time in read only mode.
(nothing changed).
2. mounted in read-write.
(nothing changed)
3. touched /mnt/raid0/foo
(nothing changed)
4. rm /mnt/raid0/foo
(nothing changed in df). Lost a whole bunch of data according to
du and other programs. Specifically, we were able to copy:
121M scoutabout/08Oct01
59G scoutabout/21Nov01
38G scoutabout/23Jul01
5.4G scoutabout/23Jul01Output
65G scoutabout/27Nov01
4.1G scoutabout/29Jun01
But now the corrupted file system reads:
121M /mnt/raid0/scoutabout/08Oct01
1.0k /mnt/raid0/scoutabout/12Nov01
59G /mnt/raid0/scoutabout/21Nov01
38G /mnt/raid0/scoutabout/23Jul01
238M /mnt/raid0/scoutabout/23Jul01Output
65G /mnt/raid0/scoutabout/27Nov01
4.1G /mnt/raid0/scoutabout/29Jun01
and that is the state we are in. At least most of our data is saved.
Did I do anything wrong that might of been able to keep the RAID
stable after the drive crash? Would reiser developers want me to try
anything on it to help them debug it and make the support more stable.
Thanks,
Sven
next reply other threads:[~2002-01-24 18:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-24 18:46 Sven Heinicke [this message]
2002-01-24 19:06 ` Stephan von Krawczynski
2002-01-24 19:49 ` Stephan von Krawczynski
2002-01-24 20:51 ` Stephan von Krawczynski
2002-01-24 19:14 ` Sven Heinicke
2002-01-24 20:29 ` Simen Thoresen
2002-01-24 21:48 ` Sven Heinicke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15440.22127.875361.718680@abasin.nj.nec.com \
--to=sven@research.nj.nec.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®