Hi Neil
Just wondering what the status is here - do you need any more from me or is it
on your stack?
The patch helped but didn't cure.
After a clean boot it mounted correctly first try.
Then I unmounted, stopped and re-assembled the array.
The next mount failed.
The subsequent mount succeeded.
On Monday May 7, [EMAIL PROTECTED] wrote:
Hi Neil
Just wondering what the status is here - do you need any more from me or is it
on your stack?
The patch helped but didn't cure.
After a clean boot it mounted correctly first try.
Then I unmounted, stopped and re-assembled the array.
The
Neil Brown wrote:
This problem is very hard to solve inside the kernel.
The partitions will not be visible until the array is opened *after*
it has been created. Making the partitions visible before that would
be possible, but would be very easy.
I think the best solution is Mike's
Mike Accetta wrote:
David Greaves writes:
...
It looks like the same (?) problem as Mike (see below - Mike do you have a
patch?) but I'm on 2.6.20.7 with mdadm v2.5.6
...
We have since started assembling the array from the initrd using
--homehost and --auto-update-homehost which takes a
David Greaves wrote:
currently recompiling the kernel to allow autorun...
Which of course won't work because I'm on 1.2 superblocks:
md: Autodetecting RAID arrays.
md: invalid raid superblock magic on sdb1
md: sdb1 has invalid sb, not importing!
md: invalid raid superblock magic on sdc1
md:
Neil Brown wrote:
This problem is very hard to solve inside the kernel.
The partitions will not be visible until the array is opened *after*
it has been created. Making the partitions visible before that would
be possible, but would be very easy.
I think the best solution is Mike's
On Tuesday April 24, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
This problem is very hard to solve inside the kernel.
The partitions will not be visible until the array is opened *after*
it has been created. Making the partitions visible before that would
be possible, but would be very
On Tuesday April 24, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
This problem is very hard to solve inside the kernel.
The partitions will not be visible until the array is opened *after*
it has been created. Making the partitions visible before that would
be possible, but would be very
Neil Brown wrote:
On Tuesday April 24, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
This problem is very hard to solve inside the kernel.
The partitions will not be visible until the array is opened *after*
it has been created. Making the partitions visible before that would
be possible, but
Neil Brown wrote:
On Tuesday April 24, [EMAIL PROTECTED] wrote:
Neil, isn't it easy to just do this after an assemble?
Yes, but it should not be needed, and I'd like to understand why it
is.
One of the last things do_md_run does is
mddev-changed = 1;
When you next open /dev/md_d0,
Neil Brown wrote:
Yes, but it should not be needed, and I'd like to understand why it
is.
One of the last things do_md_run does is
mddev-changed = 1;
When you next open /dev/md_d0, md_open is called which calls
check_disk_change().
This will call into md_fops-md_media_changed which will
Hi Neil
I think this is a bug.
Essentially if I create an auto=part md device then I get md_d0p? partitions.
If I stop the array and just re-assemble, I don't.
It looks like the same (?) problem as Mike (see below - Mike do you have a
patch?) but I'm on 2.6.20.7 with mdadm v2.5.6
FWIW I
David Greaves writes:
...
It looks like the same (?) problem as Mike (see below - Mike do you have a
patch?) but I'm on 2.6.20.7 with mdadm v2.5.6
...
We have since started assembling the array from the initrd using
--homehost and --auto-update-homehost which takes a different path through
the
This problem is very hard to solve inside the kernel.
The partitions will not be visible until the array is opened *after*
it has been created. Making the partitions visible before that would
be possible, but would be very easy.
I think the best solution is Mike's solution which is to simply
In setting up a partitioned array as the boot disk and using a nash
initrd to find the root file system by volume label, I see a delay in
the appearance of the /dev/md_d0p partitions in /proc/partitions. When
the mdadm --assemble command completes, only /dev/md_d0 is visible.
Since the raid
15 matches
Mail list logo
