Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Jose:

Yes, you should always extend the last chunk in the dbspace. I have several clients where we set the "E"xtendable flag on for the last chunk in each dbspace to "on" and just let the engine extend chunks as needed. One of those clients has two instances each of which have over 600 chunks that extend themselves while online frequently as these are, like yours, 24x7 operations. Most dbspaces there are single chunk dbspaces. There is no problem extending a chunk during normal operations. For a large extend like this one, I would just plan to do it when the client sessions are least likely to be modifying data on that dbspace, or are less affected if an insert/update/delete pauses for a bit, as there will be a lock on the dbspace during the extend operation that will block/pause those transactions.

Art

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

I'll throw in my 2c here too.

1) Years ago when inflating or extending a cooked chunk we would write every blank page out to disk--it might have been 1MB writes but either way it made this process a bit slow for large allocations. In V14 we use fallocate() (unless you've explicitly disabled that feature) which should make for a very fast inflation/extension. This doesn't apply to raw devices obviously, because they never need inflating.

2) I also can't think of any reason to favor the last chunk or any particular chunk in a dbspace for extension. All chunks in a space are linked (starting with "fchunk" as shown in onstat -d) and when scanning them for a free extent we'll follow all those links in order. So in theory your extent allocation performance should be best when the first chunk in the list has plenty of space. It's a fast scan either way though, so in a live environment you shouldn't really notice the difference.

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Thanks for the follow up John.

Just to explain my reasoning for only marking the last chunk in the dbspace for extending:

• Today with filesystem chunks, I usually set up clients to mark the initial chunk of a dbspace as extendable.
• Typically most chunks will be allocated in a single FS (or a handful of FSs). Typically the only reason to add a chunk to a dbspace is if the FS fills and cannot be itself expanded. That means that by only marking the new/last chunk as extendable the engine can ignore trying to extend the older chunks which most likely are living on a full FS. 
• I can see no good reason to mark every chunk in a dbspace as extendable.

Art

I'll throw in my 2c here too.

1) Years ago when inflating or extending a cooked chunk we would write every blank page out to disk--it might have been 1MB writes but either way it made this process a bit slow for large allocations. In V14 we use fallocate() (unless you've explicitly disabled that feature) which should make for a very fast inflation/extension. This doesn't apply to raw devices obviously, because they never need inflating.

2) I also can't think of any reason to favor the last chunk or any particular chunk in a dbspace for extension. All chunks in a space are linked (starting with "fchunk" as shown in onstat -d) and when scanning them for a free extent we'll follow all those links in order. So in theory your extent allocation performance should be best when the first chunk in the list has plenty of space. It's a fast scan either way though, so in a live environment you shouldn't really notice the difference.

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Thanks Art. That all makes sense. I don't know if this helps but one thing to note is that if the server fails to extend a chunk for any reason it will automatically remove the "extendable" flag so it doesn't keep banging its head against the wall. My hope is that there's some self-adjustment in the scenario you describe.

-jc

Thanks for the follow up John.

Just to explain my reasoning for only marking the last chunk in the dbspace for extending:

• Today with filesystem chunks, I usually set up clients to mark the initial chunk of a dbspace as extendable.
• Typically most chunks will be allocated in a single FS (or a handful of FSs). Typically the only reason to add a chunk to a dbspace is if the FS fills and cannot be itself expanded. That means that by only marking the new/last chunk as extendable the engine can ignore trying to extend the older chunks which most likely are living on a full FS. 
• I can see no good reason to mark every chunk in a dbspace as extendable.

Art

I'll throw in my 2c here too.

1) Years ago when inflating or extending a cooked chunk we would write every blank page out to disk--it might have been 1MB writes but either way it made this process a bit slow for large allocations. In V14 we use fallocate() (unless you've explicitly disabled that feature) which should make for a very fast inflation/extension. This doesn't apply to raw devices obviously, because they never need inflating.

2) I also can't think of any reason to favor the last chunk or any particular chunk in a dbspace for extension. All chunks in a space are linked (starting with "fchunk" as shown in onstat -d) and when scanning them for a free extent we'll follow all those links in order. So in theory your extent allocation performance should be best when the first chunk in the list has plenty of space. It's a fast scan either way though, so in a live environment you shouldn't really notice the difference.

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

