Re: Questions about software RAID
tmp [EMAIL PROTECTED] wrote: I've read man mdadm and man mdadm.conf but I certainly doesn't have an overview of software RAID. Then try using it instead/as well as reading about it, and you will obtain a more cmprehensive understanding. OK. The HOWTO describes mostly a raidtools context, however. Is the following correct then? mdadm.conf may be considered as the replacement for raidtab. When mdadm No. Mdadm (generally speaking) does NOT use a configuration file and that is perhaps its major difference wrt to raidtools. Tt's command line. You can see for yourself what the man page itself summarises as the differences (the one about not using a configuration file is #2 of 3): mdadm is a program that can be used to create, manage, and monitor MD devices. As such it provides a similar set of functionality to the raidtools packages. The key differ ences between mdadm and raidtools are: mdadm is a single program and not a collection of pro grams. mdadm can perform (almost) all of its functions with out having a configuration file and does not use one by default. Also mdadm helps with management of the configuration file. mdadm can provide information about your arrays (through Query, Detail, and Examine) that raidtools cannot. starts it consults this file and starts the raid arrays correspondingly. No. As far as I am aware, the config file contains such details of existing raid arrays as may conveniently be discovered during a physical scan, and as such cntains only redundant information that at most may save the cost of a physical scan during such operations as may require it. Feel free to correct me! This leads to the following: Then I'll ignore it :-). Is it correct that I can use whole disks (/dev/hdb) only if I make a partitionable array and thus creates the partitions UPON the raid mechanism? Incomprehensible, I am afraid. You can use either partitions or whole disks in a raid array. As far as I can see, partitionable arrays makes disk replacements easier Oh - you mean that the partitions can be recognized at bootup by the kernel. You say I can't boot from such a partitionable raid array. Is that correctly understood? Partitionable? Or partitioned? I'm not sure what you mean. You would be able to boot via lilo from a partitioned RAID1 array, since all lilo requires is a block map of here to read the kernel image from, and either component of the RAID1 would do, and I'm sure that lilo has been altered to allow the use of both/either components blockmap during its startup routines. I don't know if grub can boot from a RAID1 array but it strikes me as likely since it would be able to ignore the raid1-ness and boot successfully just as though it were a (pre-raid-aware) lilo. Can I grow a partitionable raid array if I replace the existing disks with larger ones later? Partitionable? Or partitioned? If you grew the array you would be extending it beyond the last partition. The partition table itself is n sector zero, so it is not affected. You would presumably next change the partitions to take advatage of the increased size available. Would you prefer manual partitioned disks, even though disk replacements are a bit more difficult? I don't understand. I guess that mdadm automatically writes persistent superblocks to all disks? By default, yes? I meant, the /dev/mdX has to be formatted, not the individual partitions. Still right? I'm not sure what you mean. You mean /dev/mdXy by individual partitions? So I could actually just pull out the disk, insert a new one and do a mdadm -a /dev/mdX /dev/sdY? You might want to check that the old has been removed as well as faulted first. I would imagine it is only faulted. But it doesn't matter. The RAID system won't detect the newly inserted disk itself? It obeys commands. You can program the hotplug system to add it in autmatically. Are there some HOWTO out there, that is up-to-date and is based on RAID usage with mdadm and kernel 2.6 instead of raidtools and kernel 2.2/2.4? What there is seems fine to me if you can use the mdadm equivalents instead of raidhotadd and raidsetfaulty and raidhotremve and mkraid. The config file is not needed. Peter - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can uuid of raid array be changed?
On Mon, Apr 18, 2005 at 08:05:22PM -0500, John McMonagle wrote: Luca Berra wrote: On Sun, Apr 17, 2005 at 05:04:13PM -0500, John McMonagle wrote: Need to duplicate some computers that are using raid 1. I was thinking of just adding adding an extra drive and then moving it to the new system. The only problem is the clones will all have the same uuids. If at some later date the drives got mixed up I could see a possibilities for disaster. Not exactly likely as the computers will be in different cities. Is there a way to change the uuid if a raid array? Is it really worth worrying about? you can recreate the array, this will not damage existing data. L. Thanks I'll try it. I suspect I'll find out real quick but do you need to a --zero-superblock on all devices making the raid arrays? NO Will this damage the lvm2 superblock info? Probably a good idea to do a vgcfgback just to be safe.. NO the idea is after you cloned the drive, create a new array with the force flag and using as components the cloned disk and the magic word missing, this will create a new degraded array and won't touch any data. you can then hotadd a new drive to this array, it will fill the slot used by the missing keyword. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
Luca Berra wrote: many people find it easier to understand if raid partitions are set to 0XFD. kernel autodetection is broken and should not be relied upon. Could you clarify what is broken? I understood that it was simplistic (ie if you have a raid0 built over a raid5 or something exotic then it may have problems) but essentially worked. Could it be : * broken for complex raid on raid * broken for root devices * fine for 'simple', non-root devices 4) I guess the partitions itself doesn't have to be formated as the filesystem is on the RAID-level. Is that correct? compulsory! I meant, the /dev/mdX has to be formatted, not the individual partitions. Still right? compulsory! if you do anything on the individual components you'll damage data. 5) Removing a disk requires that I do a mdadm -r on all the partitions that is involved in a RAID array. I attempt to by a hot-swap capable controler, so what happens if I just pull out the disk without this manual removal command? as far as md is concerned the disk disappeared. I _think_ this is just like mdadm -r. i think it will be marked faulty, not removed. yep - you're right, I remember now. You have to mdadm -r remove it and re-add it once you restore the disk. So I could actually just pull out the disk, insert a new one and do a mdadm -a /dev/mdX /dev/sdY? The RAID system won't detect the newly inserted disk itself? no, think of it as flexibility. if you want you can build something using the hotplug subsystem. or: no, it would be mighty strange if the raid subsystem just grabbed every new disk it saw... Think of what would happen when I insert my camera's compact flash card and it suddenly gets used as a hot spare grin I'll leave Luca's last word - although it's also worth re-reading Peter's first words!! David one last word: never trust howtos (they should be called howidid), they have the tendency to apply to the author configuration, not yours. general documentation is far more accurate. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: via82xx driver: reporting dxs_support experience
At Sun, 17 Apr 2005 12:51:03 -0400, TJ wrote: I was using the 2.6.7 kernel without APIC or ACPI support, and the via82xx driver worked perfectly, compiled as a module, without any options. I built a new 2.6.7 kernel on the same hardware with APIC and ACPI support in the kernel, as the board supports it, and the driver did not work correctly. When sound was played, a short, 1 second long bit of the sound to be played was looped. Possibly this is the clicking noise described by some people? The driver works fine with this new kernel after adding the option dxs_support=1. I hope this interaction with ACPI and APIC sheds some light on some of the troubles with this driver. I can provide more information if anyone wants it. Please CC me, I'm not on the list. Please try dxs_support=4 and check a non-48kHz sample (e.g. normal MP3 playback). Usually, dxs_support=4 is the right value for most devices. dxs_support=1 might work on old hardwares, though. thanks, Takashi TJ Motherboard: MSI K7T266 Pro2 lspci -nv: 00:00.0 Class 0600: 1106:3099 Subsystem: 1106: Flags: bus master, medium devsel, latency 0 Memory at e000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 Class 0604: 1106:b099 Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: dfc0-dfcf Prefetchable memory behind bridge: dfa0-dfaf Capabilities: [80] Power Management version 2 00:06.0 Class 0200: 8086:100e (rev 02) Subsystem: 8086:002e Flags: bus master, 66Mhz, medium devsel, latency 96, IRQ 17 Memory at dffc (32-bit, non-prefetchable) [size=128K] Memory at dffa (32-bit, non-prefetchable) [size=128K] I/O ports at d800 [size=64] Expansion ROM at dff8 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable - 00:07.0 Class 0200: 1317:0985 (rev 11) Subsystem: 1317:0570 Flags: bus master, medium devsel, latency 96, IRQ 18 I/O ports at d400 [size=256] Memory at dfffbc00 (32-bit, non-prefetchable) [size=1K] Expansion ROM at dff6 [disabled] [size=128K] Capabilities: [c0] Power Management version 2 00:08.0 Class 0180: 105a:4d69 (rev 02) (prog-if 85) Subsystem: 105a:4d68 Flags: bus master, 66Mhz, slow devsel, latency 96, IRQ 19 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=16] Memory at dfffc000 (32-bit, non-prefetchable) [size=16K] Expansion ROM at dffe [disabled] [size=16K] Capabilities: [60] Power Management version 1 00:09.0 Class 0180: 1095:0680 (rev 01) Subsystem: 1095:0680 Flags: bus master, medium devsel, latency 96, IRQ 16 I/O ports at d000 [size=8] I/O ports at cc00 [size=4] I/O ports at c800 [size=8] I/O ports at c400 [size=4] I/O ports at c000 [size=16] Memory at dfffbb00 (32-bit, non-prefetchable) [size=256] Expansion ROM at dfe8 [disabled] [size=512K] Capabilities: [60] Power Management version 2 00:11.0 Class 0601: 1106:3074 Subsystem: 1106: Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00:11.1 Class 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: 1106:0571 Flags: bus master, medium devsel, latency 32 I/O ports at fc00 [size=16] Capabilities: [c0] Power Management version 2 00:11.5 Class 0401: 1106:3059 (rev 10) Subsystem: 4005:4710 Flags: medium devsel, IRQ 28 I/O ports at bc00 [size=256] Capabilities: [c0] Power Management version 2 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: waiting for recovery to complete
On Sun, Apr 17, 2005 at 10:49:14AM -0700, Tim Moore wrote: Hi, The recovery daemon adjusts reconstruction speed dynamically according to available system resources. Disk I/O is somewhat slower but works just fine. You don't have to wait. So I don't have to wait to take the disk out, as the recovery will continue with embedded disk battery and wireless bus connection? How cool... ;-) Well... more seriously, I can't believe this question doesn't raise any interest, even if it seems like it does not. :-( Does everyone really type cat /proc/mdstat from time to time?? How clumsy... I just want to chat about the best way to add a backend for this kind of feature, so we could implement that properly... (and yes, that is definitely _nedded_ if you want to do things right) Herve Hervé Eychenne wrote: Hi, Suppose I'm waiting for a recovery to be completed, and want to run a command afterwards (halt, send a mail, or anything else...). The most practiacl way I can see is to check /proc/mdstat. But what if I want to do that automatically (without bothering looking at it manually from time to time)? For example, one could do: # while cat /proc/mdstat | grep recovery /dev/null ; do sleep 5 ; done But that's quite ugly, as: - it's an active polling, and it is time consuming (even if slightly) - it may even be unreliable, as I guess one cannot ensure that /proc/mdstat will print the recovery string during the (very short, but well...) transition between two partitions to recover I think that a passive wait would be much better instead. And ideally, we should have a simple and efficient way to let a program know if a device is in a clean state (or being recovered), and another that would wait until the device is clean (recovery finished). So, the while loop could be replaced by something like mdadm --recovery-wait(for example) which would exit only when all pending recoveries have finished, and let the script continue. That would be much practical, reliable, and cleaner than a loop, don't you think? How this could be achieved is another question... probably the best would be that userspace can select on a file descriptor, or something like that (netlink device?) What do you think? Hervé Hervé -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
Devid wrote: 5) Removing a disk requires that I do a mdadm -r on all the partitions that is involved in a RAID array. I attempt to by a hot-swap capable controler, so what happens if I just pull out the disk without this manual removal command? as far as md is concerned the disk disappeared. I _think_ this is just like mdadm -r. i think it will be marked faulty, not removed. yep - you're right, I remember now. You have to mdadm -r remove it and re-add it once you restore the disk. First you have to look if there are partitions on that disk to which no data was written since the disk failed (this typically concerns the swap partition). These partitions have to be marked faulty by hand using mdadm -f before you can remove them with mdadm -r. If you have scsi-disks you have to use the following command to take it out off the kernel after removing a faulty disk: echo scsi remove-single-device h.c.i.l /proc/scsi/scsi So I could actually just pull out the disk, insert a new one and do a mdadm -a /dev/mdX /dev/sdY? The RAID system won't detect the newly inserted disk itself? or: no, it would be mighty strange if the raid subsystem just grabbed every new disk it saw... Think of what would happen when I insert my camera's compact flash card and it suddenly gets used as a hot spare grin But if the new disk contains any RAID information and partitions on it then after spinning it up with something like echo scsi add-single-device h.c.i.l /proc/scsi/scsi the RAID system immediately tries to activate those incomming array(s). We had this yesterday on a SuSE 9.3 system. So be carefull walking with used disks from one system to another (this szenario is discussed actually in a parallel thread under topic ... uuid...). no, think of it as flexibility. if you want you can build something using the hotplug subsystem. We tried to build something like a hotplug system :-). Our hardware supports this but in a ratio of 1:10 the kernel (actually 2.6.11-4) crashes when there is activity on that controller while spinning up the new disk. We hoped the system would survive with the remaining (second) controller and the part of the mirrors (RAID1) attached to it but it fails in ca. 10% of our attempts. So till now we weren't lucky to build up a system based on software-raid with no downtime in case of a disk failure. But may be this problem is more related to SCSI than to sw-raid... Bernd Rieke - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: waiting for recovery to complete
Hervé Eychenne wrote: On Sun, Apr 17, 2005 at 10:49:14AM -0700, Tim Moore wrote: The recovery daemon adjusts reconstruction speed dynamically according to available system resources. Disk I/O is somewhat slower but works just fine. You don't have to wait. So I don't have to wait to take the disk out, as the recovery will continue with embedded disk battery and wireless bus connection? How cool... ;-) Your original phrasing looked (to me too) like you thought you couldn't use the raid whilst it was reconstructing (I'm still not convinced you realise this so, to be clear: whilst mdadm is rebuilding the array you can use the array as normal with no risk of data corruption. You do _not_ have to wait for resync to finish before remounting and using the device.) Tim's response told you you had no need to be alerted when it was OK since you had no need to stop working in the first place. (And why are you wanting to take a disk out after you just synced it? - no, don't answer that...) Now it looks like you just want to know when it's done for your own peace of mind, so... Well... more seriously, I can't believe this question doesn't raise any interest, even if it seems like it does not. :-( well, once recovery has started I don't *really* care when it finishes. Does everyone really type cat /proc/mdstat from time to time?? How clumsy... And yes, I do :) (well, actually I optimise to up arrow return) I just want to chat about the best way to add a backend for this kind of feature, so we could implement that properly... (and yes, that is definitely _nedded_ if you want to do things right) If you want to monitor _properly_ then use nagios (or monit) Or since mdadm already uses -F to follow and notify on errors, then I suggest you start hacking other alert options in there... David -- - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Don't use whole disks for raid arrays [was: Questions about software RAID]
A followup about one single question. tmp wrote: [] Is it correct that I can use whole disks (/dev/hdb) only if I make a partitionable array and thus creates the partitions UPON the raid mechanism? Just don't use whole disks for md arrays. *Especially* if you want to create partitions inside the array. Instead, create a single partition (/dev/hdb1) - you will waste the first sector on the disk, but will be much safer. The reason is trivial: Linux raid subsystem is designed to leave almost the whole underlying device from its very beginning to almost the end for the data, it stores its superblock (metadata information) at the *end* of the device (this way, you can mount eg a single component of your raid1 array without md layer at all, for recovery purposes). Whenever you will use the whole disk, /dev/hdb, for the raid arrays, or not, kernel will still look at the partition table in the disk. This table is at the very beginning of it. If md array is at the whole disk, very beginning of the disk is the same as the very beginning of the array. So, kernel may recognize something written to the start of the array as a partition table, and activate all the /dev/hdbN devices. This is especially the case when you create partitions *inside* the array (md1p1 etc) -- the same partition table (now valid one) will be seen in /dev/hdb itself *and* in /dev/md1. Now, when kernel recognized and activated partitions this way, the partitions physically will reside somewhere inside the array. For one, it is unsafe to access the partitions, obviously, and the kernel will not warn/deny your accesses. But it is worse. Suppose you're assembling your arrays by searching all devices for a superblocks. The device you want is /dev/hdb, but kernel recognized partitions on it, and now the superblock is at the end of both /dev/hdb and the last partition on it, say, /dev/hdb4 -- you're lucky if your raid assembly tools will pick up the right one... (Ok ok, the same applies to normal partitions as well: it's always ambiguous choice if your last partition is a part of a raid array, what to chooce: the last partition or the whole disk) Also suppose you will later want to boot from this drive, eg because your real boot drive failed - you will have to actually move your data off by a single sector to free the room for real partition table... To summarize: don't leave the kernel with more than one choice. It's trivial to avoid the whole issue, with some more yet unknown to me possible bad sides, by just creating a single partition on the drive and be done with it, once and forever. /mjt - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
David Greaves wrote: Luca Berra wrote: many people find it easier to understand if raid partitions are set to 0XFD. kernel autodetection is broken and should not be relied upon. Could you clarify what is broken? I understood that it was simplistic (ie if you have a raid0 built over a raid5 or something exotic then it may have problems) but essentially worked. Could it be : * broken for complex raid on raid * broken for root devices * fine for 'simple', non-root devices It works when everything works. If something does not work (your disk died, you moved disks, or esp. you added another disk from another machine wich was also a part of (another) raid array), every bad thing can happen, from just inability to assemble the array at all, to using the wrong disks/partitions, and to assembling the wrong array (the one from another machine). If it's your root device you're trying to assemble, recovery involves booting from a rescue CD and cleaning stuff up, which can be problematic at times. /mjt - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: waiting for recovery to complete
David Greaves wrote: Does everyone really type cat /proc/mdstat from time to time?? How clumsy... And yes, I do :) You're not alone.. *gah...* - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: waiting for recovery to complete
On Tue, 19 Apr 2005, Molle Bestefich wrote: David Greaves wrote: Does everyone really type cat /proc/mdstat from time to time?? How clumsy... And yes, I do :) You're not alone.. and it's still a lot better than some of the hw raid monitoring tools - more data - more info - other things we can do while waiting .. - other gui we can add around it - other alarms we can generate to prevent the raid failure c ya alvin - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
On Tue, Apr 19, 2005 at 01:00:11PM +0200, [EMAIL PROTECTED] wrote: You have to mdadm -r remove it and re-add it once you restore the disk. First you have to look if there are partitions on that disk to which no data was written since the disk failed (this typically concerns the swap partition). These partitions have to be marked faulty by hand using mdadm -f before you can remove them with mdadm -r. Ok, but how do you automate/simplify that? A script with a while loop and some grep,sed commands? A grep on what exactly? (this kind of precise information seems to be written nowhere in the manpage of the HOWTOs) Wouldn't it be much simpler if it could be possible to do something like the following? # mdadm --remove-disk /dev/sda So this command could mark as faulty and remove of the array any implied partition(s) of the disk to be removed. Does this currently exist? If not, would you be willing to integrate a patch in that sense? It would be much simpler, don't you think? Same thing for addition... # mdadm --add-disk /dev/sda would do the job quite automatically... Herve -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
Hervé Eychenne wrote: On Tue, Apr 19, 2005 at 01:00:11PM +0200, [EMAIL PROTECTED] wrote: First you have to look if there are partitions on that disk to which no data was written since the disk failed (this typically concerns the swap partition). These partitions have to be marked faulty by hand using mdadm -f before you can remove them with mdadm -r. Ok, but how do you automate/simplify that? EVMS? Or some other enterprise volume manager A script with a while loop and some grep,sed commands? A grep on what exactly? (this kind of precise information seems to be written nowhere in the manpage of the HOWTOs) You're talking about specific configs - not all sysadmins will want to do this. And those who do can type: fdisk -l /dev/sda | grep -i fd | cut -f1 -d' ' | xargs -n1 mdadm -r Wouldn't it be much simpler if it could be possible to do something like the following? # mdadm --remove-disk /dev/sda So this command could mark as faulty and remove of the array any implied partition(s) of the disk to be removed. see above 1 liner... David - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
On Tue, Apr 19, 2005 at 04:27:14PM +0100, David Greaves wrote: Hervé Eychenne wrote: On Tue, Apr 19, 2005 at 01:00:11PM +0200, [EMAIL PROTECTED] wrote: First you have to look if there are partitions on that disk to which no data was written since the disk failed (this typically concerns the swap partition). These partitions have to be marked faulty by hand using mdadm -f before you can remove them with mdadm -r. Ok, but how do you automate/simplify that? EVMS? I didn't experience this yet. By I currently have RAID1 setup with mdadm at hand, and I must deal with it... Or some other enterprise volume manager No, thanks. ;-) I prefer taking time to improve free (as a speech) tools than turning to other solutions. A script with a while loop and some grep,sed commands? A grep on what exactly? (this kind of precise information seems to be written nowhere in the manpage of the HOWTOs) You're talking about specific configs - not all sysadmins will want to do this. Of course not all sysadmins will want to do this, but that's not really the question... The question is why not provide something simple to those who want? And those who do can type: fdisk -l /dev/sda | grep -i fd | cut -f1 -d' ' | xargs -n1 mdadm -r I really don't like kludgy things like that... What if the string fd is present in another line? No, that's really ugly, sorry. Ok, maybe you'll come one day with a better command line. But then it will be too complex to remember. So you'll tell me to save it in a script. But that script will stay a bit kludgy anyway and it will not be present on any Linux box. Isn't the insertion/removal of a disk common enough to justify the addition of a simple and clean mdadm option? Herve -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
Hervé Eychenne wrote: And those who do can type: fdisk -l /dev/sda | grep -i fd | cut -f1 -d' ' | xargs -n1 mdadm -r I really don't like kludgy things like that... [...] Isn't the insertion/removal of a disk common enough to justify the addition of a simple and clean mdadm option? have you thought about the idea that there is a certain clue behind the actual behaviour of the mdadm tool? is it so annoying to you to mark a disk/partition as faulty before removing it? do you think it makes sense to implement every single case in an extra command line option? did you ever thought about switching to a hardware where you can remove and add disks without having to do anything else than pull the old one out and push teh new one in? i run several raid arrays on many machines and i find the tools quite useful. if you mind such command lines like the one above you should think about switching to a microsoft product where you can push your mouse arround and tell everyone that you can do what you want without those kludgy command lines which no one really understands. so please ask and learn. there are many people on this list which are pleased to answer your questions. the idea behind *n?x systems is to combine simple functionality through pipes and redirects to gain unlimited complexy and power. so if you want to use the full power of *n?x systems you have to get used to this kludgy command lines. the more you get used to it, the less kludgy they will be. SCNR - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about software RAID
On Tue, Apr 19, 2005 at 06:53:52PM +0200, Frank Wittig wrote: And those who do can type: fdisk -l /dev/sda | grep -i fd | cut -f1 -d' ' | xargs -n1 mdadm -r I really don't like kludgy things like that... [...] Isn't the insertion/removal of a disk common enough to justify the addition of a simple and clean mdadm option? have you thought about the idea that there is a certain clue behind the actual behaviour of the mdadm tool? is it so annoying to you to mark a disk/partition as faulty before removing it? I'm sorry, but having to do a cat /proc/mdstat, figure out by myself what to do (which partition is concerned), then type several commands (for each concerned partition) actually is painful. Maybe you are an experienced guy so it seems so simple to you... but I'm always amused when an experienced guy refuses to make things simpler for those who aren't as much as he is. And sends them to Microsoft. Great. This mailing-list is probably full of kernel guys, so maybe I should have guessed. But I come here as a user (who wants RAID to work as smoothly as possible), having found no other mailing-list (a user one) for RAID on Linux. (did I miss it?) Maybe I'm not asking questions to the right people, but for me, computer science is about automating things. And the process or replacing a crashed disk (described above) on a system managed with mdadm is not particularly automated, right? Maybe it's not a problem for _you_, because you know exactly what to do by heart. So you've forgotten the complexity. But it's there, and even if it's good that you can do complex and powerful things, it's not normal to force people to get into that complexity to do simple things. Think about it. do you think it makes sense to implement every single case in an extra command line option? I personnaly do not consider that this is yet another case. For me, RAID is about have disk availability, right? So the most common production case is definitely when one of your disks crashed, and you want to replace it. There must be some kind of way to deal with that without typing too much contextual command lines. Whether this simple way should belong to mdadm is another question, but I personnaly think it should, as it would introduce no overhead (would it, really ?) and would be very helpful. Let me reassure you, you could stay with several commands if you like. :-) did you ever thought about switching to a hardware where you can remove and add disks without having to do anything else than pull the old one out and push teh new one in? Ok, here we are... [First, the RAID controller I'm forced to deal with has no Linux driver, but that's not important for our discussion.] Software RAID is about doing the same that hardware RAID, but in soft. I think we agree on that. ;-) So I see absolutely no reason why software RAID should not be as simple as possible. And RAID management with mdadm could be made simpler for a common case like that. i run several raid arrays on many machines and i find the tools quite useful. They are. They could be even more if things were as simple as possible. if you mind such command lines like the one above you should think about switching to a microsoft product where you can push your mouse arround and tell everyone that you can do what you want without those kludgy command lines which no one really understands. so please ask and learn. You tell me to ask and learn from kernel guys who like to type command lines (I do, but I don't want to force everyone to do so). So maybe I can tell you to please learn from users who like the command line, but try to make simple things as simple as possible. there are many people on this list which are pleased to answer your questions. the idea behind *n?x systems is to combine simple functionality through pipes and redirects to gain unlimited complexy and power. so if you want to use the full power of *n?x systems you have to get used to this kludgy command lines. I don't agree with that. Using grep on vague patterns is not what I call power. Having to type several commands when one would be enough (I insist that I think we are talking about one of the most common cases) is not powerful, according to me. My motto is be as complex as possible for people who want power (you, and sometimes me), but be as simple as possible for people who just want things to be done quickly, simply, and efficiently (sometimes me, and all the others). the more you get used to it, the less kludgy they will be. Of course, but the very idea is that one shouldn't have to get used to it too much to perform simple and common actions. But I guess we'll never agree anyway... :-( Herve -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: Questions about software RAID
Hervé Eychenne wrote: Maybe you are an experienced guy so it seems so simple to you... but I'm always amused when an experienced guy refuses to make things simpler for those who aren't as much as he is. And sends them to Microsoft. Great. i don't send you to microsoft. i want you to understand the philosophy behind linux. the sort of functionality you want doesn't belong to the mdadm tool. mdadm is the command line interface to dm. more complex functionality like the one you desire is covered by frontends like EVMS. i don't know EVMS but what i heard about it sounds exactly like what you want. simple administration without having to know how things work in the background. I personnaly do not consider that this is yet another case. For me, RAID is about have disk availability, right? So the most common production case is definitely when one of your disks crashed, and you want to replace it. There must be some kind of way to deal with that without typing too much contextual command lines. after the first time you lose data because of a failure of an automated process you will think different about that. i think automation is fine for normal operation. failure of a component is far from normal and in this case full control is what you want/need. Whether this simple way should belong to mdadm is another question, but I personnaly think it should, as it would introduce no overhead (would it, really ?) and would be very helpful. KISS: keep it stupid simple this is the philosophy. keep low-level tools stupid simple. more complexity brings a higher risk of failure. we're talking about raid. not about doing backups or syncing the system clock. did you ever thought about switching to a hardware where you can remove and add disks without having to do anything else than pull the old one out and push teh new one in? Ok, here we are... [First, the RAID controller I'm forced to deal with has no Linux driver, but that's not important for our discussion.] there are some nice boxes arround. ther take a bunch of disks and appear to the host as a simple SCSI disk. had such a thing in the past. replacing disks was so simple a secretary could have done that. ;-) I don't agree with that. Using grep on vague patterns is not i think grep is far more powerfull as you think. the more you get used to it, the less kludgy they will be. Of course, but the very idea is that one shouldn't have to get used to it too much to perform simple and common actions. if replacing disks is a common case to you, you should buy your disks from a different manufacturer. ;-) and if you have so many arrays that a disk failure is common because of the number of disks, you would want to know the basics. But I guess we'll never agree anyway... :-( we're just on different levels of usage. and there's a tool for everyone on us. my tool is mdadm. and yours is EVMS or some other high level frontend which abstracts the use of the low-level tools behind a nice looking UI. greetings, Frank - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Questions about software RAID
-Original Message- From: [EMAIL PROTECTED] [mailto:linux-raid- [EMAIL PROTECTED] On Behalf Of Frank Wittig Sent: Tuesday, April 19, 2005 3:47 PM To: [EMAIL PROTECTED] Cc: linux-raid@vger.kernel.org Subject: Re: Questions about software RAID Hervé Eychenne wrote: Maybe you are an experienced guy so it seems so simple to you... but I'm always amused when an experienced guy refuses to make things simpler for those who aren't as much as he is. And sends them to Microsoft. Great. i don't send you to microsoft. i want you to understand the philosophy behind linux. the sort of functionality you want doesn't belong to the mdadm tool. mdadm is the command line interface to dm. more complex functionality like the one you desire is covered by frontends like EVMS. i don't know EVMS but what i heard about it sounds exactly like what you want. simple administration without having to know how things work in the background. I personnaly do not consider that this is yet another case. For me, RAID is about have disk availability, right? So the most common production case is definitely when one of your disks crashed, and you want to replace it. There must be some kind of way to deal with that without typing too much contextual command lines. after the first time you lose data because of a failure of an automated process you will think different about that. i think automation is fine for normal operation. failure of a component is far from normal and in this case full control is what you want/need. Whether this simple way should belong to mdadm is another question, but I personnaly think it should, as it would introduce no overhead (would it, really ?) and would be very helpful. KISS: keep it stupid simple this is the philosophy. keep low-level tools stupid simple. more complexity brings a higher risk of failure. we're talking about raid. not about doing backups or syncing the system clock. did you ever thought about switching to a hardware where you can remove and add disks without having to do anything else than pull the old one out and push teh new one in? Ok, here we are... [First, the RAID controller I'm forced to deal with has no Linux driver, but that's not important for our discussion.] there are some nice boxes arround. ther take a bunch of disks and appear to the host as a simple SCSI disk. had such a thing in the past. replacing disks was so simple a secretary could have done that. ;-) I don't agree with that. Using grep on vague patterns is not i think grep is far more powerfull as you think. the more you get used to it, the less kludgy they will be. Of course, but the very idea is that one shouldn't have to get used to it too much to perform simple and common actions. if replacing disks is a common case to you, you should buy your disks from a different manufacturer. ;-) and if you have so many arrays that a disk failure is common because of the number of disks, you would want to know the basics. But I guess we'll never agree anyway... :-( we're just on different levels of usage. and there's a tool for everyone on us. my tool is mdadm. and yours is EVMS or some other high level frontend which abstracts the use of the low-level tools behind a nice looking UI. greetings, Frank Well, I agree with KISS, but from the operator's point of view! I want the failed disk to light a red LED. I want the tray the disk is in to light a red LED. I want the cabinet the tray is in to light a red LED. I want the re-build to the spare to start. I want the operator du jour to notice the red LEDs. I want the operator to remove the failed disk. I want the operator to install the new disk. I want the re-build to the new disk to start. I want the re-build to not fail the current spare so data says redundant. I want the old spare to become the spare again. (optional) The operator would log the event: Disk xyz's LED went red, I replaced the disk, the red LED went out. In my opinion, most operators would not be able to replace a disk on a md RAID system. It is much too complex! Most operators need written procedures. They can't use independent thought to resolve problems. Also, most operators can't use vi! So, if you can use vi, you are better than most operators!!! IMO. Of course I can't have the red LED, but the disks could be labeled and an email sent saying disk xyz has failed. The operator could then replace disk xyz, if they could find it! Then another email(s) with a status update. With most (maybe all) hardware RAID systems I have used, the above is how it works. Even the red LED!!! But these are dedicated RAID systems, not off the shelf components. I don't expect a software solution to ever be as easy as hardware, but I do agree it needs to be much more operator friendly than it is today. Guy - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a
RE: Questions about software RAID - red led
On Wed, 20 Apr 2005, Guy wrote: Well, I agree with KISS, but from the operator's point of view! I want the failed disk to light a red LED. I want the tray the disk is in to light a red LED. I want the cabinet the tray is in to light a red LED. I want the re-build to the spare to start. I want the operator du jour to notice the red LEDs. I want the operator to remove the failed disk. I want the operator to install the new disk. I want the re-build to the new disk to start. I want the re-build to not fail the current spare so data says redundant. I want the old spare to become the spare again. (optional) The operator would log the event: Disk xyz's LED went red, I replaced the disk, the red LED went out. In my opinion, most operators would not be able to replace a disk on a md RAID system. It is much too complex! Most operators need written procedures. They can't use independent thought to resolve problems. if you want the above ... it is possible to do ... its just a few hardware tweeking on the drive tray ... ( trivial to do if you have access to the ide disk tray and backplane ) operator du jour does NOT need to do anyting ... software raid can detect or be told that a disk went bad and it will rebuild itself after the drive tray is removed and replaced with the same disk or different disk - think usb .. you plug it in .. it comes up - think cdrom .. you put it in .. it comes up - think new disk tray .. you plug it in .. it comes up - the bigger problem .. - disks should NOT be dying in the first place and yup.. building customizations is the fun part c ya alvin - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
