Piete Brooks <Piete.Brooks@cl.cam.ac.uk> wrote: > > (please do not top post - fixing. Please take note!) > (what's "top post"ing?) The opposite of bottom posting, neither of which being apposite, let us skip over the discussion of. > >> ok so, i also do know, its performance is going to suck ! > > No, it'll be fine - merely a couple or more times slower at writing > > large streams. > > Actually, over 4 times :-( Hi Piete! It's getting on for 20 years since you wrote me a ptty straight off, without looking anything up, while sitting at the console in the lab in cam. No - it won't be. He's just writing to memory in general and he'll get the ack as fast as he usually does from that. True, the writes will take longer to complete their whole journey to disk, but that's way after he's gone home and had supper. He talks to buffers in the VMS, not the driver. > He has a 4 way mirror on hdd. > As well as having to send all date over the (same!) IDE bus 4 times, > the disk head keeps having to move between the 4 partitions :-( Yeah, I know. But he won't notice, so long as he uses the device "normally". As soon as he starts streaming to it and placing it under write pressure, and memory fills up and the VMS goes sync (see bdflush settings), THEN he'll notice, but not in normal use, if what is normal is what I think it is. Writes are async to the user. > > What's silly is that there's no point in doing it > > Not true -- there is little point. > > It will protect against un-re-vectored block faults. Yes, if his disk doesn't swap them in automatically on write (or he runs out of spares and it does). On read I'm not sure what will happen. I suppose he'll get a crc error and a fail from the read attempt, and then the partition will fault out of the array, and with luck the driver will retry on another partition. But I'm not sure from memory of the code if it DOES the retry. Common sense wuld say that the code for that has to be there, but I don't recall it. > > you get no protection against the disk disappearing > > Indeed -- which is the real use for RAID1 ... > > > It's like making 3 sets of spare housekeys, and then putting them all > > in the same keyholder as the original set, and walking around like that. > > Which has *some* use if the keys are made of very soft metal and "wear out". :-). Unfortunately he insists on using ALL the keys every time, out of a sense of completeness, so they ALL wear at the same rate. He can win only on read, which is faster if he is lucky or does it right (uh, he won't - he only wins if he can do two reads at once, and he can't, since it's all the same disk) and may be less wearing. Yes, it is less wearing on read, since the frequency of reading any particular part of the disk is only 1/4 of what it normally would be. > [ His actual problem was that he didn't realise that mkraid is brain dead, and > needs a chunk size in /etc/raidtab, even when it's not used! I showed him how > to use mdadm, and it worked ] Good! Yes, I think I recall that. Thanks very much for your intercession :-). Peter _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