John:

The self-adjustment is that when I set up a server that way, I will also configure storage pool entries for all of the file systems designated for Informix chunk use so that if the FS supporting a chunk does fill up, the dbspace is expanded with a new chunk from one of the other FSs. Then someone has to notice that a new chunk was created and mark it as extendable (I actually have a script, make_all_extendable, that will mark the last chunk of each dbspace that is not already so marked). It would be nice to have an alarm code for "chunk added" and for "chunk extended" so that this and other related maintenance can be automated. RFE???

Art

Thanks Art. That all makes sense. I don't know if this helps but one thing to note is that if the server fails to extend a chunk for any reason it will automatically remove the "extendable" flag so it doesn't keep banging its head against the wall. My hope is that there's some self-adjustment in the scenario you describe.

-jc

Thanks for the follow up John.

Just to explain my reasoning for only marking the last chunk in the dbspace for extending:

• Today with filesystem chunks, I usually set up clients to mark the initial chunk of a dbspace as extendable.
• Typically most chunks will be allocated in a single FS (or a handful of FSs). Typically the only reason to add a chunk to a dbspace is if the FS fills and cannot be itself expanded. That means that by only marking the new/last chunk as extendable the engine can ignore trying to extend the older chunks which most likely are living on a full FS. 
• I can see no good reason to mark every chunk in a dbspace as extendable.

Art

I'll throw in my 2c here too.

1) Years ago when inflating or extending a cooked chunk we would write every blank page out to disk--it might have been 1MB writes but either way it made this process a bit slow for large allocations. In V14 we use fallocate() (unless you've explicitly disabled that feature) which should make for a very fast inflation/extension. This doesn't apply to raw devices obviously, because they never need inflating.

2) I also can't think of any reason to favor the last chunk or any particular chunk in a dbspace for extension. All chunks in a space are linked (starting with "fchunk" as shown in onstat -d) and when scanning them for a free extent we'll follow all those links in order. So in theory your extent allocation performance should be best when the first chunk in the list has plenty of space. It's a fast scan either way though, so in a live environment you shouldn't really notice the difference.

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

A couple more notes.

If the server creates a chunk from a directory entry in the storage pool, as you know it will create a new cooked file in the directory and use it for the chunk. If its space is a regular dbspace we'll automatically mark that new chunk as extendable, so you shouldn't need to do that by hand... Have I missed something?

When the server adds a chunk dynamically there is already an alarm invoked: Severity 3, Class ID 79, Event ID 79001. However, we do not invoke an alarm when dynamically extending a chunk. We should do that. And as Paul said we should also invoke an alarm when internally disabling extendability for a chunk due to an out-of-space or other error.

Sound like a plan? Let me know if I've forgotten anything. Tx.

John:

The self-adjustment is that when I set up a server that way, I will also configure storage pool entries for all of the file systems designated for Informix chunk use so that if the FS supporting a chunk does fill up, the dbspace is expanded with a new chunk from one of the other FSs. Then someone has to notice that a new chunk was created and mark it as extendable (I actually have a script, make_all_extendable, that will mark the last chunk of each dbspace that is not already so marked). It would be nice to have an alarm code for "chunk added" and for "chunk extended" so that this and other related maintenance can be automated. RFE???

Art

Thanks Art. That all makes sense. I don't know if this helps but one thing to note is that if the server fails to extend a chunk for any reason it will automatically remove the "extendable" flag so it doesn't keep banging its head against the wall. My hope is that there's some self-adjustment in the scenario you describe.

-jc

Thanks for the follow up John.

Just to explain my reasoning for only marking the last chunk in the dbspace for extending:

• Today with filesystem chunks, I usually set up clients to mark the initial chunk of a dbspace as extendable.
• Typically most chunks will be allocated in a single FS (or a handful of FSs). Typically the only reason to add a chunk to a dbspace is if the FS fills and cannot be itself expanded. That means that by only marking the new/last chunk as extendable the engine can ignore trying to extend the older chunks which most likely are living on a full FS. 
• I can see no good reason to mark every chunk in a dbspace as extendable.

