extreme free space difference

[ksanders99]

If I run a sxdu -as, I get a value of ~57GB, which is roughly what the SAC reports (it says that the total message store is ~58gb out of 136gb used, with 78gb of free space).

However, If I do a df -h, the scalix volume is ~122 gb used. Doing a du -sh *, the /var/opt/scalix/data directory is 123 million bytes by itself. I ran sxdu -b, and it's only 1.

Next, I ran omscan -A -u -o 0 -e. The total sizes came out to ~108 m bytes.

We're still using Scalix 10.0.0.354 (I have v. 11 to upgrade to when I get a chance) running on SLES 9.3. The scalix volume is an LVM volume.

Do I need to run a reindexing/compressing utility of some sort to try to rectify the differences in size? Which values are accurate?

thanks,
Keith

[florian]

the values reported by sxdu and SAC are coming from a counted size that tracks additions and changes. in rare situations, this number can get off, though usually the difference should not be as large as you report.

however, you should fix those up as the first step.

to do this...
- log out all users
- make sure users can no longer login (omoff -d 0 -w rci)
- make sure no more user is logged in (omstat -u all)

then.....
- run omscan -AafS

The relevant parameter here is -S which will correct the container size information.

Let us know how this goes,
Florian.

[ksanders99]

Hi Florian,

I did that - omscan corrected the values for the total mailbox size to fall in line with what sxdu -as and the SAC were reporting - the total mailstore is around 60GB. I'm pretty sure that this is accurate, since we were running at around 40GB of use before migrating about a dozen final large mailusers to the server, the largest of which had about a 4GB mailstore previously.

However, the size of the /var/opt/scalix/data directory didn't change when you run du -sh * - it's still ~122GB in size. Since that's 93% of the disk volume, I'm concerned about running out of space. Will it self-correct now that it knows the real size?

thanks,
Keith

[ivo_toshev]

ksanders99.

Months ago i realized that the storage reported by scalix and the real, reported by df is different.

Florian answered to my question about this, that for some message scalix keeps MIME copy ( i didnt remember, but was somehow related to IMAP ). So - you have around 60GB, reported by Scalix. Double it - and you will get 120 GB.

[florian]

while in that "extreme" sense this was only true for messages imported through IMAP during migration to Scalix. it won't be true for messages received within Scalix.

Florian.

[ivo_toshev]

Yes Florian,

But because they talk about migration of very large mailboxes... maybe trough IMAP.
And the most important question is what will happen when if he runs out of disk space ? Or Scalix store will overwrite those MIME copies ?

[ksanders99]

That's definitely the case with us - anyone who was converted was converted by copying their messages up via Imap. Do I need to just go ahead and upgrade the disks in order to make free space then?

thanks,
Keith

[florian]

you might want do check out which of your subdirectories contains most of the data, i.e. do a

Code: Select all

du -hs /var/opt/scalix/??/s/*

If the bulk of the data is in ./user and ./data, that's probably the case; if it is in "temp", you might be able to delete the stuff in there (while the server is down).

note that your ongoing disk space usage will be much smaller for messages arriving in Scalix from now on.

If one wants to avoid this extra use of diskspace for migration, you can import data through the Outlook connector and outlook and/or through one of our migration tools available from Scalix (providing for PST to Scalix and IMAP to Scalix - via 3rd Party tool - migration; as those are importing through MAPI, they won't have the same issue)

Cheers,
Florian.

[ivo_toshev]

So - probably you must upgrade the disk storage as soon as possible just in case.

[ksanders99]

Thanks for the help - I'll make plans to upgrade the disks this weekend to be on the safe side. It's probably a good time to upgrade to v. 11 while I'm doing it.

thanks,
Keith

[ivo_toshev]

v.11.0.1 is really stable. But - make backup before the upgrade.

[ivo_toshev]

Florian - i have a question:

Lets say that one mailbox of 1GB is migrated using ordinary imapcopy tools.
So - on the server HDD it will took 2GB of space.

Now, after 6 montsh, the user time-to-time deletes the old mai at all.l And the total mount of new mail is 500MB.

Is that mean, that now on HDD his mailbox will be 1,5GB ?

[florian]

ivo,

don't understand your calculation here...

- if the user has deleted all his old mail, his diskspace usage would be 0.
- if while doing so, he receives 500MB in new mail, his diskspace usage would be roughly 500MB, because for new mail, data is only stored once.

???
Florian.

[ivo_toshev]

Florian - you are right , and you answered my question. When i mean delete i delete in mi mind just a mime copy, but not the whole message.

[fabio]

you might want do check out which of your subdirectories contains most of the data, i.e. do a

Code: Select all

du -hs /var/opt/scalix/??/s/*

If the bulk of the data is in ./user and ./data, that's probably the case; if it is in "temp", you might be able to delete the stuff in there (while the server is down).

note that your ongoing disk space usage will be much smaller for messages arriving in Scalix from now on.

If one wants to avoid this extra use of diskspace for migration, you can import data through the Outlook connector and outlook and/or through one of our migration tools available from Scalix (providing for PST to Scalix and IMAP to Scalix - via 3rd Party tool - migration; as those are importing through MAPI, they won't have the same issue)

Cheers,
Florian.

Hi Florian,
I am migrating from Zimbra to Scalix 11.0.1, but I have realized that using imapsync to transfer the mail the space occupied by the mail on scalix is very greater (around the double one).
Is there a tool to clean the MIME copies produced by the transfer IMAP?
How does it suggest me to transfer the mail?

Thanks in advance for the help.

Fabio