On lun, apr 24, 2006 at 07:45:27 +1000, Neil Brown wrote:
> This could signal a bad controller. If it does, then you cannot trust
> any drives.
Hi all,
just to tell the end of story, my tests, and others,[1]
confirms problema in MD+DM-crypt interaction.
It would be good to
On Mon, Apr 24, 2006 at 07:45:27AM +1000, Neil Brown wrote:
> your array isn't degraded. In this case it is (I think) very unusual
> and may not be the cause of your corruption, but you should avoid
> using the flag anyway.
thanks a lot for your time and your attention, Neil. Your support it's fas
On Sunday April 23, [EMAIL PROTECTED] wrote:
> 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 \
> --b
gelma wrote:
> first run: lot of strange errors report about impossible i_size
> values, duplicated blocks, and so on
You mention only filesystem errors, no block device related errors.
In this case, I'd say that it's more likely that dm-crypt is to blame
rather than MD.
I think you should try th
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 -
