Hi, Von: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] > At 21:35 03/03/2014, you wrote: > ´¯¯¯ > >RAID3-4-5 was great when disks were expensive, in 80's an 90's. Now > >not. A minimal RAID5 needs 3 disks. A minimal RAID10 4. An enterprise > >disk SAS 15Krpm 146 GB 6G is $350, and a not enterprise grade cheaper > >and bigger. Now RAID1E and RAID10E give more flexibility and variable > >security, from "paranoid" to "i don't care" grades. > `--- > > The point being discussed was not on performance or cost, but on the > imaginary fact that RAID5-6 and variations have the inherent, by-design fatal > flaw that they break down because a parity block can be out of sync with > corresponding data blocks. This is bullshit, period.
It is not. Period. > Nothing in RAID5-6 design mandates serialization of writes, by far. Yes. But I've yet to know a setup for harddisks which allows reliable transactional writes spanning several disks. (Kinda two-phase commit for disk writes). Of course, a dedicated hardware controller who issues the write requests to the disks absolutely synchronously lowers the risk by shrinking the time window. But it cannot totally eliminate it, for at least the following reasons: - The platters are usually not completely physically in sync, so the first disk may have written the block while the second disk still needs to wait for another 1/4 rotation for the block to be written. - One of the disks may have internally remapped a bad sector, needing a seek (and thus much longer time) to write the block. In reality, there are usually some more time variation, e. G. due to - Both disks may be connected through the same cable, thus the requests to the disks need to be serialized. - There may be other outstanding requests in the disk internal cache which the disk firmware might reorder in a different way. I admit that the remaining risk may be low, but it is not zero. Period. > It's only when cheap, unreliable hardware is put to work under below par > software that the issue can be a real-world problem. > > So the rant on the design against parity-enabled RAIDs is moot, if not plain > fallacious unless "software RAID without dedicated controller" is clearly > mentionned. I did mention using battery backed power as a way to mitigate the risk. And as far as I know, even the most expensive hardware RAID controllers and disks do not yet support multi-disk transactions, so your reference to not-yet existing hardware is moot. > About SAS disks: they have actual very high reliability and don't lie, > contrary to SATA disks (on both points). > > This is not a war about mine being bigger, but it's better to have facts > stated right. I fully agree there. > All high-end reliable machines and storage subsystems only run > parity-enabled RAID levels and this thechnology isn't going to disappear > tomorrow. I doubt that _all_ those machines exclusively run on parity-enabled RAID levels, but I'm strongly interested in a proof of your "fact" here. I remember reading that PostgreSQL and Oracle recommend using mirroring based levels instead of parity-enabled ones for performance reasons, so I'm really curious to read about how you back up your claim. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