Art

I'll throw in my 2c here too.

1) Years ago when inflating or extending a cooked chunk we would write every blank page out to disk--it might have been 1MB writes but either way it made this process a bit slow for large allocations. In V14 we use fallocate() (unless you've explicitly disabled that feature) which should make for a very fast inflation/extension. This doesn't apply to raw devices obviously, because they never need inflating.

2) I also can't think of any reason to favor the last chunk or any particular chunk in a dbspace for extension. All chunks in a space are linked (starting with "fchunk" as shown in onstat -d) and when scanning them for a free extent we'll follow all those links in order. So in theory your extent allocation performance should be best when the first chunk in the list has plenty of space. It's a fast scan either way though, so in a live environment you shouldn't really notice the difference.

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Thanks Art. That all makes sense. I don't know if this helps but one thing to note is that if the server fails to extend a chunk for any reason it will automatically remove the "extendable" flag so it doesn't keep banging its head against the wall. My hope is that there's some self-adjustment in the scenario you describe.

-jc

Thanks for the follow up John.

Just to explain my reasoning for only marking the last chunk in the dbspace for extending:

• Today with filesystem chunks, I usually set up clients to mark the initial chunk of a dbspace as extendable.
• Typically most chunks will be allocated in a single FS (or a handful of FSs). Typically the only reason to add a chunk to a dbspace is if the FS fills and cannot be itself expanded. That means that by only marking the new/last chunk as extendable the engine can ignore trying to extend the older chunks which most likely are living on a full FS. 
• I can see no good reason to mark every chunk in a dbspace as extendable.

Art

I'll throw in my 2c here too.

1) Years ago when inflating or extending a cooked chunk we would write every blank page out to disk--it might have been 1MB writes but either way it made this process a bit slow for large allocations. In V14 we use fallocate() (unless you've explicitly disabled that feature) which should make for a very fast inflation/extension. This doesn't apply to raw devices obviously, because they never need inflating.

2) I also can't think of any reason to favor the last chunk or any particular chunk in a dbspace for extension. All chunks in a space are linked (starting with "fchunk" as shown in onstat -d) and when scanning them for a free extent we'll follow all those links in order. So in theory your extent allocation performance should be best when the first chunk in the list has plenty of space. It's a fast scan either way though, so in a live environment you shouldn't really notice the difference.

Hi Jose,

from your description I'm assuming we're talking raw chunks here, as opposed to file system files?
One difference this would make: the extension operation would be much faster as it wouldn't have to "inflate" a file.  So the chunk wouldn't be blocked for so long for others trying to allocate some space from it.
This probably also is the reason you're allocating all the new space in one go, then removing extensibility again - rather than letting the chunks grow by themselves?

I'd not see a reason to prefer one chunk, e.g. the last one, over others in same dbspace for this operation, nor one to not apply this expansion to multiple or all chunks in the space.

Since you also mentioned sbspaces:  neither sbspaces nor blobspaces currently support chunk extension, so you'd have to resort to adding new chunks there.

Cheers,
 Andreas

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

------------------------------
Jose
------------------------------

Hi, thank you for all the answers.

Yes we are using raw devices (or bock devices since they are marked with a 'b'):  brw-rw---- 1 informix informix 254, 266 Jun  3 10:07 /dev/dm-266

We are finaly planning to extend many (124) chunks, so instead of having the last, or one, chunk in a dbspace a lot bigger than the rest, we thought it could make sense to extend all chunks in a dbspace in equal increments. So we will

• For 5 data 2K dbspaces, with a total of 55 chunks (11 per dbspace) current having 50GB each, we will increment each with 15GB, adding a total of 825GB. So the new size will be 65GB per chunk.
• For 5 index 2K dbspaces we will add 6GB to each of its chunks (45 chunks wich current have 50GB each). So the new size will be 56GB per chunk.
• For 3 data 16K dbspaces, with a total of 4 chunks each of currently 100GB, will increment 25GB each.
• The 3 index 16K dbspaces, with 4 chunks each. will also grow its chunks in 25GB each..

