Cooked VS Raw

Any bold opinions on cooked files vs raw space? I know previously I had been told by many that the raw option was far faster because of HDD speeds. Since most things aren't single drives anymore I assume that this has changed some?

Hi Nate, I don't have any direct data to compare however with the addition of DIRECT_IO you can drastically speed up I/O on cooked devices. I would suggest benchmarking in your environment and letting us know what you find. Thanx, Dan PS Say hey to all for me. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of NATE HICKS Sent: Tuesday, October 14, 2014 4:03 PM To: ids@iiug.org Subject: Cooked VS Raw [33971] Any bold opinions on cooked files vs raw space? I know previously I had been told by many that the raw option was far faster because of HDD speeds. Since most things aren't single drives anymore I assume that this has changed some? ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

hi i prefer cooked because con muy systems there aren't single drives however cooked files depends which type of filesystems are you using. testing in linux i founded that ext2 is faster than ext3 and ext3 is faster than ext4. regards. On Oct 14, 2014 10:03 PM, "NATE HICKS" <nathaniel.hicks@trnswrks.com> wrote: > Any bold opinions on cooked files vs raw space? I know previously I had > been > told by many that the raw option was far faster because of HDD speeds. > Since > most things aren't single drives anymore I assume that this has changed > some? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a113397584003fa050567c58b

In my testing, with DIRECT_IO enabled, Cooked filesystem files are about 3-5% slower than RAW, Cooked devices can't use DIRECT_IO so they are still 5-15% slower than RAW devices. Some Linux systems do perform better with cooked than raw, but most do not. AIX, HPUX, & Solaris, RAW definitely faster. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Oct 14, 2014 at 4:03 PM, NATE HICKS <nathaniel.hicks@trnswrks.com> wrote: > Any bold opinions on cooked files vs raw space? I know previously I had > been > told by many that the raw option was far faster because of HDD speeds. > Since > most things aren't single drives anymore I assume that this has changed > some? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0160b3ba0cb9410505688966

Am 14.10.2014 22:03, schrieb NATE HICKS: > Any bold opinions on cooked files vs raw space? I know previously I had been > told by many that the raw option was far faster because of HDD speeds. Since > most things aren't single drives anymore I assume that this has changed some? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > for some time now a simple answer is no longer to this question. It depends on many 'legacy style'- details - virtual or not and if so, what is the hypervisor? Running as virtual appliance it depends on the tuning steps done for the hypervisor. Expect huuuge additional I/O latency flattening the differences between random I/O on disk versus random I/O on SSDs. Running on virtual I/O also means that there is no sequential I/O anymore - seen from the perspective of the hypervisor. Data load speed comes mind and also LRU writes versus syncing the buffer cache to disk during checkpoints - OS? - subsystem? And if so, what is it and what is the ratio controller cache size to sum of all disk space cached by this controller. It is shocking to see, that on not so few I/O subsystems this ratio of cache size to disk space is not better that on-platter cache to platter size. And what ist the bandwith to the subsystem and how many hosts share this bandwith. - if on cooked files, what is the mount setting of the underlying file system? From mailserver setup tuning ( mailserver == very many small files ) we found how important it is NOT to update meta data when reading, else you have no reads anymore but 1 read, 2 writes (man mount, atime) - finally it depends, if you have an average workload type 4+:1 read:write or not. On Linux - and on Redhat this is a starting point https://access.redhat.com/solutions/54164 dic_k --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com

Hi, I am a friend of raw devices, but there are multiple ways to define them, which might lead to different speed experiences: 1) Raw Device as Partition on a local HD 2) Raw Device as Partition on a local Software Raid (Level 1 or 10, MDADM) 3) Raw Device as Partition on a local Hardware Raid (Level 1 or 10) (take a look at the cache of the controller an the hard disks) 4) Raw Device as Volume or part of a Volume on a FC attached Raid (Level ?, how many disks ? FC speed ? Cache on Controller ?) 5) Raw Device as LVM slice of each (1-4) (LVM is nice to handle because you have names for your devices and you do not have to care about limits of partition tables like in old times, but LVM is also a drawback in terms of speed) 6) For Cooked files: as already stated, depends on the filesystem (preferably ext2 on Linux from my point of view), and of course on the same decisions as stated above (what device is "under" the filesystem) DIRECT_IO is mandatory in this case. 7) Did not try cooked devices ... For our production systems, we mostly use a Raid 10 with > 6 hard disks, 8GBit/16GBit FC (or faster), Array with enough cache memory, which can reach >700mB/s write speed. (by the way, no RAID 5 ...) For Informix usage, we assign the devices to LVM and create raw chunks on lvm partitions. We found this is reducing the speed by about 3-5%. On testing systems, we often use cooked files, since these are easy to copy for testing purposes (setting up a DB, saving it , apply some tests, which change the DB, restore the DB to previous state by just copying the device back and start all over again ...) Marcus Haarmann ----- Ursprüngliche Mail ----- Von: "Richard Kofler" <richard.kofler@chello.at> An: ids@iiug.org Gesendet: Mittwoch, 15. Oktober 2014 09:06:39 Betreff: Re: Cooked VS Raw [33975] Am 14.10.2014 22:03, schrieb NATE HICKS: > Any bold opinions on cooked files vs raw space? I know previously I had been > told by many that the raw option was far faster because of HDD speeds. Since > most things aren't single drives anymore I assume that this has changed some? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > for some time now a simple answer is no longer to this question. It depends on many 'legacy style'- details - virtual or not and if so, what is the hypervisor? Running as virtual appliance it depends on the tuning steps done for the hypervisor. Expect huuuge additional I/O latency flattening the differences between random I/O on disk versus random I/O on SSDs. Running on virtual I/O also means that there is no sequential I/O anymore - seen from the perspective of the hypervisor. Data load speed comes mind and also LRU writes versus syncing the buffer cache to disk during checkpoints - OS? - subsystem? And if so, what is it and what is the ratio controller cache size to sum of all disk space cached by this controller. It is shocking to see, that on not so few I/O subsystems this ratio of cache size to disk space is not better that on-platter cache to platter size. And what ist the bandwith to the subsystem and how many hosts share this bandwith. - if on cooked files, what is the mount setting of the underlying file system? From mailserver setup tuning ( mailserver == very many small files ) we found how important it is NOT to update meta data when reading, else you have no reads anymore but 1 read, 2 writes (man mount, atime) - finally it depends, if you have an average workload type 4+:1 read:write or not. On Linux - and on Redhat this is a starting point https://access.redhat.com/solutions/54164 dic_k --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.