From: Lars Marowsky-Bree <lmb@suse.de> To: Matt Domsch <Matt_Domsch@dell.com>, Neil Brown <neilb@cse.unsw.edu.au> Cc: Scott Long <scott_long@adaptec.com>, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: Proposed enhancements to MD Date: Fri, 16 Jan 2004 10:24:47 +0100 [thread overview] Message-ID: <20040116092447.GF22417@marowsky-bree.de> (raw) In-Reply-To: <20040115155221.A31378@lists.us.dell.com> On 2004-01-15T15:52:21, Matt Domsch <Matt_Domsch@dell.com> said: > * Solution works in both 2.4 and 2.6 kernels > - less ideal of two different solutions are needed Sure, this is important. > * RAID 0,1 DDF format > * Bootable from degraded R1 We were looking at extending the boot loader (grub/lilo) to have additional support for R1 & multipath. (ie, booting from the first drive/path in the set where a consistent image can be read.) If the BIOS supports DDF too, this would get even better. For the boot drive, this is highly desireable! Do you know whether DDF can also support simple multipathing? > * Boot from degraded RAID1 requires setup method early in boot > process, either initrd or kernel code. This is needed with DDF too; we need to parse the DDF data somewhere afterall. > From what I see about md: > * RAID 0,1 there today, no DDF Supporting additional metadata is desireable. For 2.6, this is already in the code, and I am looking forward to having this feature. > Am I way off base here? :-) I don't think so. But for 2.6, the functionality should go either into DM or MD, not into emd. I don't care which, really, both sides have good arguments, none of which _really_ matter from a user-perspective ;-) (If, in 2.7 time, we rip out MD and fully integrate it all into DM, then we can see further.) Sincerely, Lars Marowsky-Brée <lmb@suse.de> -- High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs | try again. fail again. fail better. Research & Development, SUSE LINUX AG \ -- Samuel Beckett - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Lars Marowsky-Bree <lmb@suse.de> To: Matt Domsch <Matt_Domsch@dell.com>, Neil Brown <neilb@cse.unsw.edu.au> Cc: Scott Long <scott_long@adaptec.com>, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: Proposed enhancements to MD Date: Fri, 16 Jan 2004 10:24:47 +0100 [thread overview] Message-ID: <20040116092447.GF22417@marowsky-bree.de> (raw) In-Reply-To: <20040115155221.A31378@lists.us.dell.com> On 2004-01-15T15:52:21, Matt Domsch <Matt_Domsch@dell.com> said: > * Solution works in both 2.4 and 2.6 kernels > - less ideal of two different solutions are needed Sure, this is important. > * RAID 0,1 DDF format > * Bootable from degraded R1 We were looking at extending the boot loader (grub/lilo) to have additional support for R1 & multipath. (ie, booting from the first drive/path in the set where a consistent image can be read.) If the BIOS supports DDF too, this would get even better. For the boot drive, this is highly desireable! Do you know whether DDF can also support simple multipathing? > * Boot from degraded RAID1 requires setup method early in boot > process, either initrd or kernel code. This is needed with DDF too; we need to parse the DDF data somewhere afterall. > From what I see about md: > * RAID 0,1 there today, no DDF Supporting additional metadata is desireable. For 2.6, this is already in the code, and I am looking forward to having this feature. > Am I way off base here? :-) I don't think so. But for 2.6, the functionality should go either into DM or MD, not into emd. I don't care which, really, both sides have good arguments, none of which _really_ matter from a user-perspective ;-) (If, in 2.7 time, we rip out MD and fully integrate it all into DM, then we can see further.) Sincerely, Lars Marowsky-Brée <lmb@suse.de> -- High Availability & Clustering \ ever tried. ever failed. no matter. SUSE Labs | try again. fail again. fail better. Research & Development, SUSE LINUX AG \ -- Samuel Beckett
next prev parent reply other threads:[~2004-01-16 9:24 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-01-13 0:34 Proposed enhancements to MD Scott Long 2004-01-13 16:26 ` Jakob Oestergaard [not found] ` <20040113201058.GD1594@srv-lnx2600.matchmail.com> 2004-01-14 19:07 ` Jakob Oestergaard [not found] ` <20040114194052.GK1594@srv-lnx2600.matchmail.com> 2004-01-14 21:02 ` Jakob Oestergaard [not found] ` <20040114222447.GL1594@srv-lnx2600.matchmail.com> 2004-01-15 1:42 ` Jakob Oestergaard 2004-01-13 18:21 ` mutex 2004-01-13 19:05 ` Jeff Garzik 2004-01-13 19:30 ` mutex 2004-01-13 19:43 ` Jeff Garzik 2004-01-13 20:00 ` mutex 2004-01-13 20:44 ` Scott Long 2004-01-13 18:44 ` Jeff Garzik 2004-01-13 19:01 ` John Bradford 2004-01-13 19:41 ` Matt Domsch 2004-01-13 22:10 ` Arjan van de Ven 2004-01-16 9:31 ` Lars Marowsky-Bree 2004-01-16 9:31 ` Lars Marowsky-Bree 2004-01-16 9:57 ` Arjan van de Ven 2004-01-13 20:41 ` Scott Long 2004-01-13 22:33 ` Jure Pečar 2004-01-13 22:33 ` Jure Pečar 2004-01-13 22:44 ` Scott Long 2004-01-13 22:56 ` viro 2004-01-14 15:52 ` Kevin Corry 2004-01-13 22:42 ` Luca Berra 2004-01-13 22:06 ` Arjan van de Ven 2004-01-13 22:44 ` Wakko Warner 2004-01-13 22:34 ` Arjan van de Ven 2004-01-13 23:09 ` Andreas Steinmetz 2004-01-13 23:38 ` Wakko Warner 2004-01-14 16:16 ` Kevin Corry 2004-01-14 16:53 ` Kevin P. Fleming 2004-01-14 23:07 ` Neil Brown 2004-01-15 11:10 ` Norman Schmidt 2004-01-15 21:52 ` Matt Domsch 2004-01-15 21:52 ` Matt Domsch 2004-01-16 9:24 ` Lars Marowsky-Bree [this message] 2004-01-16 9:24 ` Lars Marowsky-Bree 2004-01-16 13:43 ` Matt Domsch 2004-01-16 13:56 ` Lars Marowsky-Bree 2004-01-16 14:06 ` Christoph Hellwig 2004-01-16 14:11 ` Matt Domsch 2004-01-16 14:11 ` Matt Domsch 2004-01-16 14:13 ` Christoph Hellwig 2004-01-13 3:41 Proposed Enhancements " Scott Long 2004-01-13 10:24 ` Lars Marowsky-Bree 2004-01-13 18:03 ` Scott Long 2004-01-16 9:29 ` Lars Marowsky-Bree 2004-01-13 14:19 ` Matt Domsch 2004-01-13 17:13 ` Andreas Dilger 2004-01-13 22:26 ` Andreas Dilger 2004-01-13 18:19 ` Kevin P. Fleming 2004-01-13 18:19 ` Jeff Garzik 2004-01-13 20:29 ` Chris Friesen 2004-01-13 20:35 ` Matt Domsch 2004-01-13 21:10 ` Matt Domsch 2004-01-13 19:59 Proposed enhancements " Cress, Andrew R
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040116092447.GF22417@marowsky-bree.de \ --to=lmb@suse.de \ --cc=Matt_Domsch@dell.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-raid@vger.kernel.org \ --cc=neilb@cse.unsw.edu.au \ --cc=scott_long@adaptec.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.