Size limit in Attachments.MYD

Dear List,

In one month of running RT3, we have already come up with an Attachments.MYD
that is this large:

mysql> show table status;

| Name | Type | Row_format | Rows | Avg_row_length |
Data_length | Max_data_length | Index_length | Data_fre
e | Auto_increment | Create_time | Update_time | Check_time
| Create_options | Comment |

| Attachments | MyISAM | Dynamic | 3141 | 4438 |
13941260 | 4294967295 | 132096 |
0 | 3142 | 2004-02-25 08:29:15 | 2004-04-09 09:26:03 | 2004-02-25
08:29:15 | | |

Assuming a Linux limit of 2gb, obviously, we’re fast running out of space.

Even bumping mysql and adding ReiserFS, only gets us to 4GB max. Which
would be several weeks’ of history for our application, but not much more.

So what I was wondering is does RT on linux have an ability to run more than one
Attachments.MYD concurrent, and still have the content of all of them be
searchable ? Will RT when it hits the 2gb / 4gb line, just simply stop writing
attachments, will it fail with an error?

Any solutions / ideas welcome.

Kind regards,

Dave D

In one month of running RT3, we have already come up with an Attachments.MYD
that is this large:

Assuming a Linux limit of 2gb, obviously, we’re fast running out of space.

you’re assumption about linux and 2gb may be false.

Anyhow, I thought the mysql innodb docs discuss this.

seph

Dear List,

In one month of running RT3, we have already come up with an Attachments.MYD
that is this large:

mysql> show table status;

| Name | Type |
| Attachments | MyISAM |

Assuming a Linux limit of 2gb, obviously, we’re fast running out of space.

InnoDB has no such limit. And InnoDB is a hard requirement for RT.
You’ve configured your database incorrectly or you’re using an
unsupported older version