Re: mkraid secret flag
WARNING: i am going to type the secret command in the following mail. if you
cannot handle it, delete it now. if you want a rational explanation for why i
would do that, read on. i am not trying to be inflammatory, just make a point.
i have been using software raid under linux for quite a while now. both my
current and prior employers are using software raid boxes that i have setup
over the past two+ years. some of the older ones are running kernel 2.0.3x and
the more recent ones are 2.2.x of some sort. some older ones are using the
0.4x raid code, the newer, 0.90.
with these 20 or so machines, i have found the 0.90 tools and kernel level
driver to be much more robust and user friendly. i can remember when raid had
a single mdtab, then MULTIPLE conf files, and now a single raidtab. the newer
versions, with the inclusion of things like martin bene's failed-disk patches,
has been one of the most useful pieces of software i have applied in an x86
server environment. by comparison, the 0.40 raid code, replete with initrds
and weird startup scripts looks quite pathetic.
while there is some point to protecting a user from system damage, the message
that is printed, and the command name needed to actually get the work done,
make the 0.90 code appear unstable or untested.
there are at least hundreds if not thousands of people on this list who use
linux, and linux software raid every day. this is code is stable, and it is
tested. it is bulletproof in comparison to the 0.4x code, and if mr cox has
his way, it will finally be in the main kernel.
as such, i feel it is time to rename the --really-force command from mkraid to
--force. to leave as-is, is just great ammunition for those who would slight
the efforts of the developers as incomplete or amaturish.
people know they are taking their own system into their hands. this is WHY
they are using linux, rather than an os that hides the real innards of the
system from them. the extra logic required to make them type the longer
command, however simple, just adds kruft to the binary, to print a message
that is a GIVEN when you are root on your box.
think about it! rm by default does not -i! and rm is potentially MUCH more
dangerous than mkraid. hell, we tell people on this list ALL THE TIME to run
mkraid --really-force on their EXISTING partitions: "it only overwrites the
raid superblock"! we dont tell people to fix problems with rm -rf * ! should
we go back and change rm to always be in -i mode? fdisk does not print such
messages. mke2fs on a clean partition? no.
i feel that mingo/gadi et al have done a fine job, and these utils need to
take the same approach as other system level programs- no convoluted messages
asking for non-disclosure, just the normal warning, and the five second pause.
raid 0.90 is almost grown up. it should act that way.
wow- that was longer than i intended on such a simple subject- sorry :)
allan noah
James Manning [EMAIL PROTECTED] said:
[ Wednesday, March 15, 2000 ] root wrote:
mkraid --**-force /dev/md0
/me attempts to get the Stupid Idea Of The Month award
Motivation: trying to keep the Sekret Flag a secret is a failed effort
(the number of linux-raid archives, esp. those that are searchable, make
this a given), and a different approach could help things tremendously.
*** Idea #1:
How about --force / -f look for $HOME/.md_force_warning_read and
if not exists:
- print huge warning (and beep thousands of times as desired)
- creat()/close() the file
if exists:
- Do the Horrifically Dangerous stuff
Benefit: everyone has to read at least once (or at a minimum create a
file that says they've read it)
Downside: adds a $HOME/ entry, relies on getenv("HOME"), etc.
*** Idea #2:
--force / -f prints a warning, prompts for input (no fancy term
tricks), and continues only on "yes" being entered (read(1,..) so
we can "echo yes |mkraid --force" in cases we want it automated).
Benefit: warning always generated
Downside: slightly more complicated to script
Both are fairly trivial patches, so I'll be glad to generate the
patch for whichever (if either :) people seem to like.
James
Re: raid parity and mmx processor
As I understand it, the kernel tests parity calc speed and decides to use/not use mmx based on which is faster. Assuming an otherwise heavily loaded cpu, would it not be better to use mmx even though slightly slower just to free up cpu cycles for other tasks. If you are doing the calculations faster, it takes shorter time before the CPU is free to do other things. Fastest is fastest. Hmmm not really, if so, why would we have multi-processor systems. mmx is a distinct processor apart from the fpp or main cpu. It is possible for all to be doing separate operations at the same time. i.e. gzip, raid parity, network traffic untrue. mmx is NOT a separate entity within an intel cpu. go read the data sheets for any mmx intel cpu. or even better, go read the simd article at www.arstechnica.com mmx, due to its cheap, hackish nature, re-uses the fpu registers. you cannot do an mmx instruction followed by an fpu instruction in the same program without a painful context switch. this is not an issue with other processes on the system, however, since you are going to have some task switching anyway when you go from the raid parity code back to a userland piece of code and so on. there is always the debate as well about how well your compiler/kernel will order your instructions/schedule your procs so that different functional units within the cpu keep their pipelines full. afaik, it is better to just write fast code and get it out of the way of the other procs asap, than try to get two different procs to execute two different instruction sets on the same cpu at the same time. allan If I don't have the right picture here, someone please provide an explaination of where the cpu cycles go to raid. This reason for my question is the amount of "nice" cycles on one of my machines that is fairly busy. Only raid5d is niced, and I'm running a load factor over one consistently with only about a 20% cpu load. It appears most of the cpu cycles in use go to raid5 -- presumably parity calculations. What kinda disks are you running on? SCSI? IDE? If IDE, do you have all nice things such as DMA transfers enabled? IDE 33 +dma Assuming I'm not too far off base, it would be nice to have a /proc option or at least a compile option to force use of mmx for raid parity and a way to run the parity calculation test manually to see the difference between the two methods. Maybe not for speed, but for bug tracing. Anyway, that would be good.
Re: Unofficial patch for kernel-2.2.10
do not use this patch. it does not seem to contain the priority fixes which are needed to use raid1-5 under a kernel higher than 2.2.7. this patch will likely _NOT_SYNC_ your raid arrays. you have been warned :) allan "Theron J.Lewis" [EMAIL PROTECTED] said: You can find my hacked patch raid0145-19990421-2.2.10.gz with an explaination on how I generated it at the following URL: http://nspace.cs.ucsb.edu/linux-raid/ I make no guarentees reguarding it's reliability or correctness, although it is working fine for my raid level 0 partition. Download it at your own risk. Have fun. -Theron [EMAIL PROTECTED]
Re: backup/redundancy solutions
bad call. i NEVER backup unix via smb. go and restore from that backup and look at your unix permissions. unless you tar first, perms are destroyed by smb. i use a backup server running linux. the nt boxes can dump to it using smb, the unix boxes use nfs v3, and the backup server takes care of the rest. this good cause it gives me a running machine, a harddrive backup, and a tape backup all with the correct full unix perms. allan Steve McPherson [EMAIL PROTECTED] said: We do the same thing here. Linux is set up to talk to NT through SAMBA. The NT server is running the Backup Exec. The Linux server backs up along with everything else. Dirk Petry [EMAIL PROTECTED] 07/08/99 10:57AM Dear Tony, our system manager here just dumps all data from a large mixed LAN on a 70 GB DLT using Seagate Backup Exec running on an NT server. It seems to work pretty well. Typical data transfer speed is 3.5 MB/s. Best regards, Dirk -- -- Dirk Petryemail: [EMAIL PROTECTED] Institut de Fisica d'Altes Energies (IFAE), Edificio Cn, Universitat Autonoma de Barcelona, 08193 Bellaterra, Spain Fax: +34-93581-1938Phone: +34-93581-2833 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: aic7890 or 53c875?
i have 875's 825's, 810's, and 896's and several aic788x boards. the adaptecs are onboard and true adaptec brand cards. the NCR's are Symbios, Compaq, ASUS, and Tekram boards. i will replace those adaptecs with NRC's every time i get a chance. the cable problems with AIC's are so bad, esp. with external cases that you HAVE to have granite's cables. and still no guarantees. my NCR's on the other hand, NEVER give me any trouble. even the ancient 810's integrated into compaqs. we get so much crap on this list from people with adaptec's that timeout when they do something, and declare it is the raid code. i can tell you i have pulled drives out of ncr machines during file ops that are hitting the disk, and not so much as a peep. the AIC's will choke. NCR all the way. (diamond fireport is a nice version. spend your 60 bucks on another controller.) thats my .02 allan "C. R. Oldham" [EMAIL PROTECTED] said: Greetings, I'm about to move several disks out of an Asus T-10 case into an external enclosure because they are running pretty hot. The motherboard in the case has an onboard Adaptec 7890 SCSI adapter and I also installed an Asus SC-875 to drive an external tape unit and a CD-RW. I'm looking at cases from Granite Digital, and they will make me a custom cable to hook the Adaptec to the backplate. The cable is $60. I can save that by moving the drives off onto the 53c875 controller, which already has a 68-pin external port on the back of it, but I'm not sure which controller is the better one. Do some people with experience with both controllers have any comment on which one I should use to drive my RAID? The drives in question are actually U2W drives, but it was my understanding that the aic78xx driver doesn't yet support the 80MB/s transfer rates. True, or not? Thanks! -- | Charles R. (C. R.) Oldham | NCA Commission on Schools| | [EMAIL PROTECTED] | Arizona St. Univ., PO Box 873011,| | V:602/965-8700 F:602/965-9423 | Tempe, AZ 85287-3011 _ | | "I like it!"--Citizen G'Kar | #include disclaimer.h X_|
Re: Newbie: What to do when a disk fails?
I suspect thst I could have done something like this: 1. Remove the failed disk. 2. Insert a new one 3. Boot with only one disk set up for raid usage. 4. Use fdisk to get the partition table right. 5. Reboot to get linux to recognize the new partition 6. Use raidhotadd toadd the empty partition to the existing raid-1. you hit the nail on the head man. no need to copy things to the replacement disk. just get the partition table right and readable by linux (requires the reboot in 5). then use raidhotadd. sweet, huh? thanks to mingo, martin bene, et al. allan
