Hi all,
to make a long story very very shorty:
a) I create /dev/md1, kernel latest rc-2-git4 and mdadm-2.4.1.tgz,
with this command:
/root/mdadm -Cv /dev/.static/dev/.static/dev/.static/dev/md1
--bitmap-chunk=1024 --chunk=256 --assume-clean --bitmap=internal -l5 -n5
/dev/hda2 /dev/hdb2 /dev/hde2 /dev/hdf2 missing
b) dm-encrypt /dev/md1
c) create fs with:
mkfs.ext3 -O dir_index -L 'tritone' -i 256000 /dev/mapper/raidone
d) export it via nfs (mounting /dev/mapper/raidone as ext2)
e) start to cp-ing files
f) after 1 TB of written data, with no problem/warning, one of the
not-in-raid-array HD freeze
g) reboot, check with:
fsck -C -D -y /dev/mapper/raidone
a) first run: lot of strange errors report about impossible
i_size values, duplicated blocks, and so on, but it ends without
complain, saying everything is fixed.
b) mount it (as ext3), everything, at first glance, seems good
(I will check checksum tomorrow) as
number/size/filename/directory place of files. In /lost+found
some files, but nothing "real". I mean, special files/devices,
that never were on that fs, with giga/tera size (holes, of
course), with chattr bits randomly setted.
when I try to remove them I've got a kernel complain about
offset in dir /lost+found.
c) fsck again, after everything is fine
Now the cloning from old storage is going on, and now I'm wondering
if "--assume-clean" could be the reason of what happens.
btw, hardware passed usual test (memtest, cpuburn, ecc).
thanks a lot for your time and sorry for my terrible english,
gelma
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