So the plan is to perform the following tasks On-Line when no backup is running and when there is less activity in the system: 

• mark all affected chunks as Extentable ('E' flag)
• extend each chunk in the desired amount in KB
• unmark all chunks removing the 'E' flag.

We have a test system, a clon of production, so will test procedure first.

Best regards,

------------------------------
Jose Manuel Ruiz Gallud

Original Message:
Sent: Wed June 11, 2025 05:22 AM
From: Jose Manuel Ruiz Gallud
Subject: Extending chunk capacity

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

------------------------------
Jose
------------------------------

Hi,

A little question on this topic in case the dbspace had been extended a little bit to far ;-)

Is there meanwhile an option to decrease a size of a chunk or dbspace rather than export the db, drop dbspace, re-create and import the db? 

We do extend by EXECUTE FUNCTION tasks (mark to extend, extend, unmark) and are quite happy with it, but for some spaces we do see a lot of free space whithin, i.e. as some db's got dropped or moved.

We're using IDS 14.10.FC4W1 on AIX.

Hi, thank you for all the answers.

Yes we are using raw devices (or bock devices since they are marked with a 'b'):  brw-rw---- 1 informix informix 254, 266 Jun  3 10:07 /dev/dm-266

We are finaly planning to extend many (124) chunks, so instead of having the last, or one, chunk in a dbspace a lot bigger than the rest, we thought it could make sense to extend all chunks in a dbspace in equal increments. So we will

• For 5 data 2K dbspaces, with a total of 55 chunks (11 per dbspace) current having 50GB each, we will increment each with 15GB, adding a total of 825GB. So the new size will be 65GB per chunk.
• For 5 index 2K dbspaces we will add 6GB to each of its chunks (45 chunks wich current have 50GB each). So the new size will be 56GB per chunk.
• For 3 data 16K dbspaces, with a total of 4 chunks each of currently 100GB, will increment 25GB each.
• The 3 index 16K dbspaces, with 4 chunks each. will also grow its chunks in 25GB each..

So the plan is to perform the following tasks On-Line when no backup is running and when there is less activity in the system: 

• mark all affected chunks as Extentable ('E' flag)
• extend each chunk in the desired amount in KB
• unmark all chunks removing the 'E' flag.

We have a test system, a clon of production, so will test procedure first.

Best regards,

------------------------------
Jose Manuel Ruiz Gallud

Original Message:
Sent: Wed June 11, 2025 05:22 AM
From: Jose Manuel Ruiz Gallud
Subject: Extending chunk capacity

Hi, in a 24x7 Informix v14.10, x86 SuSE linux instance with 2KB and 16K dbspaces and smart-blobspaces, with +250 chunks, we neede to grow the disk capacity and we are considering the option of extend chunk capacity instead of adding new chunks. We have successfully tested the following commands:

• dbaccess sysadmin <<!
• -- we select the chunk we want to extend (onstat -d), chunk #7, and mark it as 'extendable', after execution with onstat -d we check new flag 'E' on chunk
  EXECUTE FUNCTION task("modify chunk extendable", "7");
• -- This chunk had 1GB capacity, but using the volume manager we have extended it so it now has 5GB. This means we can extend the chunk in 4GB=4194304K
• -- we can double check with dd command that the logical volume has indeed 5GB capacity (dd if=/informix/links/chunk7 of=/dev/null )
  EXECUTE FUNCTION task("modify chunk extend", "7", "4194304");
• -- we can check with onstat -d the new size (in 2K pages)
• -- We unmark chunk7 removing the 'E' flag.
  EXECUTE FUNCTION task("modify chunk extendable off", "7");
• !

All worked very well in a test environment. Now the doubts:

-. In a large system with many chunks per dbspace, if i had to choose one, i would be extending the last chunk added to each dbspace (???).

-. Since this is done with API Admin calls we cannot extend chunks in Quiescent mode, so i would recommend executing the commands in single user mode (onmode -j). Any issues if we did it in On-Line mode ?

any othe considerations ?

Best regards!

------------------------------
Jose
------------------------------