Offset in a new chunk
Question: when adding a chunk to a dbspace, must the offset be 0? Answers: no, it can be anything, but 0 is normal. For cooked/filesystem chunks the offset is essentially always 0, since there's no reason to pack multiple chunks into one file. A non-zero offset is only needed when several chunks share one raw device/LUN (each subsequent chunk offset by the sizes of the previous ones), or with old partitioning tools like fdisk that keep the partition table in the first blocks, which a zero-offset chunk would overwrite. For the poster's case of a new filesystem/device in the same array, offset 0 was confirmed as fine; Informix should also refuse to overwrite an existing chunk.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, When adding a chunk to a dbspace the offset must be 0 ? Thanks in advance. Enviado desde mi iPhone
Simple answer: No, the offset can be anything. Complete answer: Typically for file system based chunks the offset is always zero since there is no good reason to place multiple chunks in a single file system file. For RAW chunks the offset will depend on whether the underlying lun/device is supporting multiple chunks in a single device. In that case all but the first chunk will be offset by the sizes of all of the previous chunks defined in that device (plus the offset of the first chunk). The offset of the first chunk defined on a raw device might be zero or it might be a small number depending on how the device/lun was defined. If you use an old style partitioning utility like fdisk to partition a physical drive then you may need a non-zero offset for the first chunk defined on the first partition carved from the drive because some of those partitioners place the partition table in the first blocks of that first device. In that case, if you don't leave an offset, the chunk will overwrite the partition table and make the drive unusable the next time the system boots. Most modern partitioning utilities, including all volume managers for SANs that I am aware of, place their partitioning tables outside of any lun or device that is defined for use so you should be able to use a zero offset everywhere (again except if you have more than one chunk packed into a single device or lun). Art Art S. Kagel, Principal Consultant ASK Database Management 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, Jun 24, 2014 at 6:24 PM, Jorge <jorgervt@gmail.com> wrote: > Hi, > > When adding a chunk to a dbspace > the offset must be 0 ? > > Thanks in advance. > > Enviado desde mi iPhone > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0160b42038f59b04fc9ccbaf
Ok, in my case. I have a file system that is part of an array. This file system was asigned to a dbspace of data. This dbspace is almost full, so I planning to create another file system in the same array and this like a chubk to the dbspace of data. In this case both file systems are in the same array but there are 2 devices, so I can put zero to the offset without any problem, am I correct? Enviado desde mi iPhone El 24/06/2014, a las 15:51, "Art Kagel" <art.kagel@gmail.com> escribió: > Simple answer: No, the offset can be anything. > > Complete answer: Typically for file system based chunks the offset is > always zero since there is no good reason to place multiple chunks in a > single file system file. > > For RAW chunks the offset will depend on whether the underlying lun/device > is supporting multiple chunks in a single device. In that case all but the > first chunk will be offset by the sizes of all of the previous chunks > defined in that device (plus the offset of the first chunk). > > The offset of the first chunk defined on a raw device might be zero or it > might be a small number depending on how the device/lun was defined. If > you use an old style partitioning utility like fdisk to partition a > physical drive then you may need a non-zero offset for the first chunk > defined on the first partition carved from the drive because some of those > partitioners place the partition table in the first blocks of that first > device. In that case, if you don't leave an offset, the chunk will > overwrite the partition table and make the drive unusable the next time the > system boots. > > Most modern partitioning utilities, including all volume managers for SANs > that I am aware of, place their partitioning tables outside of any lun or > device that is defined for use so you should be able to use a zero offset > everywhere (again except if you have more than one chunk packed into a > single device or lun). > > Art > > Art S. Kagel, Principal Consultant > ASK Database Management > > 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, Jun 24, 2014 at 6:24 PM, Jorge <jorgervt@gmail.com> wrote: > >> Hi, >> >> When adding a chunk to a dbspace >> the offset must be 0 ? >> >> Thanks in advance. >> >> Enviado desde mi iPhone > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0160b42038f59b04fc9ccbaf > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Is it a filesystem that you will be creating a file in for the chunk or is it a raw device that will be linked to the chunk path (ie a 'c'haracter device with a 'c' at the beginning of its ls -l entry? Hmm, either way, I suppose the answer is 'yes', a zero offset would be appropriate. Art Art S. Kagel, Principal Consultant ASK Database Management 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 Wed, Jun 25, 2014 at 5:07 PM, Jorge <jorgervt@gmail.com> wrote: > Ok, in my case. I have a file system that is part of an array. This file > system was asigned to a dbspace of data. This dbspace is almost full, so I > planning to create another file system in the same array and this like a > chubk > to the dbspace of data. > In this case both file systems are in the same array but there are 2 > devices, > so I can put zero to the offset without any problem, am I correct? > > Enviado desde mi iPhone > > El 24/06/2014, a las 15:51, "Art Kagel" <art.kagel@gmail.com> escribió: > > > Simple answer: No, the offset can be anything. > > > > Complete answer: Typically for file system based chunks the offset is > > always zero since there is no good reason to place multiple chunks in a > > single file system file. > > > > For RAW chunks the offset will depend on whether the underlying > lun/device > > is supporting multiple chunks in a single device. In that case all but > the > > first chunk will be offset by the sizes of all of the previous chunks > > defined in that device (plus the offset of the first chunk). > > > > The offset of the first chunk defined on a raw device might be zero or it > > might be a small number depending on how the device/lun was defined. If > > you use an old style partitioning utility like fdisk to partition a > > physical drive then you may need a non-zero offset for the first chunk > > defined on the first partition carved from the drive because some of > those > > partitioners place the partition table in the first blocks of that first > > device. In that case, if you don't leave an offset, the chunk will > > overwrite the partition table and make the drive unusable the next time > the > > system boots. > > > > Most modern partitioning utilities, including all volume managers for > SANs > > that I am aware of, place their partitioning tables outside of any lun or > > device that is defined for use so you should be able to use a zero offset > > everywhere (again except if you have more than one chunk packed into a > > single device or lun). > > > > Art > > > > Art S. Kagel, Principal Consultant > > ASK Database Management > > > > 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, Jun 24, 2014 at 6:24 PM, Jorge <jorgervt@gmail.com> wrote: > > > >> Hi, > >> > >> When adding a chunk to a dbspace > >> the offset must be 0 ? > >> > >> Thanks in advance. > >> > >> Enviado desde mi iPhone > > > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. > > > > --089e0160b42038f59b04fc9ccbaf > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0141a0a692dcbb04fcb01e0f
Offset 0 will be fine if your new chunk is in a new file or on a different device. The only time a non-zero offset is needed is when you add to an existing file or raw device. That prevents the new chunk from overwriting the old one. Incidentally, it should fail if you try to overwrite an existing chunk. --EEM > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Jorge > Sent: Wednesday, June 25, 2014 4:08 PM > To: ids@iiug.org > Subject: Re: Offset in a new chunk [33284] > > Ok, in my case. I have a file system that is part of an array. This > file system was asigned to a dbspace of data. This dbspace is almost > full, so I planning to create another file system in the same array and > this like a chubk to the dbspace of data. > In this case both file systems are in the same array but there are 2 > devices, so I can put zero to the offset without any problem, am I > correct? > > Enviado desde mi iPhone > > El 24/06/2014, a las 15:51, "Art Kagel" <art.kagel@gmail.com> escribió: > > > Simple answer: No, the offset can be anything. > > > > Complete answer: Typically for file system based chunks the offset is > > always zero since there is no good reason to place multiple chunks in > > a single file system file. > > > > For RAW chunks the offset will depend on whether the underlying > > lun/device is supporting multiple chunks in a single device. In that > > case all but the first chunk will be offset by the sizes of all of > the > > previous chunks defined in that device (plus the offset of the first > chunk). > > > > The offset of the first chunk defined on a raw device might be zero > or > > it might be a small number depending on how the device/lun was > > defined. If you use an old style partitioning utility like fdisk to > > partition a physical drive then you may need a non-zero offset for > the > > first chunk defined on the first partition carved from the drive > > because some of those partitioners place the partition table in the > > first blocks of that first device. In that case, if you don't leave > an > > offset, the chunk will overwrite the partition table and make the > > drive unusable the next time the system boots. > > > > Most modern partitioning utilities, including all volume managers for > > SANs that I am aware of, place their partitioning tables outside of > > any lun or device that is defined for use so you should be able to > use > > a zero offset everywhere (again except if you have more than one > chunk > > packed into a single device or lun). > > > > Art > > > > Art S. Kagel, Principal Consultant > > ASK Database Management > > > > 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, Jun 24, 2014 at 6:24 PM, Jorge <jorgervt@gmail.com> wrote: > > > >> Hi, > >> > >> When adding a chunk to a dbspace > >> the offset must be 0 ? > >> > >> Thanks in advance. > >> > >> Enviado desde mi iPhone > > > *********************************************************************** > ******** > >> Forum Note: Use "Reply" to post a response in the discussion forum. > > > > --089e0160b42038f59b04fc9ccbaf > > > > > > > *********************************************************************** > ******** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > *********************************************************************** > ******** > Forum Note: Use "Reply" to post a response in the discussion forum.
Thanks. Enviado desde mi iPhone El 25/06/2014, a las 14:54, "Art Kagel" <art.kagel@gmail.com> escribió: > Is it a filesystem that you will be creating a file in for the chunk or is > it a raw device that will be linked to the chunk path (ie a 'c'haracter > device with a 'c' at the beginning of its ls -l entry? > > Hmm, either way, I suppose the answer is 'yes', a zero offset would be > appropriate. > > Art > > Art S. Kagel, Principal Consultant > ASK Database Management > > 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 Wed, Jun 25, 2014 at 5:07 PM, Jorge <jorgervt@gmail.com> wrote: > >> Ok, in my case. I have a file system that is part of an array. This file >> system was asigned to a dbspace of data. This dbspace is almost full, so I >> planning to create another file system in the same array and this like a >> chubk >> to the dbspace of data. >> In this case both file systems are in the same array but there are 2 >> devices, >> so I can put zero to the offset without any problem, am I correct? >> >> Enviado desde mi iPhone >> >> El 24/06/2014, a las 15:51, "Art Kagel" <art.kagel@gmail.com> escribió: >> >>> Simple answer: No, the offset can be anything. >>> >>> Complete answer: Typically for file system based chunks the offset is >>> always zero since there is no good reason to place multiple chunks in a >>> single file system file. >>> >>> For RAW chunks the offset will depend on whether the underlying >> lun/device >>> is supporting multiple chunks in a single device. In that case all but >> the >>> first chunk will be offset by the sizes of all of the previous chunks >>> defined in that device (plus the offset of the first chunk). >>> >>> The offset of the first chunk defined on a raw device might be zero or it >>> might be a small number depending on how the device/lun was defined. If >>> you use an old style partitioning utility like fdisk to partition a >>> physical drive then you may need a non-zero offset for the first chunk >>> defined on the first partition carved from the drive because some of >> those >>> partitioners place the partition table in the first blocks of that first >>> device. In that case, if you don't leave an offset, the chunk will >>> overwrite the partition table and make the drive unusable the next time >> the >>> system boots. >>> >>> Most modern partitioning utilities, including all volume managers for >> SANs >>> that I am aware of, place their partitioning tables outside of any lun or >>> device that is defined for use so you should be able to use a zero offset >>> everywhere (again except if you have more than one chunk packed into a >>> single device or lun). >>> >>> Art >>> >>> Art S. Kagel, Principal Consultant >>> ASK Database Management >>> >>> 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, Jun 24, 2014 at 6:24 PM, Jorge <jorgervt@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> When adding a chunk to a dbspace >>>> the offset must be 0 ? >>>> >>>> Thanks in advance. >>>> >>>> Enviado desde mi iPhone > ******************************************************************************* >>>> Forum Note: Use "Reply" to post a response in the discussion forum. >>> >>> --089e0160b42038f59b04fc9ccbaf > ******************************************************************************* >>> Forum Note: Use "Reply" to post a response in the discussion forum. > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0141a0a692dcbb04fcb01e0f > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Thanks. Enviado desde mi iPhone El 25/06/2014, a las 14:57, "Everett Mills" <Everett.Mills@nationalbeef.com> escribió: > Offset 0 will be fine if your new chunk is in a new file or on a different > device. The only time a non-zero offset is needed is when you add to an > existing file or raw device. That prevents the new chunk from overwriting the > old one. Incidentally, it should fail if you try to overwrite an existing > chunk. > > --EEM > >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of >> Jorge >> Sent: Wednesday, June 25, 2014 4:08 PM >> To: ids@iiug.org >> Subject: Re: Offset in a new chunk [33284] >> >> Ok, in my case. I have a file system that is part of an array. This >> file system was asigned to a dbspace of data. This dbspace is almost >> full, so I planning to create another file system in the same array and >> this like a chubk to the dbspace of data. >> In this case both file systems are in the same array but there are 2 >> devices, so I can put zero to the offset without any problem, am I >> correct? >> >> Enviado desde mi iPhone >> >> El 24/06/2014, a las 15:51, "Art Kagel" <art.kagel@gmail.com> escribió: >> >>> Simple answer: No, the offset can be anything. >>> >>> Complete answer: Typically for file system based chunks the offset is >>> always zero since there is no good reason to place multiple chunks in >>> a single file system file. >>> >>> For RAW chunks the offset will depend on whether the underlying >>> lun/device is supporting multiple chunks in a single device. In that >>> case all but the first chunk will be offset by the sizes of all of >> the >>> previous chunks defined in that device (plus the offset of the first >> chunk). >>> >>> The offset of the first chunk defined on a raw device might be zero >> or >>> it might be a small number depending on how the device/lun was >>> defined. If you use an old style partitioning utility like fdisk to >>> partition a physical drive then you may need a non-zero offset for >> the >>> first chunk defined on the first partition carved from the drive >>> because some of those partitioners place the partition table in the >>> first blocks of that first device. In that case, if you don't leave >> an >>> offset, the chunk will overwrite the partition table and make the >>> drive unusable the next time the system boots. >>> >>> Most modern partitioning utilities, including all volume managers for >>> SANs that I am aware of, place their partitioning tables outside of >>> any lun or device that is defined for use so you should be able to >> use >>> a zero offset everywhere (again except if you have more than one >> chunk >>> packed into a single device or lun). >>> >>> Art >>> >>> Art S. Kagel, Principal Consultant >>> ASK Database Management >>> >>> 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, Jun 24, 2014 at 6:24 PM, Jorge <jorgervt@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> When adding a chunk to a dbspace >>>> the offset must be 0 ? >>>> >>>> Thanks in advance. >>>> >>>> Enviado desde mi iPhone >> *********************************************************************** >> ******** >>>> Forum Note: Use "Reply" to post a response in the discussion forum. >>> >>> --089e0160b42038f59b04fc9ccbaf >> *********************************************************************** >> ******** >>> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> *********************************************************************** >> ******** >> Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >