diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20130305')
12 files changed, 114 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20130305/2d3f7c1d/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130305/2d3f7c1d/attachment-0001.html new file mode 100644 index 000000000..938f25325 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/2d3f7c1d/attachment-0001.html @@ -0,0 +1,10 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 11:11 AM, Colin Guthrie <span dir="ltr"><<a href="mailto:mageia@colin.guthr.ie" target="_blank">mageia@colin.guthr.ie</a>></span> wrote:<br> +<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anything that relies on ordering is just broken by design. We need to<br> +handle things gracefully regardless of the order they are detected. This<br> +is why UUIDs are the defacto method for filesystem identification these<br> +days and why in mga4 we'll likely switch to a consistent naming scheme<br> +for networking devices too.<br></blockquote><div><br>Yes, I understand that cryptic-looking UUIDs are the defacto identifiers but when mdadm reports that /dev/sdf1 has failed in a parity RAID +setup, it will be good if a mere mortal can know which drive to replace. :o)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +Also "modprobe ordering" is increasingly not true either as many modules<br> +are automatically loaded when the hardware is present.<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, but it is possible to override the automatic loading...which is why I like the modular approach.<br> +<br></div><div>Now that I understand the reasons for going back to statically compiled drivers, I'm OK with rolling my own.<br></div><div><br></div><div>Thanks -- RJ<br><br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/2d3f7c1d/attachment.html b/zarb-ml/mageia-dev/attachments/20130305/2d3f7c1d/attachment.html new file mode 100644 index 000000000..938f25325 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/2d3f7c1d/attachment.html @@ -0,0 +1,10 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 11:11 AM, Colin Guthrie <span dir="ltr"><<a href="mailto:mageia@colin.guthr.ie" target="_blank">mageia@colin.guthr.ie</a>></span> wrote:<br> +<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anything that relies on ordering is just broken by design. We need to<br> +handle things gracefully regardless of the order they are detected. This<br> +is why UUIDs are the defacto method for filesystem identification these<br> +days and why in mga4 we'll likely switch to a consistent naming scheme<br> +for networking devices too.<br></blockquote><div><br>Yes, I understand that cryptic-looking UUIDs are the defacto identifiers but when mdadm reports that /dev/sdf1 has failed in a parity RAID +setup, it will be good if a mere mortal can know which drive to replace. :o)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +Also "modprobe ordering" is increasingly not true either as many modules<br> +are automatically loaded when the hardware is present.<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, but it is possible to override the automatic loading...which is why I like the modular approach.<br> +<br></div><div>Now that I understand the reasons for going back to statically compiled drivers, I'm OK with rolling my own.<br></div><div><br></div><div>Thanks -- RJ<br><br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/326063bf/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130305/326063bf/attachment-0001.html new file mode 100644 index 000000000..56d0ade94 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/326063bf/attachment-0001.html @@ -0,0 +1,15 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 12:19 PM, Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org" target="_blank">tmb@mageia.org</a>></span> wrote:<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +<br> +If you follow raid devel list you will soon learn that they dont recommend trusting the /dev/sd* naming either as it is by<br> +no means static... :)<br> +<br> +depending on your hw, they may for example hange place if you happend<br> +to have a usb disk plugged at boot and so on.<br> +<br> +so the thing to check is for example what disk is mapped as /dev/disk/by-id/*<br> +<br> +<br> +where you can match on actual disc serial number and so on...<br> +then you can be sure wich disk is failing / has failed..</blockquote><div><br></div><div>Great advice. I'll make sure the drive's serial numbers are visible without removal and then use ls /dev/disk/by-id/ to make sure I get the right one, if/when the time ever comes...<br> +<br></div><div>Thanks again -- RJ<br><br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/326063bf/attachment.html b/zarb-ml/mageia-dev/attachments/20130305/326063bf/attachment.html new file mode 100644 index 000000000..56d0ade94 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/326063bf/attachment.html @@ -0,0 +1,15 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 12:19 PM, Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org" target="_blank">tmb@mageia.org</a>></span> wrote:<br> +<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +<br> +If you follow raid devel list you will soon learn that they dont recommend trusting the /dev/sd* naming either as it is by<br> +no means static... :)<br> +<br> +depending on your hw, they may for example hange place if you happend<br> +to have a usb disk plugged at boot and so on.<br> +<br> +so the thing to check is for example what disk is mapped as /dev/disk/by-id/*<br> +<br> +<br> +where you can match on actual disc serial number and so on...<br> +then you can be sure wich disk is failing / has failed..</blockquote><div><br></div><div>Great advice. I'll make sure the drive's serial numbers are visible without removal and then use ls /dev/disk/by-id/ to make sure I get the right one, if/when the time ever comes...<br> +<br></div><div>Thanks again -- RJ<br><br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/72339886/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130305/72339886/attachment-0001.html new file mode 100644 index 000000000..726380041 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/72339886/attachment-0001.html @@ -0,0 +1,6 @@ +<div dir="ltr"><div><div><div><div>I remember when PATA (IDE) drivers were statically compiled into the kernel, then we went to modular IDE which I liked because modprobe ordering could be controlled. (When dealing with parity RAID, its nice to have logical drive enumeration because SATA ports don't have UUID labels.)<br> +<br>But now it seems we've come full circle:<br><br>[root@localhost ~]# grep SATA_AHCI /boot/config-3.8.1-desktop-1.mga3<br>CONFIG_SATA_AHCI=y<br>CONFIG_SATA_AHCI_PLATFORM=y<br><br></div>Is there a compelling reason to do this (other than AHCI is popular)?<br> +<br></div>I'm putting together a home-brewed a file server using an old motherboard plus a couple of add-in SATA controllers. With the Mageia stock kernel, the enumeration looks like:<br><br></div><div>sda = RAID disk 08 (ahci)<br> +</div><div>sdb = RAID disk 09 (ahci)</div><div>sdc = RAID disk 10 (ahci)</div><div>sdd = RAID disk 11 (ahci)<br><div>sde = Mageia OS (sata_nv) (1st port on mobo)<br></div><div>sdf = RAID disk 01 (sata_nv)</div><div>sdg = RAID disk 02 (sata_nv)</div> +<div>sdh = RAID disk 03 (sata_nv)</div></div><div>sdi = RAID disk 04 (sata_sil)</div><div>sdj = RAID disk 05 (sata_sil)</div><div>sdk = RAID disk 06 (sata_sil)</div><div>sdl = RAID disk 07 (sata_sil)</div><br><div></div>Of course its no problem to re-compile the kernel with AHCI as a module so I can modprobe it last. Just wondering why AHCI is now the exception to modular sata...?<br> +<br></div>Thanks -- RJ<br><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/72339886/attachment.html b/zarb-ml/mageia-dev/attachments/20130305/72339886/attachment.html new file mode 100644 index 000000000..726380041 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/72339886/attachment.html @@ -0,0 +1,6 @@ +<div dir="ltr"><div><div><div><div>I remember when PATA (IDE) drivers were statically compiled into the kernel, then we went to modular IDE which I liked because modprobe ordering could be controlled. (When dealing with parity RAID, its nice to have logical drive enumeration because SATA ports don't have UUID labels.)<br> +<br>But now it seems we've come full circle:<br><br>[root@localhost ~]# grep SATA_AHCI /boot/config-3.8.1-desktop-1.mga3<br>CONFIG_SATA_AHCI=y<br>CONFIG_SATA_AHCI_PLATFORM=y<br><br></div>Is there a compelling reason to do this (other than AHCI is popular)?<br> +<br></div>I'm putting together a home-brewed a file server using an old motherboard plus a couple of add-in SATA controllers. With the Mageia stock kernel, the enumeration looks like:<br><br></div><div>sda = RAID disk 08 (ahci)<br> +</div><div>sdb = RAID disk 09 (ahci)</div><div>sdc = RAID disk 10 (ahci)</div><div>sdd = RAID disk 11 (ahci)<br><div>sde = Mageia OS (sata_nv) (1st port on mobo)<br></div><div>sdf = RAID disk 01 (sata_nv)</div><div>sdg = RAID disk 02 (sata_nv)</div> +<div>sdh = RAID disk 03 (sata_nv)</div></div><div>sdi = RAID disk 04 (sata_sil)</div><div>sdj = RAID disk 05 (sata_sil)</div><div>sdk = RAID disk 06 (sata_sil)</div><div>sdl = RAID disk 07 (sata_sil)</div><br><div></div>Of course its no problem to re-compile the kernel with AHCI as a module so I can modprobe it last. Just wondering why AHCI is now the exception to modular sata...?<br> +<br></div>Thanks -- RJ<br><br></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/8682f172/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130305/8682f172/attachment-0001.html new file mode 100644 index 000000000..f663e8de5 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/8682f172/attachment-0001.html @@ -0,0 +1,12 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 12:54 PM, AL13N <span dir="ltr"><<a href="mailto:alien@rmail.be" target="_blank">alien@rmail.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +Op dinsdag 5 maart 2013 20:10:20 schreef Thomas Backlund:<br> +[...]<br> +<div class="im">> For servers (& bigger workstations) where you rely on SCSI / SAS / FC /<br> +> .... you still need initrds, and usually you dont really care if a<br> +> boot take a little longer.<br> +<br> +</div>does this mean that AHCI is enabled only for desktop kernels?<br></blockquote><div><br></div><div>AHCI is definitely enabled for all kernels.<br></div><div>Its also statically compiled into all kernels as well:<br> +</div><div><br></div><div><div># cd /usr/src/linux-3.8.1-1.mga3/arch/x86/configs<br></div># grep SATA_AHCI *<br><br>i386_defconfig:CONFIG_SATA_AHCI=y<br>i386_defconfig-desktop:CONFIG_SATA_AHCI=y<br>i386_defconfig-desktop:CONFIG_SATA_AHCI_PLATFORM=y<br> +i386_defconfig-desktop586:CONFIG_SATA_AHCI=y<br>i386_defconfig-desktop586:CONFIG_SATA_AHCI_PLATFORM=y<br>i386_defconfig-server:CONFIG_SATA_AHCI=y<br>i386_defconfig-server:CONFIG_SATA_AHCI_PLATFORM=y<br>x86_64_defconfig:CONFIG_SATA_AHCI=y<br> +x86_64_defconfig-desktop:CONFIG_SATA_AHCI=y<br>x86_64_defconfig-desktop:CONFIG_SATA_AHCI_PLATFORM=y<br>x86_64_defconfig-server:CONFIG_SATA_AHCI=y<br>x86_64_defconfig-server:CONFIG_SATA_AHCI_PLATFORM=y<br><br></div><div>(If any were modular, they be set to 'm')<br> +<br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/8682f172/attachment.html b/zarb-ml/mageia-dev/attachments/20130305/8682f172/attachment.html new file mode 100644 index 000000000..f663e8de5 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/8682f172/attachment.html @@ -0,0 +1,12 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 12:54 PM, AL13N <span dir="ltr"><<a href="mailto:alien@rmail.be" target="_blank">alien@rmail.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +Op dinsdag 5 maart 2013 20:10:20 schreef Thomas Backlund:<br> +[...]<br> +<div class="im">> For servers (& bigger workstations) where you rely on SCSI / SAS / FC /<br> +> .... you still need initrds, and usually you dont really care if a<br> +> boot take a little longer.<br> +<br> +</div>does this mean that AHCI is enabled only for desktop kernels?<br></blockquote><div><br></div><div>AHCI is definitely enabled for all kernels.<br></div><div>Its also statically compiled into all kernels as well:<br> +</div><div><br></div><div><div># cd /usr/src/linux-3.8.1-1.mga3/arch/x86/configs<br></div># grep SATA_AHCI *<br><br>i386_defconfig:CONFIG_SATA_AHCI=y<br>i386_defconfig-desktop:CONFIG_SATA_AHCI=y<br>i386_defconfig-desktop:CONFIG_SATA_AHCI_PLATFORM=y<br> +i386_defconfig-desktop586:CONFIG_SATA_AHCI=y<br>i386_defconfig-desktop586:CONFIG_SATA_AHCI_PLATFORM=y<br>i386_defconfig-server:CONFIG_SATA_AHCI=y<br>i386_defconfig-server:CONFIG_SATA_AHCI_PLATFORM=y<br>x86_64_defconfig:CONFIG_SATA_AHCI=y<br> +x86_64_defconfig-desktop:CONFIG_SATA_AHCI=y<br>x86_64_defconfig-desktop:CONFIG_SATA_AHCI_PLATFORM=y<br>x86_64_defconfig-server:CONFIG_SATA_AHCI=y<br>x86_64_defconfig-server:CONFIG_SATA_AHCI_PLATFORM=y<br><br></div><div>(If any were modular, they be set to 'm')<br> +<br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/928982c9/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20130305/928982c9/attachment-0001.html new file mode 100644 index 000000000..ab5975692 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/928982c9/attachment-0001.html @@ -0,0 +1,7 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 9:41 AM, Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org" target="_blank">tmb@mageia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +<div class="im"> +<br></div> +It's needed to be able to boot new hw without need for initrd.<br> +<br> +<a href="https://wiki.mageia.org/en/Feature:BootSansRamdisk" target="_blank">https://wiki.mageia.org/en/Feature:BootSansRamdisk</a></blockquote><div><br></div><div>Ah, I didn't know about that. It seems like the target systems will need to be simple AND have ahci compliant boot controllers. Otherwise a bunch of SATA drivers will need to be statically compiled in kinda like the old IDE days. It'll be interesting to see how many users complain because they "think" they shouldn't need an initrd... :o)<br> +<br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/928982c9/attachment.html b/zarb-ml/mageia-dev/attachments/20130305/928982c9/attachment.html new file mode 100644 index 000000000..ab5975692 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/928982c9/attachment.html @@ -0,0 +1,7 @@ +<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 5, 2013 at 9:41 AM, Thomas Backlund <span dir="ltr"><<a href="mailto:tmb@mageia.org" target="_blank">tmb@mageia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +<div class="im"> +<br></div> +It's needed to be able to boot new hw without need for initrd.<br> +<br> +<a href="https://wiki.mageia.org/en/Feature:BootSansRamdisk" target="_blank">https://wiki.mageia.org/en/Feature:BootSansRamdisk</a></blockquote><div><br></div><div>Ah, I didn't know about that. It seems like the target systems will need to be simple AND have ahci compliant boot controllers. Otherwise a bunch of SATA drivers will need to be statically compiled in kinda like the old IDE days. It'll be interesting to see how many users complain because they "think" they shouldn't need an initrd... :o)<br> +<br></div></div></div></div> diff --git a/zarb-ml/mageia-dev/attachments/20130305/ca9cd72b/attachment-0001.asc b/zarb-ml/mageia-dev/attachments/20130305/ca9cd72b/attachment-0001.asc new file mode 100644 index 000000000..46c4a6d13 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/ca9cd72b/attachment-0001.asc @@ -0,0 +1,7 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iEYEABECAAYFAlE2drMACgkQjsMgV2ARTmORXwCfcU90M6TX1vsLaw2DIZBYo+0b +ojMAnR/cvvi2QjfFyqtRYdPCGBn0H6SJ +=YHJG +-----END PGP SIGNATURE----- diff --git a/zarb-ml/mageia-dev/attachments/20130305/ca9cd72b/attachment.asc b/zarb-ml/mageia-dev/attachments/20130305/ca9cd72b/attachment.asc new file mode 100644 index 000000000..46c4a6d13 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20130305/ca9cd72b/attachment.asc @@ -0,0 +1,7 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iEYEABECAAYFAlE2drMACgkQjsMgV2ARTmORXwCfcU90M6TX1vsLaw2DIZBYo+0b +ojMAnR/cvvi2QjfFyqtRYdPCGBn0H6SJ +=YHJG +-----END PGP SIGNATURE----- |