Explain offset
Hello everybody, we're running a few informix servers. They grow historical in the past. Right now we have some new servers, so it's time to start finetune our systems. I already read and found a lot about tuning the systems and indeed... Our comp is running very fine right now ! Now I've read about the offset. But I can't find a logic explanation what it does and why we should give it a value. Can anyone help me out ? (We're running NTFS = Win2003) Thanks a lot, Bjorn
Bjorn De Waele wrote: > we're running a few informix servers. They grow historical in the past. > Right now we have some new servers, so it's time to start finetune our > systems. > > I already read and found a lot about tuning the systems and indeed... Our > comp is running very fine right now ! > > Now I've read about the offset. But I can't find a logic explanation what > it does and why we should give it a value. > > Can anyone help me out ? (We're running NTFS = Win2003) Offset - as in offset for a chunk? If that's wrong, explain what you're talking about. Assuming that's right, then... There have been various reasons why you might want to use a non-zero chunk offset. For example: /dev/rdsk/c0t1d0s1 - 1 GB total space. -- chunk 0 of dbspace1 at offset 0 MB, size 128 MB -- chunk 0 of dbspace2 at offset 128 MB, size 384 MB -- chunk 1 of dbspace1 at offset 512 MB, size 256 MB -- chunk 0 of sbspace1 at offset 768 MB, size 256 MB If you're using a cooked file, you can specify the initial size you want, and then extend it later, using the appropriate non-zero offset. In the bad old days, some volume managers used to write control information in the first few KB of the disk. If IDS tried to write there too, one of the systems got upset when the other prevailed and rewrote its material over the same space. So, on those systems, when using a raw device, you needed to use a non-zero offset for the start of the chunk to avoid such dual-use problems. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Hello Jonathan, this is exactly what I mean. Ok, I got the point about that offset. Probably for not overwriting eachother. But do you need to implement this always ? Under Windows, you can give raw disk space or use the NTFS. Do you need the offset too when you use your NTFS ? Or does NTFS arrange this then ? thank a lot, Newbie Bjorn :) "Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:QpYHc.11769$oD3.5245@newsread1.news.pas.earthlink.net... > Bjorn De Waele wrote: > > we're running a few informix servers. They grow historical in the past. > > Right now we have some new servers, so it's time to start finetune our > > systems. > > > > I already read and found a lot about tuning the systems and indeed... Our > > comp is running very fine right now ! > > > > Now I've read about the offset. But I can't find a logic explanation what > > it does and why we should give it a value. > > > > Can anyone help me out ? (We're running NTFS = Win2003) > > Offset - as in offset for a chunk? > > If that's wrong, explain what you're talking about. > > Assuming that's right, then... > > There have been various reasons why you might want to use a non-zero > chunk offset. > > For example: > > /dev/rdsk/c0t1d0s1 - 1 GB total space. > -- chunk 0 of dbspace1 at offset 0 MB, size 128 MB > -- chunk 0 of dbspace2 at offset 128 MB, size 384 MB > -- chunk 1 of dbspace1 at offset 512 MB, size 256 MB > -- chunk 0 of sbspace1 at offset 768 MB, size 256 MB > > If you're using a cooked file, you can specify the initial size you > want, and then extend it later, using the appropriate non-zero offset. > > In the bad old days, some volume managers used to write control > information in the first few KB of the disk. If IDS tried to write > there too, one of the systems got upset when the other prevailed and > rewrote its material over the same space. So, on those systems, when > using a raw device, you needed to use a non-zero offset for the start > of the chunk to avoid such dual-use problems. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
Bjorn De Waele wrote: > This is exactly what I mean. Ok, I got the point about that offset. > Probably for not overwriting each other. > > But do you need to implement this always? Under Windows, you can > give raw disk space or use the NTFS. Do you need the offset too > when you use your NTFS? Or does NTFS arrange this then? You use non-zero offsets when they'll be beneficial to you, for any convenient definition of beneficial. Most of the time, that means you'll be using an offset of zero. If you're using cooked files on NTFS, the only time you would ever need a non-zero offset is if you initially created a chunk in a file, and you subsequently decide you want to increase the size of the dbspace but don't want to create a new file. Then you'd simply set the offset of the new chunk to the end of the old one, and the new size, and off you'd go. I'll call this 'chunk stacking' - to coin a term - and showed how to do it for raw devices in my previous response. FWIW, if you're chunk stacking on cooked files, you should not do it across instances. Technically, you can do it - no problem - but it is a managerial disaster waiting to happen. (I've had to do chunk stacking across instances on raw devices for lack of disk space to do otherwise; it's still a managerial disaster, but there may be overriding reasons - like lack of any alternative raw devices - for doing so..) If you're using raw devices, you'd only use non-zero offsets for one of two reasons: 1. Chunk stacking 2. Because the o/s uses the first N KB of the raw device. If you can come up with a sensible alternative reason for using a non-zero offset, I'm listening. > "Jonathan Leffler" <jleffler@earthlink.net> wrote: >>Bjorn De Waele wrote: >>> we're running a few informix servers. They grow historical in >>> the past. Right now we have some new servers, so it's time to >>> start finetune our systems. >>> >>> I already read and found a lot about tuning the systems and >>> indeed... Our comp is running very fine right now ! Now I've >>> read about the offset. But I can't find a logic explanation >>> what it does and why we should give it a value. >>> >>>Can anyone help me out ? (We're running NTFS = Win2003) >> >> Offset - as in offset for a chunk? [...] There have been various >> reasons why you might want to use a non-zero chunk offset. >> >>For example: >> >>/dev/rdsk/c0t1d0s1 - 1 GB total space. >> -- chunk 0 of dbspace1 at offset 0 MB, size 128 MB >> -- chunk 0 of dbspace2 at offset 128 MB, size 384 MB >> -- chunk 1 of dbspace1 at offset 512 MB, size 256 MB >> -- chunk 0 of sbspace1 at offset 768 MB, size 256 MB >> > > If you're using a cooked file, you can specify the initial size you >> want, and then extend it later, using the appropriate non-zero >> offset. >> >> In the bad old days, some volume managers used to write control >> information in the first few KB of the disk. If IDS tried to >> write there too, one of the systems got upset when the other >> prevailed and rewrote its material over the same space. So, on >> those systems, when using a raw device, you needed to use a >> non-zero offset for the start of the chunk to avoid such dual-use >> problems. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/