hi ya james
On Thu, 2 Feb 2006 [EMAIL PROTECTED] wrote:
> with "mdadm -As /dev/md0" - this is what
yup...
> mounter was concerned. So I ran mdadm --assemble (with --scan, IIRC), left
yup ...
> it to cook for ages,
don't use 1TB sized home dirs :-) ( which may be 12-36 hrs depending )
and hw raid isn't any faster, for those that wanna play
but there's not much options ..
> then did "mount -a". It was up and working. "df"
> showed /dev/md0 mounted, and a size in line with what I expected. Plus,
> the files that were in the 'home' directory on the root partition suddenly
> disappeared, as did my regular user's home directory!
> I assume that, having now assembled the array, I can activate it in future
if files/directories disappeared..
a) your raid is corrupt in one or more ways
b) you do have backups before the corruptions started to show
> The problem that I see is that if I want to turn on the array before the
> fsck, I need to load the SATA drivers as well, and they seem to be loading
> long after the fsck.
yeah.. why some modules is loaded afterward and fsck before assembling of
raids is a silly bug ... trivial to fix...
> What would be the disadvantages of removing the fstab entry for /dev/md0,
> and creating a script to activate and mount the array after boot? I assume
> I could do this by messing around in the /etc/init.d files.
no you activate, fsck it than than mount after its all booted
hundred ways ( sorta ) to do the mounting of the raid after its booted
> I guess it's possible to load the SATA drivers earlier and assemble the
> array before fsck,
yup.. just depends on the configs and the kernels
you can get around all of the above by simply using your own custom
kernel with built in drivers for that sata controller
- modules is for job security for those that want to
build up hours to help corps debug systems that wont boot :-)
c ya
alvin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
