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!