RE: [Evms-devel] EVMS and Drive Linking

[Stian B. B. <st...@ba...>]

Quite the long posting, but I did some (perhaps) interesting lab work, =
so
read to the bottom!!

[snip]
>Not possible ... unless ... hdc had old drivelink metadata on it.  Did =
it?
>What was the last thing you used this disk for?   When you run evmsn or
>evmsgui or whatever ... and you delete a storage object ... the plug-in
>managing the storage object will delete its metadata so that you won't
>discover the storage object the next time you run evms and you wont
>discover the storage object unexpectedly if you move the disk to a
>different system.  If you simply pull the disk from a system it will =
still
>have metadata on it ... which is generally not a good thing.  There is
>simply no way that your drivelink suddenly contained a replacement disk =
...
>unless ... the disk had old drivelink metadata on it or else it was
>deliberately added.  Perhaps your saying that you did a replace on the
>missing child object??

The disk was containing an ntfs file system before I replaced. Honestly =
I
don't know what actually happened, maybe I did something wrong, but I =
can't
remember! :)

>>placeholder, and reporting total size 2 gb too large!). Sadly I did =
not
>>just

>Guessing that hdc was a 2gb drive ...

That is correct! :)


>>escape and try again, but rather saved. The result was disaster, all =
the

>What changes did you save.  Just starting evms and saving will =
generally
>just activate DM mappings.  If you haven't made any configuration =
changes
>then you should not have saved any configuration changes.

This is what I thought, just dunno what happened!=20

>>disks were available again (empty like) and the Feature object
>>disappeared.

>>Oh well. I try again. Have just set up the drive link again, filled it
>>with
>>data, and I am currently killing off the hdb drive (the first in the =
drive
>>link). This time I chose ext3 file system. Fingers crossed!

>Looking forward to hearing about this attempt.

Okay, here it is!

EXT3 disk nr 2:
I first set up ext3 with three disks. I powered down, rmoved the nr.2 =
disk
and booted. Now my drive link (DL) was again reported broken and my nr.2
disk was replaced with a placeholder like before. EVMS reported that it =
was
going to put my DL in read only mode, but I used Kevin's patch so this =
did
not happen. I mounted the DL and was able to run fix, read/write data =
but of
course I got a lot of inode errors (missing as such), but it still =
worked.=20

Then I tried to shrink the DL in EVMS but this was not possible. It's =
not an
option to shrink with the placeholder, you must shrink with a physical =
disk
with no errors. Also the replace is a no go. From what I see I can still
extend the DL with another disk but I have not tried this.=20

EXT3 disk nr 1:
Now I got cocky so I shut down and installed the nr. 2 disk, booted, ran
fsck.ext3 on it (just to make sure all was dandy), shut down again, =
removed
disk nr. 1. Well, now problems occurred. No longer could I mount the =
file
system or run fsck.ext3 on it. I read in the man page to do a mke2fs -n
/dev/evms/ld to find alternate superblocks, which I found, and then run =
the
command "fsck.ext3 -b "superblock number here" /dev/evms/ld". Sadly this =
did
not work, fsck only reported "Could this be a zero length partition?". I
tried all the superblocks I found, but none worked.

Cannot find any other way to repair the remains of this partition. Maybe =
if
I could remove the placholder I could find some data for fsck to work =
with.
In my case here it needs to work trough 2,3 GB of empty/broken data =
blocks
before finding any data. Maybe it only checks a little bit?=20

ReiserFS disk nr 3 (should have been 2 but ...!):
On reiserfs I could not mount the partition after the nr. 3 disk (last =
of
three) was gone. Not even fsck.reiserfs could remedy this. Only the =
"bread:
Cannot read the block (1702001): (Input/output error)" was reported. =
Silly
file system!=20

ReiserFS disk nr 1:
I did the same (remove nr. 1 disk) with reiserfs also and got similar
results. Have tried the "fsck.reiserfs --rebuild-tree", "fsck.reiserfs
--rebuild-sb" but all just reports (Input/output error). So I cannot get =
It
working again. Reiserfs just isn't there with error correction I think.=20

Conclusion:
Well my conclusion is that the data is saveable as long as we have the =
first
disk operative as long as you choose ext2/3 as the file system. Then we =
can
fix the FS to a working volume again, but we need to be able to remove =
or
replace the placeholder. I would guess fsck would then just update the =
inode
table and not report i/o errors.=20

Now I am wondering whether to take the chance, or not. If I take the =
chance
then I need to set up AES-loop encryption. This will be cool to! :)

-Don