Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > ger.ct > #220834 > unrolled thread
| Started by | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| First post | 2015-09-12 15:20 +0200 |
| Last post | 2015-10-03 10:25 +0200 |
| Articles | 20 on this page of 205 — 38 participants |
Back to article view | Back to ger.ct
RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-12 15:20 +0200
Re: RAIDereien Günter Frenz <usenet-01@guefz.de> - 2015-09-12 15:44 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-12 16:04 +0200
Re: RAIDereien Günter Frenz <usenet-01@guefz.de> - 2015-09-12 16:48 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-12 17:17 +0200
Re: RAIDereien Günter Frenz <usenet-01@guefz.de> - 2015-09-12 17:54 +0200
Re: RAIDereien Michael Bode <m.g.bode@web.de> - 2015-09-12 18:05 +0200
Re: RAIDereien Mike Grantz <beatclubs@stoiseland.de> - 2015-09-12 20:48 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 09:54 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-13 16:10 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 09:30 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-14 09:26 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 12:13 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-14 14:21 +0000
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-14 18:28 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 09:19 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-15 08:13 +0000
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-15 03:49 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 09:07 +0200
Re: RAIDereien Ingo Paschke <ipaschke@lpclabs.de> - 2015-09-15 10:03 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 10:46 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-15 12:34 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 15:57 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 17:43 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 09:43 +0200
Re: RAIDereien Holger Marzen <holger@marzen.de> - 2015-09-12 14:29 +0000
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-12 16:58 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-12 15:05 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-12 17:41 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-12 16:01 +0000
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-12 19:38 +0200
Re: RAIDereien Emil Schuster <emil@wieslauf.sub.de> - 2015-09-12 22:42 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-12 20:29 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-12 20:33 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-12 21:56 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-12 22:11 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-13 15:48 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 16:20 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 09:33 +0200
Re: RAIDereien Günter Frenz <usenet-01@guefz.de> - 2015-09-13 10:02 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 14:35 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 14:58 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 15:25 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-13 16:10 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 16:31 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-14 10:25 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 11:02 +0200
Re: RAIDereien Friederich Daumeyer <spam-yourself@none.invalid> - 2015-09-14 11:16 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-14 20:32 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 09:08 +0200
Re: RAIDereien Matthias Eißing <meissing@gmx.de> - 2015-09-15 09:25 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 10:03 +0200
Re: RAIDereien Matthias Eißing <meissing@gmx.de> - 2015-09-15 12:06 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 12:41 +0200
Re: RAIDereien Matthias Eißing <meissing@gmx.de> - 2015-09-15 13:31 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-16 03:50 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 09:33 +0200
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 09:59 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 11:00 +0200
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 11:28 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-16 15:34 +0000
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-16 08:10 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 10:54 +0200
Re: RAIDereien Matthias Eißing <meissing@gmx.de> - 2015-09-16 11:25 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-16 07:55 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 09:29 +0200
Re: RAIDereien Matthias Eißing <meissing@gmx.de> - 2015-09-16 09:50 +0200
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 09:55 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-16 08:30 +0000
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 10:43 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-16 10:37 +0000
Re: RAIDereien Jörg Tewes <jogi1964@gmx.net> - 2015-09-16 14:02 +0200
Re: RAIDereien Dr. Joachim Neudert <neudert@5sl.org> - 2015-09-16 12:14 +0000
Re: RAIDereien Jörg Tewes <jogi1964@gmx.net> - 2015-09-16 14:30 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 14:23 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 10:52 +0200
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 11:10 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 11:55 +0200
Re: RAIDereien Lothar Frings <Lothar.Frings@gmx.de> - 2015-09-16 03:55 -0700
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-16 11:05 +0000
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 17:16 +0200
Re: RAIDereien Jörg Tewes <jogi1964@gmx.net> - 2015-09-16 17:27 +0200
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 17:32 +0200
Re: RAIDereien Jörg Tewes <jogi1964@gmx.net> - 2015-09-16 17:44 +0200
Re: RAIDereien "Dr. Joachim Neudert" <neudert@5sl.org> - 2015-09-16 17:49 +0200
Re: RAIDereien Wolfgang Kynast <wky@gmx.de> - 2015-09-16 18:22 +0200
Re: RAIDereien Sepp Neuper <Sepp_Neuper@web.de> - 2015-09-16 23:04 +0200
Re: RAIDereien Lothar Frings <Lothar.Frings@gmx.de> - 2015-09-17 00:07 -0700
Re: RAIDereien Lothar Frings <Lothar.Frings@gmx.de> - 2015-09-17 00:03 -0700
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-16 11:02 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 13:33 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-16 14:55 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 15:14 +0200
Re: RAIDereien Hanno Foest <hurga-news2@tigress.com> - 2015-09-16 16:46 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-16 22:53 +0200
Re: RAIDereien Hanno Foest <hurga-news2@tigress.com> - 2015-09-17 19:30 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-18 10:30 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-18 11:06 +0200
Re: RAIDereien Hanno Foest <hurga-news2@tigress.com> - 2015-09-18 11:32 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-18 12:38 +0200
Re: RAIDereien Hanno Foest <hurga-news2@tigress.com> - 2015-09-18 12:50 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-09-16 10:00 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-16 12:37 +0200
Re: RAIDereien "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2015-09-16 16:41 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-17 10:01 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-16 12:05 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-16 15:32 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-17 09:55 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 16:18 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 16:26 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 16:55 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 17:16 +0200
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-13 16:52 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 17:02 +0200
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-13 18:38 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 19:35 +0200
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-13 20:19 +0200
Re: RAIDereien Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-09-13 20:30 +0200
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-13 19:33 +0200
Re: RAIDereien Jörg Tewes <jogi1964@gmx.net> - 2015-09-13 22:24 +0200
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-14 18:39 +0200
Re: RAIDereien Jörg Tewes <jogi1964@gmx.net> - 2015-09-13 22:16 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 09:40 +0200
Re: RAIDereien Michael Zink <michael@swamp.franken.de> - 2015-09-13 17:02 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 17:33 +0200
Re: RAIDereien Michael Zink <michael@swamp.franken.de> - 2015-09-14 10:27 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-14 10:59 +0200
Re: RAIDereien Hendrik van der Heijden <hvdh@gmx.de> - 2015-09-14 19:25 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-15 09:30 +0200
Re: RAIDereien Puerstinger Josef <nospam@puerstinger.cc> - 2015-09-13 09:28 +0000
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-13 13:46 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 14:26 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-13 16:13 +0200
Re: RAIDereien Michael Zink <michael@swamp.franken.de> - 2015-09-13 17:00 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-13 17:18 +0200
Re: RAIDereien Michael Zink <michael@swamp.franken.de> - 2015-09-14 10:38 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-09-13 15:50 +0200
Re: RAIDereien Robin Koch <robin.koch@t-online.de> - 2015-10-01 23:09 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 09:44 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-10-02 12:22 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 14:09 +0200
Re: RAIDereien Shinji Ikari <shinji@gmx.net> - 2015-10-02 14:32 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 15:10 +0200
Re: RAIDereien Willi Marquart <usenet@neppi.net> - 2015-10-02 14:40 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 15:19 +0200
Re: RAIDereien Willi Marquart <usenet@neppi.net> - 2015-10-02 15:49 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 16:23 +0200
Re: RAIDereien Willi Marquart <usenet@neppi.net> - 2015-10-02 16:55 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 17:31 +0200
Lex Heidenreich (was: RAIDereien) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-10-02 18:26 +0200
Re: Lex Heidenreich (was: RAIDereien) Holger Marzen <holger@marzen.de> - 2015-10-02 16:45 +0000
Re: Lex Heidenreich Dorothee Hermann <DorotheeHermann@gmx.net> - 2015-10-02 18:58 +0200
Re: Lex Heidenreich Rainer Knaepper <rainerk@smial.prima.de> - 2015-10-02 19:38 +0200
Re: Lex Heidenreich gunter kuehne <kuehne-g@freenet.de> - 2015-10-02 21:02 +0200
Re: Lex Heidenreich Holger Marzen <holger@marzen.de> - 2015-10-03 06:21 +0000
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 10:41 +0200
Re: Lex Heidenreich Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-10-02 20:16 +0200
Re: Lex Heidenreich Mike Grantz <beatclubs@stoiseland.de> - 2015-10-02 20:32 +0200
Re: Lex Heidenreich Dennis Preiser <d__p@d--p.de> - 2015-10-02 18:49 +0000
Re: Lex Heidenreich Holger Marzen <holger@marzen.de> - 2015-10-03 06:21 +0000
Re: Lex Heidenreich Wolfgang Kynast <wky@gmx.de> - 2015-10-03 12:03 +0200
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 15:07 +0200
Re: Lex Heidenreich Klaus Dahlwitz <kdahlwitz@gmx.net> - 2015-10-04 00:30 +0200
Re: Lex Heidenreich Jörg Tewes <jogi1964@gmx.net> - 2015-10-02 22:47 +0200
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 10:19 +0200
Re: Lex Heidenreich Jörg Tewes <jogi1964@gmx.net> - 2015-10-04 23:54 +0200
Re: Lex Heidenreich Lothar Frings <Lothar.Frings@gmx.de> - 2015-10-05 00:32 -0700
Re: Lex Heidenreich Dorothee Hermann <DorotheeHermann@gmx.net> - 2015-10-05 13:45 +0200
Re: Lex Heidenreich Lothar Frings <Lothar.Frings@gmx.de> - 2015-10-05 04:50 -0700
Re: Lex Heidenreich Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-05 14:47 +0200
Re: Lex Heidenreich Lothar Frings <Lothar.Frings@gmx.de> - 2015-10-05 05:53 -0700
Re: Lex Heidenreich Jörg Tewes <jogi1964@gmx.net> - 2015-10-07 03:12 +0200
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-05 10:38 +0200
Re: Lex Heidenreich Lothar Frings <Lothar.Frings@gmx.de> - 2015-10-05 01:59 -0700
Re: Lex Heidenreich Michael Baeuerle <michael.baeuerle@stz-e.de> - 2015-10-05 10:08 +0000
Re: Lex Heidenreich Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-05 12:29 +0200
Re: Lex Heidenreich Peter Mc Donough <mcd-mail-lists@gmx.net> - 2015-10-05 19:39 +0200
Re: Lex Heidenreich Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-05 21:28 +0200
Re: Lex Heidenreich Lothar Frings <Lothar.Frings@gmx.de> - 2015-10-05 13:27 -0700
Re: Lex Heidenreich "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2015-10-06 15:35 +0200
Re: Lex Heidenreich Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-06 16:19 +0200
Re: Lex Heidenreich spamfalle2@arcor.de (Marc Stibane) - 2015-10-08 08:48 +0200
Re: Lex Heidenreich Carsten Thumulla <ct@ct.org> - 2015-10-08 09:44 +0200
Re: Lex Heidenreich Jörg Tewes <jogi1964@gmx.net> - 2015-10-05 12:56 +0200
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-05 15:03 +0200
Re: Lex Heidenreich Jörg Tewes <jogi1964@gmx.net> - 2015-10-07 03:12 +0200
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-07 10:22 +0200
Re: Lex Heidenreich "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 10:45 +0200
Re: Lex Heidenreich Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-02 19:24 +0200
Re: Lex Heidenreich Mike Grantz <beatclubs@stoiseland.de> - 2015-10-02 20:34 +0200
Re: Lex Heidenreich Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-02 20:57 +0200
Re: Lex Heidenreich Mike Grantz <beatclubs@stoiseland.de> - 2015-10-03 02:03 +0200
Re: RAIDereien Michael Bode <m.g.bode@web.de> - 2015-10-02 23:11 +0200
Re: RAIDereien Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-10-03 08:06 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 10:11 +0200
Re: RAIDereien Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2015-10-03 13:23 +0200
Re: RAIDereien Mike Grantz <beatclubs@stoiseland.de> - 2015-10-03 02:16 +0200
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-10-02 14:48 +0000
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-02 17:10 +0200
Re: RAIDereien Robin Koch <robin.koch@t-online.de> - 2015-10-02 21:46 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 10:03 +0200
Re: RAIDereien "Juergen P. Meier" <nospam-1984@jors.net> - 2015-10-03 08:15 +0000
Re: RAIDereien Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2015-10-03 16:04 +0000
Re: RAIDereien Robin Koch <robin.koch@t-online.de> - 2015-10-02 21:51 +0200
Re: RAIDereien "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-03 10:25 +0200
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| Date | 2015-09-14 18:39 +0200 |
| Message-ID | <8q9jccx6i9.ln2@diedrich.ehlerding.dialin.t-online.de> |
| In reply to | #221133 |
Jörg Tewes meinte: >> Ich ess derweil dann ne Currywurst, > > Geschnitten oder am Stück? ;-) Je nachdem. Ich nehm jedenfalls einen Schraubenzieher zum Aufpieken der Stücke, wenn sie geschnitten ist, und einen Zollstock, um nachzumessen, ob sie die Normlänge hat (wenn sie nicht geschnitten ist). Hauptsache, ich kann den Zollstock ablesen; aber irgendwo werd ich schon ne Glühbirne finden. Diedrich -- pgp-Key (RSA) 1024/09B8C0BD fingerprint = 2C 49 FF B2 C4 66 2D 93 6F A1 FF 10 16 59 96 F3 HTML-Mail wird ungeleſen entſorgt.
[toc] | [prev] | [next] | [standalone]
| From | Jörg Tewes <jogi1964@gmx.net> |
|---|---|
| Date | 2015-09-13 22:16 +0200 |
| Message-ID | <55F5D9A4.6000807@jtewes.my-fqdn.de> |
| In reply to | #221036 |
Gerrit Heitsch schrieb:
> Lies dir die URL durch, die ich gepostet hatte, da steht es gut erklärt
> drin.
Ulrich liest keine URLs, das kannst du doch sicher mit wenigen Worten
besser erklären. ;-) Mit anderen Worten du bist auch rein gefallen.
Bye Jörg
--
"Mollari, what did he say...really."
"He said...that we are both damned."
"Well, it's a small enough price to pay for immortality."
(Refa and Londo, "The Coming of Shadows")
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-09-14 09:40 +0200 |
| Message-ID | <mt64lo.3vs784p.1!not-for-mail@ufh.invalid.de> |
| In reply to | #221130 |
Jörg Tewes in <news:55F5D9A4.6000807@jtewes.my-fqdn.de>: >Gerrit Heitsch schrieb: > >> Lies dir die URL durch, die ich gepostet hatte, da steht es gut erklärt >> drin. > >Ulrich liest keine URLs, das kannst du doch sicher mit wenigen Worten >besser erklären. Das wäre auch nötig. Denn auch diese URL schreibt nur, nach welchem Schema die Paritybits auf den Platten verteilt werden, aber erklärt auch nicht, warum trotz gleicher Gesamtkapazität bei mehr Platten weniger Platz - und vice versa - dafür benötigt wird. CU! Ulrich
[toc] | [prev] | [next] | [standalone]
| From | Michael Zink <michael@swamp.franken.de> |
|---|---|
| Date | 2015-09-13 17:02 +0200 |
| Message-ID | <d5lhffFp5g4U2@mid.individual.net> |
| In reply to | #221026 |
On Sun, 13 Sep 2015 15:25:49 +0200, Ulrich F. Heidenreich wrote: >Ließen wir jetzt einen Mathematiker die Sache analysieren, würde der zum >Schluss kommen, man bräuche nur die Anzahl der Platten gegen unendlich >konvergieren zu lassen, dann ginge der Platzbedarf für Parity gegen >Null. Und damit hätte er Recht. Daß das wieder andere Nachteile bringen würde (die in diesem Thread genannt wurden) braucht ein Mathematiker nicht zu wissen. Auf Wiederlesen Michael -- Das Internet darf kein GRUNDrechtsfreier Raum werden!
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-09-13 17:33 +0200 |
| Message-ID | <mt4c0r.3vs3nf9.1!not-for-mail@ufh.invalid.de> |
| In reply to | #221050 |
Michael Zink in <news:d5lhffFp5g4U2@mid.individual.net>: >On Sun, 13 Sep 2015 15:25:49 +0200, Ulrich F. Heidenreich wrote: > >>Ließen wir jetzt einen Mathematiker die Sache analysieren, würde der zum >>Schluss kommen, man bräuche nur die Anzahl der Platten gegen unendlich >>konvergieren zu lassen, dann ginge der Platzbedarf für Parity gegen >>Null. > >Und damit hätte er Recht. Und was meint der Physiker/Techniker dazu: Je mehr Platten im Verbund, umso besser lässt sich das Parity für die *identische* Plattenkapazität einstampfen? Aber nun mal eine "moralische" Frage zu diesem Dunstkreis: Im Rahmen der angesagten Migration von 4x4 TB RAID5 auf 8x4TB RAID6 halte ich es aus Sicherheitsaspekten für sinnvoll, das 4x4 TB RAID5 erst einmal zu sichern, bevor ich am Pfriemeln beginne. Dazu /könnte/ ich bei Amazon ein QNAP TS 431 nebst Platten ordern und nach hoffentlich erfolgreichem Ablauf der Migration wieder zurückgeben. Also eklanter Missbrauch des Rückgaberechtes zwecks Leihgabe. Müsste ich deswegen vor Scham im Boden versinken oder dürfte "Scheisswasdrauf, andere machen's genauso" als Ausrede durchghen? TIA, Ulrich -- Bei Amazon kauft man via http://u-heidenreich.de/Amazon In 3 Monaten und 12 Tagen ist Weihnachten. VUIR8 OQPNR D9PW8 MVJSN C2BSW G39K5 DLBDB 61N9B 2XXMX Stellt euch vor, es ist Sonntag und keiner geht hin!
[toc] | [prev] | [next] | [standalone]
| From | Michael Zink <michael@swamp.franken.de> |
|---|---|
| Date | 2015-09-14 10:27 +0200 |
| Message-ID | <d5nenuF97vmU1@mid.individual.net> |
| In reply to | #221176 |
On Sun, 13 Sep 2015 17:33:15 +0200, Ulrich F. Heidenreich wrote: >Und was meint der Physiker/Techniker dazu: Je mehr Platten im Verbund, >umso besser lässt sich das Parity für die *identische* Plattenkapazität >einstampfen? Das wurde in diesem Thread schon so oft beantwortet, daß ich das nicht nochmal mache. >Aber nun mal eine "moralische" Frage zu diesem Dunstkreis: Unabhängig vom genannten Fall: Ich würde ungern mit Echtdaten beschriebene Platten aus der Hand geben. Besonders wenn sie nicht sicher gelöscht sind. Ich würde zum Umkopieren eher einen vorhandenen Sicherungsdatenträger nehmen. Auf Wiederlesen Michael -- Das Internet darf kein GRUNDrechtsfreier Raum werden!
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-09-14 10:59 +0200 |
| Message-ID | <mt69ai.3vs176d.1!not-for-mail@ufh.invalid.de> |
| In reply to | #221206 |
Michael Zink in <news:d5nenuF97vmU1@mid.individual.net>: >On Sun, 13 Sep 2015 17:33:15 +0200, Ulrich F. Heidenreich wrote: > >>Und was meint der Physiker/Techniker dazu: Je mehr Platten im Verbund, >>umso besser lässt sich das Parity für die *identische* Plattenkapazität >>einstampfen? > >Das wurde in diesem Thread schon so oft beantwortet, daß ich das nicht >nochmal mache. Da es noch kein einziges Mal beantwortet wurde, brauchst Du es in der Tat nicht noch einmal nicht zu beantworten. :-) Ich selbst bin derweil auf folgenden Denkansatz gestoßen: Eine einzige der Platten des Verbundes existiert de facto zweimal. Aber so geschickt auf alle Platten verteilt, daß es egal ist, welche der verbauten Platten nun zweimal da ist. Da aber nur eine zweimal da ist, darf auch maximal nur eine ausfallen. RAID6 dito: Da sind zwei beliebige Platten quasi zweimal da. RAID5 und 6 sichert den Ausfall einer respektive zweier Platten. Da muss die Sicherung freilich genauso groß wie die Platte sein. Irreführend bei der ganzen Geschichte war da wohl, daß überall und nirgends von Parity über den gesamten Plattenverbund zu lesen ist. >>Aber nun mal eine "moralische" Frage zu diesem Dunstkreis: > >Unabhängig vom genannten Fall: > >Ich würde ungern mit Echtdaten beschriebene Platten aus der Hand >geben. Besonders wenn sie nicht sicher gelöscht sind. Wo war was von "aus der Hand geben" die Rede? >Ich würde zum Umkopieren eher einen vorhandenen Sicherungsdatenträger >nehmen. Damit wäre der aber weg. Das wäre mir zu unsicher. Also sollte neben NAS und freilich existierender Sicherheizkopie des NAS ein weiteres NAS her. Das hat sich aber derweil erledigt, weil ein weiteres NAS ja da ist. Lediglich ein paar Platten mussten noch hinzu. Status quo: Erstes 4-Bay-NAS als primäres Datengrab. Zweites 4-Bay-NAS als Sicherungskopie des ersten. Ziel: Erstes 8-Bay-NAS als primäres Datengrab. Zweites 8-Bay-NAS als Sicherungskopie des ersten. Das zweite 8-Bay-NAS (noch leer. Dahinein sollen später die vorhanden 8 Platten aus NAS und Backup-NAS) kann mit 4 Platten als Zwischenspeicher während des Umkopiervorganges dienen. Es muss also kein drittes her. Wenn ich fertig habe, habe ich diese 4 Platten als Ersatzplatten auf Lager. CU! Ulrich
[toc] | [prev] | [next] | [standalone]
| From | Hendrik van der Heijden <hvdh@gmx.de> |
|---|---|
| Date | 2015-09-14 19:25 +0200 |
| Message-ID | <mt6vur$ik9$1@solani.org> |
| In reply to | #221209 |
Am 14.09.2015 um 10:59 schrieb Ulrich F. Heidenreich:
> Michael Zink in <news:d5nenuF97vmU1@mid.individual.net>:
>
>> On Sun, 13 Sep 2015 17:33:15 +0200, Ulrich F. Heidenreich wrote:
>>
>>> Und was meint der Physiker/Techniker dazu: Je mehr Platten im Verbund,
>>> umso besser lässt sich das Parity für die *identische* Plattenkapazität
>>> einstampfen?
>>
>> Das wurde in diesem Thread schon so oft beantwortet, daß ich das nicht
>> nochmal mache.
>
> Da es noch kein einziges Mal beantwortet wurde, brauchst Du es in der
> Tat nicht noch einmal nicht zu beantworten. :-)
>
> Ich selbst bin derweil auf folgenden Denkansatz gestoßen: Eine einzige
> der Platten des Verbundes existiert de facto zweimal. Aber so geschickt
> auf alle Platten verteilt, daß es egal ist, welche der verbauten Platten
> nun zweimal da ist.
So, nach diversen Ansätzen mach ich hier auch mal den Erklärbär.
Für jedes addressierbare Bit i (bzw. Byte oder Sektor) über
alle HDDs A1 bis An gilt für das RAID folgende Invariante:
XOR(A1[i], A2[i], A3[i], ... An[i]) = 0
Bei vier HDDs also a1 x a2 x a3 x a4 = 0
oder beispielhaft 0 x 0 x 1 x 1 = 0
Damit die Gleichung erfüllt wird, ist durch drei vorgegebene Werte
(z.B. a1,a2,a3) der vierte festgelegt (a4 = a1 x a2 ax a3).
Damit sind a1,a2,a3 frei wählbare Nutzdaten und a4 die Redundanz.
Fällt nun eine beliebige HDD weg (= 1/4 der Gesamtdatenmenge),
bleibt
0 x ? x 1 x 1 = 0,
woraus die fehlende Information restauriert werden kann, da die Gleichung
genau eine Unbekannte hat, und XOR so toll kommutativ, assoziativ,
invertierbar und sowieso alles mögliche ist.
Dem geneigten Leser ist es jetzt erlaubt, sich selbst daraus abzuleiten, dass
folgendes gilt:
- bei n HDDs halten (n-1) HDDs Nutzdaten und 1 HDD Redundanz
- die 1 HDD Redundanz entspricht (1/n)-tel der Gesamtdatenmenge
- wenn 1 beliebige HDD ausfällt, sind alle Nutzdaten und die Redundanz
aus den übrigen Daten ableitbar (kein Informationsverlust)
- wenn mehr als eine HDD ausfällt, ist der Inhalts der verlorenen
HDDs vollständig nicht wiederherstellbar
Hendrik vdH
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-09-15 09:30 +0200 |
| Message-ID | <mt8oev.3vs2h59.1!not-for-mail@ufh.invalid.de> |
| In reply to | #221299 |
Hendrik van der Heijden in <news:mt6vur$ik9$1@solani.org>: Aufs Wesentliche gekürzt: > - bei n HDDs halten (n-1) HDDs Nutzdaten und 1 HDD Redundanz Richtig. Redundanz in Größe genau der einen Platte, die maximal ausfallen darf. Und so geschickt über alle Platten verschachtelt, daß jede beliebige davon ausfallen darf. Nix mit Parity über die Gesamtkapazität. Ersteres ist in der Tat von der Plattengröße abhängig; Parity dagegen eigentlich™ von der Datenmenge, die mit einem Prüfbit verziert sein will. So musste ich mich vom Begriff "Parity" trennen und stattdessen an die Bedeutung des "R"in "RAID" erinnern. *Wie* diese Redundanz tatsächlich erzeugt wird, ist mir dabei so ziemlich Schnuppe. Zu erkenen, *daß* es aber Redundanz und nicht Parity ist, war dagegen ziemlich hilfreich. CU! Ulrich
[toc] | [prev] | [next] | [standalone]
| From | Puerstinger Josef <nospam@puerstinger.cc> |
|---|---|
| Date | 2015-09-13 09:28 +0000 |
| Message-ID | <mt3fja$b5a$1@news.albasani.net> |
| In reply to | #220964 |
Am 13/09/15 um 07:33 schrieb Ulrich F. Heidenreich: > Shinji Ikari in <news:8mr8valn4ntbb38kngqrjeae76rke5t4e2@4ax.com>: > >> Guten Tag "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> schrieb >> >>> Und nun kommt wieder einmal meine Dumme Frage: Geht bei RAID 5 immer nur >>> die Kapazität einer Platte für Parity verloren, egal, ob nun per vier >>> oder acht Platten realisiert? >> >> Ja. Bis 47 HDDs in einem Raid5 habe ich es spasseshalber vor einigen >> Monaten ausprobiert. > > Angenommen, es seien 1 TB Platten gewesen, dann reichte dazu ein > popeliges Terabyte, um Parity über 46 TByte zu bilden. Während ich > in meinem 4x4 TByte RAID ganze 4 TByte benötige, um Parity von > popeligen 12 TByte zu speichern? > > Das muss man nicht verstehen wollen, oder? Ich wage einen Erklärungsversuch: Angenommen, Du hast 9 Festplatten mit einer Kapazität von jeweils 1 Bit. Auf 8 Festplatten speicherst Du 1 Byte (= 8 Bit). Danach zählst Du die "1" auf den 8 Platten und schreibst auf die 9. Platte eine "0", falls die Anzahl der "1" auf den 8 Platten gerade, eine "1", falls die Anzahl der "1" auf den 8 Platten ungerade ist. D.h. die Summe der "1" auf den 9 Platten ist gerade. Falls eine der Platten ausfällt, zählst Du die "1" der restlichen HDDs. Da Du weisst, dass die Anzahl eine gerade Zahl ist, kannst Du das Bit der defekten HDD rekonstruieren. Jetzt erweiterst Du das RAID auf 17 (=16 + 1) HDD, d.h. Du kannst 2 Byte (=16 Bit) Daten speichern. Das Bit der Paritätsplatte bestimmst Du wie zuvor durch Zählen der "1" der Datenplatten. Das Prinzip funktioniert auch mit 65 (64 + 1) Platten (für 8 Byte), 8193 Platten (1 kB + 1 Paritatsplatte), etc. Du benötigst, egal wieviele HDD Du verwendest, nur 1 HDD, um zu speichern, ob die Anzahl der "1" gerade oder ungerade ist. In der Realität haben die Festplatten meistens eine Kapazïtät, die grösser als 1 Bit ist. In diesem Fall handelt es sich vom Funktionsprinzip her um nichts anderes als um eine Parallelschaltung des oben dargestellten 1-Bit-RAID. Im 1. Bit der Paritätsfestplatte ist gespeichert, ob die Anzahl der "1" der jeweils 1. Bits der HDDs gerade oder ungerade ist, im 2. Bit der Paritätsplatte wird vermerkt, ob die Anzahl der "1" der jeweils 2. Bits der HDDs gerade oder ungerade ist, etc. HTH, Josef
[toc] | [prev] | [next] | [standalone]
| From | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| Date | 2015-09-13 13:46 +0200 |
| Message-ID | <v94gccx3jo.ln2@diedrich.ehlerding.dialin.t-online.de> |
| In reply to | #220980 |
Puerstinger Josef meinte: > Am 13/09/15 um 07:33 schrieb Ulrich F. Heidenreich: [...] >> Das muss man nicht verstehen wollen, oder? > > Ich wage einen Erklärungsversuch: [Erklärungsversuch] Gut gemeint, auch gut erklärt - so gut, dass es selbst einem UFH verständlich sein müsste- ; aber da es deinem Vorredner offensichtlich zum wiederholten Male darum ging, anfangs eine scheinbar ernsthafte Frage zu stellen, sich dann bezüglich jedes Erklärungsversuchs ausnehmend dumm zu stellen und sich daran zu ergötzen, wie die anderen übers hingehaltene Stöckchen springen, absolut chancenlos. UFH will mal wieder keine Erklärung, ihm ist einfach langweilig - und er beobachtet gern andere , wenn die sich abmühen. Früher habe ich ihn einfach für lernresistent gehalten; inzwischen habe ich eher den Eindruck "böswilliger Troll". Diedrich -- pgp-Key (RSA) 1024/09B8C0BD fingerprint = 2C 49 FF B2 C4 66 2D 93 6F A1 FF 10 16 59 96 F3 HTML-Mail wird ungeleſen entſorgt.
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-09-13 14:26 +0200 |
| Message-ID | <mt411p.3vs4u8l.1!not-for-mail@ufh.invalid.de> |
| In reply to | #220980 |
Puerstinger Josef in <news:mt3fja$b5a$1@news.albasani.net>: >Am 13/09/15 um 07:33 schrieb Ulrich F. Heidenreich: > >> Angenommen, es seien 1 TB Platten gewesen, dann reichte dazu ein >> popeliges Terabyte, um Parity über 46 TByte zu bilden. Während ich >> in meinem 4x4 TByte RAID ganze 4 TByte benötige, um Parity von >> popeligen 12 TByte zu speichern? >> >> Das muss man nicht verstehen wollen, oder? > >Ich wage einen Erklärungsversuch: Ich glaub's ja, aber beim Nachvollziehen hapert es. >Angenommen, Du hast 9 Festplatten mit einer Kapazität von jeweils 1 Bit. Nehmen wir lieber 1 Byte an. Dann wird's Dir (Euch) viellleicht klarer, wo es mit meinem Verständnis hapert. >Auf 8 Festplatten speicherst Du 1 Byte (= 8 Bit). Und das 9te Bit ist Parity und kommtg auf die 9. Platte. (Okay: In natura sind die Paritybits wohl geschickt über alle Platten verteilt) >Danach zählst Du die >"1" auf den 8 Platten und schreibst auf die 9. Platte > > eine "0", falls die Anzahl der "1" auf den 8 Platten gerade, > eine "1", falls die Anzahl der "1" auf den 8 Platten ungerade > >ist. D.h. die Summe der "1" auf den 9 Platten ist gerade. Falls eine der >Platten ausfällt, zählst Du die "1" der restlichen HDDs. Da Du weisst, >dass die Anzahl eine gerade Zahl ist, kannst Du das Bit der defekten HDD >rekonstruieren. a) Wie weiß ich denn, auf welcher der Fehler ist? b) Muss ich das nicht pro Byte machen? Das heißt, bei einer 1 Byte Platte brauche ich 1 Bit Parity. Bei einer 2 Byte Platte 2 Bit Parity. Bei einer 3 Byte Platte 3 Bit Parity, usw. usf. Irgendwie muss es bei RAID aber anders gehen als Parity beim Haupt- speicher. Dann da spielt es keine Rolle, wie der organisiert ist: Ob nun 8 Streifen à 1 MB oder 4 Streifen à 2 MB. Für diese 8 MB brauche ich pro Byte ein Parity-Bit. Und nicht etwa bei den vier 2MB-Streifen mehr als bei den 8 1MB-Streifen. CU! Ulrich -- Nein.
[toc] | [prev] | [next] | [standalone]
| From | Shinji Ikari <shinji@gmx.net> |
|---|---|
| Date | 2015-09-13 16:13 +0200 |
| Message-ID | <f11bva19a5m5g9iti9h06qcfsn5nkchuab@4ax.com> |
| In reply to | #221022 |
Guten Tag "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> schrieb >a) Wie weiß ich denn, auf welcher der Fehler ist? Indem Der Kontroller/Software die Fehlermeldungen der HDD auswertet. Unterhalb dieser Raid5-Spielerei laufen weiterhin die HDD internen Fehlererkennungen ab. >b) Muss ich das nicht pro Byte machen? Per Bit erklaert ist es einfacher.
[toc] | [prev] | [next] | [standalone]
| From | Michael Zink <michael@swamp.franken.de> |
|---|---|
| Date | 2015-09-13 17:00 +0200 |
| Message-ID | <d5lhc5Fp5g4U1@mid.individual.net> |
| In reply to | #221022 |
On Sun, 13 Sep 2015 14:26:01 +0200, Ulrich F. Heidenreich wrote: >Irgendwie muss es bei RAID aber anders gehen als Parity beim Haupt- >speicher. Dann da spielt es keine Rolle, wie der organisiert ist: Ob nun >8 Streifen à 1 MB oder 4 Streifen à 2 MB. Für diese 8 MB brauche ich pro >Byte ein Parity-Bit. Und nicht etwa bei den vier 2MB-Streifen mehr als >bei den 8 1MB-Streifen. Genau! Vergiß ECC mal für ein paar Minuten und lese den Thread und einigen genannte Links nochmal. RAID ist kein ECC! Wenn ein Block gelesen werden soll und die zuständige Platte Daten zurückgibt, dann werden diese Daten verwendet. Wenn da Mist gelesen wurde, fällt das nicht auf. Aber wenn eine(!) Platte Lesefehler (oder gar nchts mehr) meldet, dann kann RAID das ausgleichen. Und das wird umso aufwändiger, je mehr Platten im RAID sind. Auf Wiederlesen Michael -- Das Internet darf kein GRUNDrechtsfreier Raum werden!
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-09-13 17:18 +0200 |
| Message-ID | <mt4b5t.3vs2d2h.1!not-for-mail@ufh.invalid.de> |
| In reply to | #221049 |
Michael Zink in <news:d5lhc5Fp5g4U1@mid.individual.net>: >Aber wenn eine(!) Platte Lesefehler (oder gar nchts mehr) meldet, >dann kann RAID das ausgleichen. Und das wird umso aufwändiger, je >mehr Platten im RAID sind. Je *mehr*?
[toc] | [prev] | [next] | [standalone]
| From | Michael Zink <michael@swamp.franken.de> |
|---|---|
| Date | 2015-09-14 10:38 +0200 |
| Message-ID | <d5nfciF9amtU2@mid.individual.net> |
| In reply to | #221057 |
On Sun, 13 Sep 2015 17:18:53 +0200, Ulrich F. Heidenreich wrote: >Je *mehr*? Ja. Auf Wiederlesen Michael -- Das Internet darf kein GRUNDrechtsfreier Raum werden!
[toc] | [prev] | [next] | [standalone]
| From | Shinji Ikari <shinji@gmx.net> |
|---|---|
| Date | 2015-09-13 15:50 +0200 |
| Message-ID | <emvava529jogqtu54o2ajjb8s51hv34fp7@4ax.com> |
| In reply to | #220964 |
Guten Tag "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> schrieb >>Ja. Bis 47 HDDs in einem Raid5 habe ich es spasseshalber vor einigen >>Monaten ausprobiert. >Angenommen, es seien 1 TB Platten gewesen, dann reichte dazu ein >popeliges Terabyte, um Parity über 46 TByte zu bilden. Es reicht um im Ausfallfall in Verbindung mit den verbleibenden 45 HDDs die Ursprungsdaten zu rekonstruieren und somit den Inhalt der 47.HDD wieder nachzubilden. >Das muss man nicht verstehen wollen, oder? Korrekt. Das muss man nicht.
[toc] | [prev] | [next] | [standalone]
| From | Robin Koch <robin.koch@t-online.de> |
|---|---|
| Date | 2015-10-01 23:09 +0200 |
| Message-ID | <muk7eh$mg2$1@news.albasani.net> |
| In reply to | #220834 |
Am 12.09.2015 um 15:20 schrieb Ulrich F. Heidenreich:
> Mein Milchmädchen bekommt gerade Rechenprobleme:
Ich habe den Thread jetzt (nachträglich) im wesentlichen gelesen und so
ganz entmystifiziert scheint es ja für Dich ja noch nicht zu sein.
Und aus irgendeinem Grund lässt mich das nicht los, da es eigentlich
wirklich simpel ist. (Ich weiß so eine Einleitung ist didaktisch unklug,
musste jetzt aber einfach mal sein.)
Daher versuche ich es nochmal mit anderen Worten und einem Beispiel!
Aber zunächst nochmal die Frage:
> Und nun kommt wieder einmal meine Dumme Frage: Geht bei RAID 5 immer nur
> die Kapazität einer Platte für Parity verloren, egal, ob nun per vier
> oder acht Platten realisiert? Müssten nicht acht Platten mehr für Parity
> brauchen als vier?
Bevor ich zur Antwort schreite möchte ich betonen, dass ich mich zuvor
noch nicht mit RAID beschäftigt habe und sämtliche Informationen zum
Verfahren aus diesem Thread stammen, soweit es RAID5 betrifft. Auch den
zitierten bzw. verlinkten Wikipedia-Artikel habe ich nicht gelesen.
Nur den Abschnitt über RAID6 habe ich überflogen und offenbar sind die
Verfahren nicht ganz so simpel wie RAID5, weshalb ich nur ein Beispiel
für RAID5 bringe.
Falls ich grundsätzliche Fehler mache mögen mich diejenigen die sich
besser auskennen korrigieren, falls ich nur zu flapsig formuliere mögen
Klärungs- und Verwirrungspotential eines Kommentars gegeneinander
abgewägt werden. :-)
Also los!
Das grundsätzliche Prinzip von RAID5 (soweit ich es verstanden habe)
besteht darin die Informationen aus n-1 gleichgroßen Festplatten
miteinander zu verrechnen und das Ergebnis, die "Parität", auf der n-ten
Festplatte zu speichern.
Soweit ist es nun schon öfter erwähnt worden ohne die Dinge zu klären.
Was bedeutet das also alle?
Halten wir zunächst fest, dass alle Festplatten idealerweise gleich groß
sind (oder ansonsten von jeder Festplatte nur der Speicherbereich der
insgesamt kleineste Platte im Verbund genutzt wird).
Wieso ist das so?
Die Rechenoperation die auf die n-1 Festplatten angewendet wird ist eine
bitweise Operation (das XOR, dazu später.). Das bedeutet, dass jedes
einzelne Bit auf einer Festplatte mit allen anderen einzelnen Bits auf
den anderen Festplatten *an der jeweils gleichen Stelle* miteinander
verrechnet werden. Und das Ergebnis an der selben Stelle auf der n-ten
Festplatte gespeichert wird.
Im 3+1-Verbund heißt das, dass das Ergebnis aus dem 20151001. Bit der 1.
Festplatte und dem 20151001. Bit der zweiten Festplatte und dem
20151001. Bit der dritten Festplatte im 20151001. Bit der vierten
Festplatte gespeichert wird.
Ein Beispiel mit drei (vollbeschriebenen) 8 Byte-Festplatten:
HDD1: AUTO 01000001 01010101 01010100 01001111
HDD2: BALL 01000010 01000001 01001100 01001100
HDD3: NNTP 01001110 01001110 01010100 01010000
(Die erste Spalte sei unser Festplatteninhalt in Plaintext für "uns" und
die Blöcke sind die Bitrepräsentationen ist ASCII für "den Computer".)
Jetzt werden die 3 Bits jeder Spalte "miteinander verrechnet". Wie
passiert das?
Die magische Operation in das "XOR" oder "Exklusive Oder" oder das
"nicht gleich". Was macht die und was macht sie so nützlich?
Das XOR ist ein logischer binärer Operator. Es gehen also zwei Bit rein
und eines kommt raus. Im Falle des XOR (Formelzeichen: ^) ist das
Ergebnis 1 (also 'wahr'), gdw. ein Operant 1 und ein Operant 0 ist.
Die Tabelle dazu sieht so aus:
A | B | A^B
--+---+----
0 | 0 | 0
0 | 1 | 1
1 | 0 | 1
1 | 1 | 0
Man liest das XOR: "Entweder A oder B (aber nicht beides)"
Zwei wichtige Eigenschaften des XORs sind seine Kommutativität und seine
Assoziativität.
Das bedeuten, das sowohl die Reihenfolge der Operanten sowie die
Reihenfolge der Ausführung der Operationen das Ergebnis nicht ändern.
Mit dem XOR kann man also ähnlich rechnen wie mit Plus oder Mal.
(a*b = b*a und (a*b)*c = a*(b*c))
Die Kommutativität erkennt man in der obigen Tabelle daran, das die
Ergebnisse der zweiten und dritten Zeile übereinstimmen. Den Nachweis
der Assoziativität lasse ich mal weg, wer das nicht glaubt möge das
bitte nachlesen, nachfragen oder einfach mal selbst ausprobieren.
Wichtig ist die Erkenntnis, da man nun beobachten kann, was die
XOR-Operation anschaulich macht, wenn man sie auf mehr als zwei
Operanden anwendet:
Das XOR ist 0 gdw. die Anzahl der vorkommenden 1en gerade ist.
Das XOR ist 1 gdw. die Anzahl der vorkommenden 1en ungerade ist.
Daher kommt schließlich auch der Name "Parität".
Beispiel mit für drei Operanden:
A | B | C | A^B^C
--+---+---+------
0 | 0 | 0 | 0 (0 Einsen)
0 | 0 | 1 | 1 (1 Eins)
0 | 1 | 0 | 1 (1 Eins)
0 | 1 | 1 | 0 (2 Einsen)
1 | 0 | 0 | 1 (1 Eins)
1 | 0 | 1 | 0 (2 Einsen)
1 | 1 | 0 | 0 (2 Einsen)
1 | 1 | 1 | 1 (3 Einsen)
Mit dieser Operation ausgestattet können wir nun den Inhalt unserer 4. 8
Byte-Festplatte berechnen:
HDD1: AUTO 01000001 01010101 01010100 01001111
HDD2: ^ BALL 01000010 01000001 01001100 01001100
HDD3: ^ NNTP 01001110 01001110 01010100 01010000
=============================================
HDD4: MZLS 01001101 01011010 01001100 01010011
Jedes Bit in der vierten Zeile entsteht durch VerXORung der drei Bits
darüber. Das kann jeder selbst nachrechnen, z.B. mit der Wertetabelle oben.
Die Daten sind also meine Operanden, das Ergebnis ist die Parität. Die
Reihenfolge der Festplatten 1-3 spielt dabei keine Rolle.
Und auch die Anzahl wird keine Rolle spielen! Dazu später ein Beispiel.
Jetzt wissen wir, *wie* das XOR funktioniert.
Die zweite Frage zum XOR war: Wieso?
Das Ziel ist es ja im Falle eines Festplattenausfalles den Inhalt dieser
Platte zu rekonstruieren. Man muss als die Operation rückgängig machen.
Das mag auch mit anderen Operationen als dem XOR gehen, aber das XOR hat
eine besonders schöne Eigenschaft!
Wenn ich einen beliebigen Operanden weglasse und durch das zuvor
berechnete Ergebnis ersetze (als dem Paritätsbit), dann erhalte ich als
Ergebnis den fehlenden Operanden!
Dazu zwei Beispiele:
Im einfachsten Fall habe ich nur zwei Operanden A und B:
A | B | E = A^B | A^E | E^B
--+---+---------+-----+-----
0 | 0 | 0 | 0 | 0
0 | 1 | 1 | 1 | 0
1 | 0 | 1 | 0 | 1
1 | 1 | 0 | 1 | 1
Wir stellen fest, dass A^E = B ist und E^B = A!
Ein anderes Beispiel mit unseren 8 Byte-Festplatten:
Nehmen wir an HDD2 fällt aus:
HDD1: AUTO 01000001 01010101 01010100 01001111
HDD2: ???????? ???????? ???????? ????????
HDD3: NNTP 01001110 01001110 01010100 01010000
HDD4: MZLS 01001101 01011010 01001100 01010011
Wie bekommen wir die Daten zurück?
Wir machen das gleiche wie sonst auch. Wie verXORen die restlichen Platten:
HDD1: AUTO 01000001 01010101 01010100 01001111
HDD3: ^ NNTP 01001110 01001110 01010100 01010000
HDD4: ^ MZLS 01001101 01011010 01001100 01010011
=============================================
HDD2: BALL 01000010 01000001 01001100 01001100
Wir bekommen tatsächlich wieder unseren ursprünglichen Inhalt!
(Auch das kann jeder nachrechnen.)
Auf den mathematischen Beweis, dass das immer und für alle n
funktioniert verzichte ich an dieser Stelle, sondern reiche ihn bei
Bedarf einfach nach.
So. Nun sollte verstanden sein, wie die Ausfallsicherheit bei RAID5
funktioniert.
Wenn ich mehr Laufwerke verwende, verrechne ich halt mehr Bits in eine
Parität (es bleibt bei einem Bit pro Spalte).
Die benötigte Datenmenge für die Parität nimmt also *nicht* mit der Zahl
der Laufwerke zu!
Sie entspricht prinzipbedingt *immer* *genau* einem gleichartigen
Datenträger.
Der relative Anteil der Sicherung *sinkt*.
Das ist ein Vorteil. Der damit eingekaufte Nachteil wurde ebenfalls
schon angesprochen:
Je mehr Festplatte im Verbund sind, desto höher ist die
Wahrscheinlichkeit, dass eine ausfällt. Die muss man dann rechtzeitig
ersetzen, bevor die zweite ausfällt. (Eine ausgefallene Platte lässt
sich ja wiederherstellen, haben wir gelernt. Fallen zwei Platten zur
gleichen Zeit aus sind die Daten weg.)
Sehen wir uns daher mal ein anderes Beispiel an.
Eben hatten wir vier 4 Byte-HDDs, also insgesamt 16 Byte Speicher, und
konnten darauf 12 Byte speichern (75% Daten, 25% "Sicherung").
Betrachten wir nun also acht 2 Byte-HDDs. Sieben für unsere Daten (14
Byte, 87,5%) und eine für unsere "Sicherung" (2 Byte, 12,5%).
HDD1: MO 01001101 01001111
HDD2: ^ DI 01000100 01001001
HDD3: ^ MI 01001101 01001001
HDD4: ^ DO 01000100 01001111
HDD5: ^ FR 01000110 01010010
HDD6: ^ SA 01010011 01000001
HDD7: ^ SO 01010011 01001111
=========================
HDD8: F\ 01000110 01011100
Das Prinzip ist das gleiche wie zuvor. Wir nehmen die 7 Bit jeder Spalte
(= Position auf dem Laufwerk), verXORen die (= zählen die Einsen und
prüfen, ob die Anzahl gerade oder ungerade ist) und schreiben das
Ergebnis (=die Parität) an die entsprechende Stelle auf dem Sicherungs-
oder Paritätslaufwerk.
Tatsächlich können wir jetzt mehr Daten auf unseren insgesamt 16 Byte
speichern als vorher und der relative Anteil der Sicherung nimmt ab.
Dafür verdoppeln sich die Wahrscheinlichkeiten für den Ausfall einer
Platte und (vor allem) zweier Platten.
================
Ich hoffe ich konnte deutlich machen
- was die Parität eigentlich ist.
- wieso die Parität immer genau eine Festplatte benötigt unabhängig von
der Zahl der Datenplatten.
- dass bei RAID5 keine Daten im eigentlichen Sinne "gesichert" werden,
sondern nur wiederherstellbar gemacht werden und daher die
"Sicherungsdaten" nicht mit der Zahl der Datenmenge wächst.
- wieso die Paritätsdatenmenge bei entsprechender Umverteilung der
Daten auf mehr (kleinere) Festplatten sogar sinken kann.
Wie schon eingangs erwähnt habe ich mich mit RAID6 nicht beschäftigt.
Diese (laut Wikipedia wohl eher unübliche) Art des RAID-Verbunds benutzt
in der Tat zwei Platten statt einer um Paritätsdaten zu speichern. Das
hier beschriebene Verfahren funktioniert in diesem Fall natürlich nicht
ohne entsprechende Veränderungen des gesamten Algorithmus!
RAID6 speichert *nicht* einfach die Paritätsdaten doppelt. Das würde
exakt *keinen* Vorteil bringen.
RAID6 ist auch kein "geschachteltes" RAID5, das auf einer Platte die
Paritäten der Daten *plus* deren Paritätsdaten speichert. Auch das wäre
völlig reduntant. (Es wäre eine Übung für den Leser zu überlegen, was
dann auf der zweiten Platte stehen würde. :-))
Ich hoffe mit dem neuen Verständnis von Paritäten, XOR und RAID5 lassen
sich Webseiten über RAID6 besser selbstständig verstehen.
Herzlichst,
--
Robin Koch
[toc] | [prev] | [next] | [standalone]
| From | "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> |
|---|---|
| Date | 2015-10-02 09:44 +0200 |
| Message-ID | <muljmp.3vs7a3b.1!not-for-mail@ufh.invalid.de> |
| In reply to | #223586 |
Robin Koch in <news:muk7eh$mg2$1@news.albasani.net>: >Am 12.09.2015 um 15:20 schrieb Ulrich F. Heidenreich: > >> Mein Milchmädchen bekommt gerade Rechenprobleme: >Das grundsätzliche Prinzip von RAID5 (soweit ich es verstanden habe) >besteht darin die Informationen aus n-1 gleichgroßen Festplatten >miteinander zu verrechnen und das Ergebnis, die "Parität", auf der n-ten >Festplatte zu speichern. Und das ist falsch. Denn wäre es so, müsste sie Parität umso größer werden, je größer die Gesamtkapazität ist. Wenn jedes Byte ein Parity- Bit bekommt, benötigen halt 10 Byte zehnmal soviel Parity als ein Byte. Tatsächlich gibt es keine "Parity"-Festplatte, sondern die Daten werden so geschickt über alle Platten verteilt, daß eine davon ausfallen darf, ohne einen Datenverlust zu erleiden. Und dann sagt sich das gleiche Milchmädchen: Wenn eine ganze Platte ausfallen darf, muß so ziemlich genau die Kapazität einer Platte redundant vorhanden sein. *Wie* das intern verhackstückelt ist, spielt zum Verständnis keine Rolle, ja es verwirrt eher. >Soweit ist es nun schon öfter erwähnt worden ohne die Dinge zu klären. > >Was bedeutet das also alle? > >Halten wir zunächst fest, dass alle Festplatten idealerweise gleich groß >sind (oder ansonsten von jeder Festplatte nur der Speicherbereich der >insgesamt kleineste Platte im Verbund genutzt wird). >Wieso ist das so? Irrelevant. >Jetzt wissen wir, *wie* das XOR funktioniert. >Die zweite Frage zum XOR war: Wieso? Irrelevant. Ausschlaggebend it, was hinten rauskommt: Eine Platte darf ausfallen, also muss die Kapazität einer Platte redundant vorgehalten werden. Es gilt dabei völlig logisch: Je kleiner die Platte, umsoweniger Redundanz ist vorzuhalten. >Das Ziel ist es ja im Falle eines Festplattenausfalles den Inhalt dieser >Platte zu rekonstruieren. Exakt. *Wie* das geht, interessiert mich nicht die Bohne. Mir reicht es zu wissen, *daß* das geht. Und zwar nicht via dem Verfahren, was allgemein als Parity bakannt ist. Denn "Parity" impliziert ja "je mehr Daten umso mehr Parity". Tatsächlich impliziert RAID5 aber "je kleiner die eine Platte, die dabei ausfallen darf, umso kleiner auch die benötigte Redundanz". >Man muss als die Operation rückgängig machen. >Das mag auch mit anderen Operationen als dem XOR gehen, aber das XOR hat >eine besonders schöne Eigenschaft! Schön für das XOR. Aber will ich was von Interna wissen? >Wenn ich mehr Laufwerke verwende, verrechne ich halt mehr Bits in eine >Parität (es bleibt bei einem Bit pro Spalte). Es ist eben genau *nicht* die Anzahl der Laufwerke, die den Platz für "Parity" beeinflusst, sondern die Größe einer einzigen Platte. Denn es muss ja nur eine einzige redundant gehalten werden. Ob ich eine von 3 oder ein von 8 redundant haben will, brauche ich nur genau den Platz dieser einen Platte. Damit das eine beliebige sein kann, werden die Daten geschickt in Scheibchen auf allen Platten verteilt. >Je mehr Festplatte im Verbund sind, desto höher ist die >Wahrscheinlichkeit, dass eine ausfällt. Auch das hatten wir schon durchgekaut. Die Wahrscheinlichkeit für den Plattenausfall einer Platte ist eine (mehr oder weniger) Konstante. Egal, ob neben ihr noch eine oder fünf weitere werkeln. Die weiß das nämlich nicht und geht hops, wenn und wann es ihr beliebt. >Sehen wir uns daher mal ein anderes Beispiel an. >Eben hatten wir vier 4 Byte-HDDs, also insgesamt 16 Byte Speicher, und >konnten darauf 12 Byte speichern (75% Daten, 25% "Sicherung"). Du versuchst weiter durch völlig uninteressante Interna zu verwirren. >Wie schon eingangs erwähnt habe ich mich mit RAID6 nicht beschäftigt. >Diese (laut Wikipedia wohl eher unübliche) Art des RAID-Verbunds benutzt >in der Tat zwei Platten statt einer um Paritätsdaten zu speichern. Andersrum wird ein Schuh draus: Wenn im Gegensatz zu RAID5 zwei Platten statt nur einer ausfallen dürfen, dann muß halt die Kapazität zweier Platten redundant vorgehalten werden. Wie, ist auch hier Schnuppe. CU! Ulrich -- Aus meiner Sammlung "Eigenwillige Newgroups": alt.schrodingers.other.cat 0 0 y All about Schrodinger's Other Cat
[toc] | [prev] | [next] | [standalone]
| From | Shinji Ikari <shinji@gmx.net> |
|---|---|
| Date | 2015-10-02 12:22 +0200 |
| Message-ID | <d1ls0bl0an55oltpsf0i2aq0hhnoidt2ss@4ax.com> |
| In reply to | #223601 |
Guten Tag "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> schrieb >>Das grundsätzliche Prinzip von RAID5 (soweit ich es verstanden habe) >>besteht darin die Informationen aus n-1 gleichgroßen Festplatten >>miteinander zu verrechnen und das Ergebnis, die "Parität", auf der n-ten >>Festplatte zu speichern. >Und das ist falsch. Denn wäre es so, müsste sie Parität umso größer >werden, je größer die Gesamtkapazität ist. Solange die Groesse der kleinsten HDD sich nicht aendert muss die Paritaet nicht groesser werden (Paritaet mathematisch betrachtet!). Der Gesamtverbund hingegen kann (im Tahmen der technischen Grenzen) ruhig erweitert werden. Ob nun ein Raid aus 4*2TB HDDs besteht oder aus 24* 2TB ist egal. Die Summe der Paritaetsdaten betragen bei Vollausnutzung grob gesagt die Gesamtmenge einer 2TB HDD (bei Raid5 aber ueber alle Platten verteilt). > Wenn jedes Byte ein Parity- >Bit bekommt, benötigen halt 10 Byte zehnmal soviel Parity als ein Byte. Ja, aber es ist ja nicht jedes Byte, sondern alle ersten NutzdatenBytes aller Nutzdaten HDDs werden zuammen genommen und nur die Paritaet dieser Stelle auf allen HDDs wird vermerkt. Dann werden alle zweiten Nutzdatenbytes genommen... Dann alle dritten Nutzdatenbayates... etc... >Tatsächlich gibt es keine "Parity"-Festplatte, sondern die Daten werden >so geschickt über alle Platten verteilt, daß eine davon ausfallen darf, >ohne einen Datenverlust zu erleiden. Ich vermute, dass Robin mit Absicht hier schrieb, dass es die "n-te" Festplatte ist um das Prinzip der wechselnden HDD fuer die Paeritaetsdaten der jeweiligen Bits/Bytes/Bloecke nicht noch komplizierter erklaeren zu muessen. Das, was Robin versuchte zu erklaeren ist eigentlich Raid4. Es ist grundlegend genau so sicher wie Raid5 (gegen Ausfall einer einzigen HDD), dafuer ist die Schreibperformance bei Raid4 in bestimmten Situationen nicht optimal. > Und dann sagt sich das gleiche >Milchmädchen: Wenn eine ganze Platte ausfallen darf, muß so ziemlich >genau die Kapazität einer Platte redundant vorhanden sein. In Milchmaedchendenkweise ist das ja auch so: Die Kapazitaet einer Platte (in Summe der Paritaetsdaten) steht ja bei Raid 5 zur Verfuegung. >>Das Ziel ist es ja im Falle eines Festplattenausfalles den Inhalt dieser >>Platte zu rekonstruieren. >Exakt. *Wie* das geht, interessiert mich nicht die Bohne. Mir reicht >es zu wissen, *daß* das geht. Dafuer, dass Dich das "wie" nicht interessiert, sondern nur das "es geht". hattest Du aber schon sehr interessiert nach dem Warum gefragt. >Und zwar nicht via dem Verfahren, was >allgemein als Parity bakannt ist. Denn "Parity" impliziert ja "je mehr >Daten umso mehr Parity". nein, impliziert es nicht. https://de.wikipedia.org/wiki/Parit%C3%A4t Parität (Mathematik): Eigenschaft einer ganzen Zahl, gerade zu sein oder ungerade zu sein. Wenn man als Ganze Zahl beispielsweise jeweils das erste Bit der NutzdatenHDDs nimmt, ist und bleibt die Groesse, die fuer diese eine Information benoetigt wird gleich gross, egal ob man 4 oder 10 oder 20 HDDs als Raid5 nutzt. > Tatsächlich impliziert RAID5 aber "je kleiner >die eine Platte, die dabei ausfallen darf, umso kleiner auch die >benötigte Redundanz". Die Redundanzgroesse = der kleinsten dafuer genutzen Groesse der einzelnen Medien in einem Raid5. Raid5 bestehend aus 10 * 1TB enthaelt Paritaet in der Groesse von 1TB und Nutzdaten in der Groesse von 9TB. Raid5 bestehend aus 5 * 2TB enthaelt Paritaet in der Groesse von 2TB und Nutzdaten in der Groesse von 8TB. >>Wenn ich mehr Laufwerke verwende, verrechne ich halt mehr Bits in eine >>Parität (es bleibt bei einem Bit pro Spalte). >Es ist eben genau *nicht* die Anzahl der Laufwerke, die den Platz für >"Parity" beeinflusst, sondern die Größe einer einzigen Platte. ...und das schreibt er ja: Wenn man mehr Laufwerke nimmt bleibt es bei der gleichen Groesse fuer die Paritaet.
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | ger.ct
csiph-web