Re: [Evms-devel] EVMS and Drive Linking

[Kevin C. <kev...@us...>]

On Thursday 05 June 2003 05:59, Stian B. Barmen wrote:
>
> 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.
>
> 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.

Don,

Do you think DriveLinking can be updated to allow replacing a missing child 
with another available object? It would basically be a replace without 
copying the data.


> 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?

Yeah...it would be interesting to see how it reacts to just a blank disk in 
that place, instead of the placeholder that always returns I/O errors.

> 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!
>
> 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.
>
> 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.
>
> 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! :)

Interesting results. Not very suprising that the filesystems are basically 
toast if the first disk is lost. I was a bit suprised that ext3 survived 
losing the middle disk.

-- 
Kevin Corry
kev...@us...
http://evms.sourceforge.net/