How Large should the zdb Files be?

[mgibeault]

Hi Mike,

Yep I checked it. I never compressed Outlook data files by fear of a slowdown.
But I added the registry entries found at How to configure the size limit for both (.pst) and (.ost) files in Outlook 2007 and in Outlook 2003. It should take care of this problem.

But still the suggestion by Rubble that a mode would allow the connector to " queries zimbra headers, fetches bodies on demand, etc? Fetch a month of data at a time" would be a big step forward.

Thanks,

-Marc

[mmorse]

You might add those notes to the bug if you think the 'month at a time' has merit, but that seems like a lot of work to setup/manage. 'Just select which folders to sync' is probably good enough for most.
Yup, I think 'mode where headers are always sync'd and messages are loaded when they're viewed' would work wonders though Bug 11962 - Sync Mode: Headers Only, Rest On Demand -as long as people know how the mode works


For shared folders that would be:
Bug 11418 - user selects which shared folders to mount

Currently in ZCO whenever you access any item in a delegate mailbox, all items you have access to are synced. The user should be allowed to select which
folders of all the folders accessable in the delegate mailbox should be synced. This set of folders should be modifiable (add/remove) at any time through an
extended UI.

[mgibeault]

Hi,

Yep, selecting wich folder to sync is an important feature.
But when I looked at the "HSM" setting in the admin console, I thought it would let me enter a number of days (I put 150) and then all messages older than 150 days would be kind of archived on the server, unloaded from the clients, but available through searches or a special command.
Most users have folders setup for each client. They can have clients for several years and thousands of e-mails, so it would be worthless to select some for sync -or not sync.
But it would be nice for shared folders; here we only share a few calendars and contacts. There are a lot of superfluous stuff exchanged.

-Marc

[mmorse]

Originally Posted by mgibeault

But when I looked at the "HSM" setting in the admin console, I thought it would let me enter a number of days (I put 150) and then all messages older than 150 days would be kind of archived on the server, unloaded from the clients, but available through searches or a special command.

Not quite, Hierarchical Storage Management (HSM) has nothing to do with ZCO.
Messages and attachments are moved from a primary volume to the current secondary volume based on the age of the message; completely transparent to the user.

ie: It let's you easily offload data server-side from one storage solution to another automatically based on date; like after say 30 days from your fast SCSI/more expensive solution, and therefore you tend to have less of it. > To a SAN of SATA's or something/usually cheaper, and thus more abundant.

It's nothing that the end-users have to configure; and most would be hard pressed to notice a difference, as they're mostly working with the recent stuff anyway.
ie: Your searches for older stuff in the web-client are just a tad slower, for all intensive purposes practically unnoticeable. It's just the time difference in speed between your SCSI & SATA disks. The same would go for grabbing data with a thick-client, etc.

For that, these are some cool RFE's to track as well:
Bug 18720 - Add support for more than one current secondary storage volume in HSM & Bug 18850 - multiple "current" primary, secondary, index zmvolumes
Bug 9178 - Folder based HSM/aging > Bug 6542 - Zimbra Message Store & HSM Aging Policies

[mgibeault]

Maybe my post was not clear, English is not my primary language.
I know that "HSM has nothing to do with ZCO". But I was trying to explain that would be a great feature.
Right now HSM is not very interesting. With the low cost of big fast disks, I can add terabytes of space in a matter of minutes.
Imagine the benefits if this was propagated to the clients. It would ensure that everybody keeps a not-so-huge data file.

-Marc

[mmorse]

gotcha, I see what your getting at though