I'm in a bit of a pickle and need to find a way to pass boot params to a
reiserfs rootfs to *prevent* it from replaying the journal on single-user
boot. This may seem like a strange request, but I've got a degraded RAID array
that I need to poke around in before deciding whether or not to send a disk
off to a rehab lab. If the replay occurs, it will potentially destroy the fs
since I'm using a degraded snapshot of the failed disk in hopes of reclaiming
*some* of my data. The system is running 2.2.x (can't remember and can't find
out w/out booting).
Do I have a snowball's chance of pulling this off?
thanks,
stewart
On December 12, 2001 21:50, Stewart Allen wrote:
> I'm in a bit of a pickle and need to find a way to pass boot params to a
> reiserfs rootfs to *prevent* it from replaying the journal on single-user
> boot. This may seem like a strange request, but I've got a degraded RAID
> array that I need to poke around in before deciding whether or not to send
> a disk off to a rehab lab. If the replay occurs, it will potentially
> destroy the fs since I'm using a degraded snapshot of the failed disk in
> hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> remember and can't find out w/out booting).
>
> Do I have a snowball's chance of pulling this off?
Well, kinda. The only thing that can deter ReiserFS from replaying the
journal is convincing it that the physical media it's on is actually read
only. Some quick less/grep work revealed that there is no option that makes
the SCSI subsystem claim its devices are readonly (although it'd be extremely
useful for situations such as this).
It'd probably be pretty easy to make a boot disk using a hacked version of
ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
top of journal_read(struct super_block *) in journal.c. However, you might
feel more comfortable sending it off for data recovery than testing kernel
hacks on it ;)
-Ryan
Ryan Cumming wrote:
>On December 12, 2001 21:50, Stewart Allen wrote:
>
>>I'm in a bit of a pickle and need to find a way to pass boot params to a
>>reiserfs rootfs to *prevent* it from replaying the journal on single-user
>>boot. This may seem like a strange request, but I've got a degraded RAID
>>array that I need to poke around in before deciding whether or not to send
>>a disk off to a rehab lab. If the replay occurs, it will potentially
>>destroy the fs since I'm using a degraded snapshot of the failed disk in
>>hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
>>remember and can't find out w/out booting).
>>
>>Do I have a snowball's chance of pulling this off?
>>
>
>Well, kinda. The only thing that can deter ReiserFS from replaying the
>journal is convincing it that the physical media it's on is actually read
>only. Some quick less/grep work revealed that there is no option that makes
>the SCSI subsystem claim its devices are readonly (although it'd be extremely
>useful for situations such as this).
>
>It'd probably be pretty easy to make a boot disk using a hacked version of
>ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
>top of journal_read(struct super_block *) in journal.c. However, you might
>feel more comfortable sending it off for data recovery than testing kernel
>hacks on it ;)
>
>-Ryan
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
why not just edit the source code directly and recompile?
Hans
--------- Received message begins Here ---------
>
> On December 12, 2001 21:50, Stewart Allen wrote:
> > I'm in a bit of a pickle and need to find a way to pass boot params to a
> > reiserfs rootfs to *prevent* it from replaying the journal on single-user
> > boot. This may seem like a strange request, but I've got a degraded RAID
> > array that I need to poke around in before deciding whether or not to send
> > a disk off to a rehab lab. If the replay occurs, it will potentially
> > destroy the fs since I'm using a degraded snapshot of the failed disk in
> > hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> > remember and can't find out w/out booting).
> >
> > Do I have a snowball's chance of pulling this off?
>
> Well, kinda. The only thing that can deter ReiserFS from replaying the
> journal is convincing it that the physical media it's on is actually read
> only. Some quick less/grep work revealed that there is no option that makes
> the SCSI subsystem claim its devices are readonly (although it'd be extremely
> useful for situations such as this).
>
> It'd probably be pretty easy to make a boot disk using a hacked version of
> ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
> top of journal_read(struct super_block *) in journal.c. However, you might
> feel more comfortable sending it off for data recovery than testing kernel
> hacks on it ;)
Wouldn't it be better to make a backup (dd copy) of the disk volume to another
drive? The raid would not be mounted, so the fs would not be updated.
I would recommend that be done even before sending the disk out.
ALTERNATIVE TO READ-ONLY and this might not be possible.
If the raid is SCSI based, then there is (should be) a read-only switch
in the disk configuration. Most disks do not have a jumper there, and since
they are usually internal only, the option is not used. Putting the jumper
on (or removing one if it is there - depends on the drive) will make the
disk read-only.
Even some IDE drives may have this option, though finding documentation on
it may be difficult to locate.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Thu, 13 Dec 2001, Hans Reiser wrote:
> Ryan Cumming wrote:
>
> >On December 12, 2001 21:50, Stewart Allen wrote:
> >
> >>I'm in a bit of a pickle and need to find a way to pass boot params to a
> >>reiserfs rootfs to *prevent* it from replaying the journal on single-user
> >>boot. This may seem like a strange request, but I've got a degraded RAID
> >>array that I need to poke around in before deciding whether or not to send
> >>a disk off to a rehab lab. If the replay occurs, it will potentially
> >>destroy the fs since I'm using a degraded snapshot of the failed disk in
> >>hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> >>remember and can't find out w/out booting).
> >>
> >>Do I have a snowball's chance of pulling this off?
> >>
> >
> >Well, kinda. The only thing that can deter ReiserFS from replaying the
> >journal is convincing it that the physical media it's on is actually read
> >only. Some quick less/grep work revealed that there is no option that makes
> >the SCSI subsystem claim its devices are readonly (although it'd be extremely
> >useful for situations such as this).
> >
> >It'd probably be pretty easy to make a boot disk using a hacked version of
> >ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
> >top of journal_read(struct super_block *) in journal.c. However, you might
> >feel more comfortable sending it off for data recovery than testing kernel
> >hacks on it ;)
> >
> >-Ryan
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to [email protected]
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> why not just edit the source code directly and recompile?
>
> Hans
There are a couple of potential problems with this approach:
1. I thought the on-disk structures for ReiserFS changed sometime
between 2.2.something (the system in question) and now. Since I
cannot pinpoint the kernel/patch version, I'm not sure this hack
will work.
2. I have no other systems like this one to test the read-only hack on.
Without a fairly high degree of confidence that I'm actually booting
in a no-replay read-only state, I'm not going to take chances with
this data.
stewart
On Thu, 13 Dec 2001, Jesse Pollard wrote:
> --------- Received message begins Here ---------
>
> >
> > On December 12, 2001 21:50, Stewart Allen wrote:
> > > I'm in a bit of a pickle and need to find a way to pass boot params to a
> > > reiserfs rootfs to *prevent* it from replaying the journal on single-user
> > > boot. This may seem like a strange request, but I've got a degraded RAID
> > > array that I need to poke around in before deciding whether or not to send
> > > a disk off to a rehab lab. If the replay occurs, it will potentially
> > > destroy the fs since I'm using a degraded snapshot of the failed disk in
> > > hopes of reclaiming *some* of my data. The system is running 2.2.x (can't
> > > remember and can't find out w/out booting).
> > >
> > > Do I have a snowball's chance of pulling this off?
> >
> > Well, kinda. The only thing that can deter ReiserFS from replaying the
> > journal is convincing it that the physical media it's on is actually read
> > only. Some quick less/grep work revealed that there is no option that makes
> > the SCSI subsystem claim its devices are readonly (although it'd be extremely
> > useful for situations such as this).
> >
> > It'd probably be pretty easy to make a boot disk using a hacked version of
> > ReiserFS that refuses to replay the journal, by adding a "return 0;" near the
> > top of journal_read(struct super_block *) in journal.c. However, you might
> > feel more comfortable sending it off for data recovery than testing kernel
> > hacks on it ;)
>
> Wouldn't it be better to make a backup (dd copy) of the disk volume to another
> drive? The raid would not be mounted, so the fs would not be updated.
>
> I would recommend that be done even before sending the disk out.
>
> ALTERNATIVE TO READ-ONLY and this might not be possible.
>
> If the raid is SCSI based, then there is (should be) a read-only switch
> in the disk configuration. Most disks do not have a jumper there, and since
> they are usually internal only, the option is not used. Putting the jumper
> on (or removing one if it is there - depends on the drive) will make the
> disk read-only.
>
> Even some IDE drives may have this option, though finding documentation on
> it may be difficult to locate.
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: [email protected]
>
> Any opinions expressed are solely my own.
The RAID array uses 3ware's Escalade switch so all the drives are EIDE.
I've used read-only jumpers on SCSI drives in the past and hoped that these
supported it as well, but when I took the array apart, my hopes were dashed.
The drive that crashed will not spin up so I cannot dd back it up. I will be
doing this with two of the other disks, which should comprise a complete (if
degraded) image set.
stewart
On December 13, 2001 01:28, Hans Reiser wrote:
> >It'd probably be pretty easy to make a boot disk using a hacked version of
> >ReiserFS that refuses to replay the journal, by adding a "return 0;" near
> > the top of journal_read(struct super_block *) in journal.c. However, you
> > might feel more comfortable sending it off for data recovery than testing
> > kernel hacks on it ;)
> why not just edit the source code directly and recompile?
Just curious, but how would editing the source and recompiling be any
different from what I suggested?
-Ryan
Ryan Cumming wrote:
>On December 13, 2001 01:28, Hans Reiser wrote:
>
>>>It'd probably be pretty easy to make a boot disk using a hacked version of
>>>ReiserFS that refuses to replay the journal, by adding a "return 0;" near
>>>the top of journal_read(struct super_block *) in journal.c. However, you
>>>might feel more comfortable sending it off for data recovery than testing
>>>kernel hacks on it ;)
>>>
>
>>why not just edit the source code directly and recompile?
>>
>
>Just curious, but how would editing the source and recompiling be any
>different from what I suggested?
>
>-Ryan
>
>
email delay time. ;-)
Stewart, you can get Edward to create a new option for you by going to
http://www.namesys.com/support.html
$25 and you get a patch and all the additional support you need (sounds
like you may need some for figuring out what version you have on the
disk, etc.).
Or you might try what Ryan says, and save $25.
Hans
On Thursday, December 13, 2001 10:02:21 PM +0300 Hans Reiser
<[email protected]> wrote:
> Ryan Cumming wrote:
>
>> On December 13, 2001 01:28, Hans Reiser wrote:
>>
>>>> It'd probably be pretty easy to make a boot disk using a hacked version
>>>> of ReiserFS that refuses to replay the journal, by adding a "return 0;"
>>>> near the top of journal_read(struct super_block *) in journal.c.
>>>> However, you might feel more comfortable sending it off for data
>>>> recovery than testing kernel hacks on it ;)
>>>>
>>
>>> why not just edit the source code directly and recompile?
I posted a path for this a few months ago, hold on I'm rediffing real quick...
-chris
Ok, the patch is attached, it was against 2.4.17-pre8 but should apply to
2.4.16 (let me know if you have problems).
To use, mount the FS with -o noreplay. If there are transactions that need
to be replayed, it will force the FS readonly, otherwise, you get a normal rw
mount. So, you might want to use -o ro,noreplay instead.
You'll need a boot disk with the patched 2.4.x kernel (it will be able to
read the 2.2.x reiserfs disk).
Now, with all of that said, I don't think this is the best way to poke around
on the degraded array (RAID5 with one disk dead?). Grab the 3.x.0j version
of reiserfsprogs, and we can use debugreiserfs to get a look at what metadata
is still usable on the FS.
If the data is important, I'd strongly suggest finding a way to back it up (a
raw copy of the other two drives is better than nothing) before trying
anything fancy. Even if this means a trip to the computer store and some
extra downtime.
-chris