Re: moving from raw chunks to cooked files

See my comments below. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, 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 Wed, Aug 25, 2010 at 12:17 PM, Aleksander Kamenik < aleksander@krediidiinfo.ee> wrote: > > Yeah, Linus has been trying to get rid of RAW files for many years. I > > wish he'd just give it up. Anyway, there is no problem using cooked > > files, and migrating the data is as simple as dd'ing the data from the > > RAW devices to new filesystem files and then relinking the link paths > > that IDS using to access the RAW devices to the filesystem files. > > This would create 2 files instead of 2 raw devices. Any way to split the > raw device into separate files where each file would corresponding to a > chunk? I think it might be possible using dd's skip and count options. > Ahh, I didn't understand that you are using two large RAW devices and using offsets to create several chunks in each device. OK, you have two options: 1. Create one big file for each raw device replacement and continue using the existing offsets, or 2. Use ontape or onbar to archive your server (which you should be doing already) then create (ie touch) the new filesystem files one for each chunk, and restore the server from the archive using ontape/onbar chunk renaming feature to migrate each chunk into a new filesystem file with a zero offset. You can't just use dd with skip and count to copy the data from the two large raw devices into many smaller files because Informix expects that the data for each chunk is located at a specific offset from the beginning of the file. > > How I can I change paths in Informix? root dbs is specified in the onconfig > file and that's in one chunk fortunately, but I don't know how to change the > paths for all the other chunks. I also don't know what you mean by > relinking. > OK, two separate questions. As to links, the path that you give to onspaces when you create a new chunk (and that you place into the ROOTPATH parameter in the ONCONFIG file, should NEVER be the actual path to the file or device but a symbolic link. That allows you to easily move chunks from one device to another without Informix having to know about it at all. This was VERY important prior to Informix 10.00 because there was no facility to rename chunks prior to that release. Currently you can rename chunk paths using ontape or onbar, but ONLY during a restore of the server from an archive. Since this is usually a lengthy process it remains more convenient to use symbolic links whenever possible. So, what I'm saying is that in the new storage, you will have chunks in say three filesystems. Let's call them /informix/disks_1, /informix/disks_2, and /informix/disks_3. I'm recommending that instead of using those paths when you pass the chunk paths to ontape/onbar to remap them from the RAW devices, create another directory, say /informix/all_disks. While in /informix/disks_1 you will have chunk files named something like dbspace_1_chunk_1, and dbspace_1_chunk2 and in /informix/disks_2 you will have chunk files named something like dbspace_2_chunk_1, etc. You will then create links in /informix/all_disks for all of those chunks and use the link's paths instead of the actual file paths. That way if someday you add a new set of disks and decide to spread the load around to the new filesystem it will just be a matter of shutting down the engine, copying the file(s) to the new filesystem, and changing the appropriate links in /informix/all_disks to point to the new file locations and restarting the engine. no muss, no fuss, no restore needed. For new, because you will have to change offsets from non-zero ones to zeros, and from two paths for all chunks to many different paths, you will have no option really other than to do a restore or to live with just two huge files. > > You > > should use the simplest filesystem available, no journalled filesystems > > like EXT3 and EXT4. I would suggest just using an old EXT2 filesystem > > as the best choice. It's very low overhead compared to the more modern > > filesystems. > > Makes sense, thanks. > > > Another option, BTW, would be to use COOKED (aka block) devices rather > > than filesystem files. COOKED devices tend to be a little faster than > > filesystem files even with DIRECT_IO enabled on both. > > What do you mean by that; that each chunk or set of chunks would have their > own partition on disk? So instead on /dev/raw/raw1 I'd have /dev/sda1 for > example? > Yes, exactly. On other UNIX-like OSes (than Linux) all RAW devices have a directly corresponding COOKED device through the single disk device driver, so you would just have to relink your chunk paths from the RAW device to point to the COOKED device and restart the engine. POOF! In Linux, since the RAW devices are not handled by the same OS driver as COOKED devices, and the physical data layout is not identical (RAW devices have some hidden overhead at the beginning of the device's storage that's not part of the device's data area), you can't get away that easy. You would have to copy the data from the RAW device to a COOKED device. If you will need to create the COOKED devices on the same storage you are using for the RAW data now, that would probably mean either having some intermediate storage (copy from RAW to intermediate, destroy RAW, create COOKED, copy data to COOKED) or going through the ontape/onbar restore process after destroying the RAW devices and recreating them as COOKED devices. > > > > > Aleksander Kamenik > System Administrator > Krediidiinfo AS > an Experian Company > Phone: +372 665 9649 > Email: aleksander@krediidiinfo.ee > > http://www.krediidiinfo.ee/ > http://www.experiangroup.com/ > > > > > Art > > > > Art S. Kagel > > Advanced DataTools (www.advancedatatools.com) > > IIUG Board of Directors (art@iiug.org) > > > > Disclaimer: Please keep in mind that my own opinions are my own > > opinions and do not reflect on my employer, Advanced DataTools, 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 Wed, Aug 25, 2010 at 10:43 AM, Aleksander Kamenik > > <aleksander@krediidiinfo.ee> wrote: > > > > > > Hi, > > > > We're running Suse Linux Enterprise Server on x86 and with the > > latest SLES11SP1 release notes comes this announcement: > > > > "The RAW devices are deprecated and will be removed with one of > > the next Service Packs or SUSE Linux Enterprise Server 12.@