This problem is probably a rehash, but here goes:
I have three disks in a RAID 5 volume. For some reason, now
when I boot, I get the following:
Mar 14 21:18:57 shadow kernel: md: superblock update time inconsistency
-- using the most recent one
Mar 14 21:18:
have seen this problem since the first 2.0.36 patches. i usually make the arrays
with the part. type set to 83, then WITHOUT rebooting, i setup the fs, move the
data, THEN fdisk again, change part. type to fd. then i reboot. this has worked
on a couple boxes, 2.2.1, and 2.0.36. another alternativ
Hi,
thanks to Jakobs really helpful HOWTO I managed to set up
a well-working RAID1 based on the 990309-edition, inklusive
RAID1 of the boot partion. However, smaller problems remain:
- If you change the type of a partion to "FD", a active inode
will be kept for this partion after auto-detectio
[ I'm new to the list, so feel free to point me at TFM ... ]
I have built a Linux 2.2.2 kernel with raid0145-19990309-2.2.3 and RAIDs
0 and 1 seem to work just fine (linear seems to need a chunksize!).
With the demise of "ckraid", how can I do I "check all is well" test ?
Also, how do I say "the
Tom <[EMAIL PROTECTED]> wonders:
> Hmmm... make me wonder why VFS wasn't fixed long, long ago then.
> Tom
The story is long, like Mark SCHAEFER here mentioned.
The problem sphere consists of many parts, these include:
- Passing file offset information around; 2.0 had a 'long' (which
size de
Thanks Oliver,
I better should have a look at the documentation of the newest kernel I
use. To explain, I got two systems: one for "surfin'", one for experimental
things. The "surfin'"-sys is a 2.0.35, which documentation does'nt contain
that information.
I have looked at the 2.2.3-doc and found
Tom <[EMAIL PROTECTED]> wrote:
> Hmmm... make me wonder why VFS wasn't fixed long, long ago then.
Linus says that 64 bit words are too inefficient on i386 and that
if you want > 2 GB you should upgrade to a 64 bit architecture, such
as MIPS, Alpha or SPARC. It's the same reason which made a fig
Hi,
If you look in the devices.txt under /Documentation,
you'll see that SCSI disk devices 96-111 have major number 70 ... and
112-127 have major number 71.
So, mknod /dev/sddx b 71 240 should create the device file for the 128th
SCSI disk.
Does it answer your question ?
Olivier
> --
>