On Mon, 6 Nov 2006, Neil Brown wrote:
So it looks like you machine recently crashed (power failure?) and it is
restarting.
Or upgrade some part of the OS and now it'll do resync every week or so (I
think this is debian default nowadays, don't know the interval though).
--
Mikael
On Mon, 6 Nov 2006, Mikael Abrahamsson wrote:
On Mon, 6 Nov 2006, Neil Brown wrote:
So it looks like you machine recently crashed (power failure?) and it is
restarting.
Or upgrade some part of the OS and now it'll do resync every week or so (I
think this is debian default nowadays,
On Mon, 6 Nov 2006, Neil Brown wrote:
hey i have another related question... external bitmaps seem to pose a bit
of a chicken-and-egg problem. all of my filesystems are md devices. with
an external bitmap i need at least one of the arrays to start, then have
filesystems mounted, then
On Mon, 6 Nov 2006, James Lee wrote:
Thanks for the reply Dean. I looked through dmesg output from the
boot up, to check whether this was just an ordering issue during the
system start up (since both evms and mdadm attempt to activate the
array, which could cause things to go wrong...).
On Mon, 6 Nov 2006, Neil Brown wrote:
This creates a deep disconnect between udev and md.
udev expects a device to appear first, then it created the
device-special-file in /dev.
md expect the device-special-file to exist first, and then created the
device on the first open.
could you create
On Mon, 6 Nov 2006, dean gaudet wrote:
it should be only once a month... and it's just a check -- it reads
everything and corrects errors.
If you have a recent enough kernel, yes. I used 2.6.15 and it would
actually rebuild, I think it was 2.6.16 that does correct read and
compare.
i
Hi!
If there's a swap file on a software RAID, it should be possible to use
this
file for saving the swsusp's suspend image. Also, this file should be
available to the memory management subsystem when memory is being freed
before
the suspend image is created.
For the
On 6 Nov 2006, Thomas Andrews uttered the following:
Thanks Neil, I fixed my problem by creating the raid set using the -e
option:
mdadm -C /dev/md0 -e 0.90 --level=raid1 --raid-devices=2 /dev/sda1
/dev/sdb1
You're suggestion to use mdadm to assemble the array is not an option
for me
On 06/11/06, dean gaudet [EMAIL PROTECTED] wrote:
On Mon, 6 Nov 2006, James Lee wrote:
Thanks for the reply Dean. I looked through dmesg output from the
boot up, to check whether this was just an ordering issue during the
system start up (since both evms and mdadm attempt to activate the
On Sunday November 5, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
On Saturday November 4, [EMAIL PROTECTED] wrote:
Hi,
I'm setting up a raid 5 system and I ran across a bug when reshaping an
array with a mounted XFS filesystem on it. This is under linux 2.6.18.2
and mdadm 2.5.5
On Monday November 6, [EMAIL PROTECTED] wrote:
On Mon, Nov 06, 2006 at 09:17:26AM +1100, Neil Brown wrote:
You mdadm to assemble the array, it is more flexible than auto-detect.
Thanks Neil, I fixed my problem by creating the raid set using the -e
option:
mdadm -C /dev/md0 -e 0.90
On Monday November 6, [EMAIL PROTECTED] wrote:
On Mon, 6 Nov 2006, Neil Brown wrote:
This creates a deep disconnect between udev and md.
udev expects a device to appear first, then it created the
device-special-file in /dev.
md expect the device-special-file to exist first, and then
12 matches
Mail list logo