| Welcome to the Zimbra :: Forums! | |
Welcome, if you would like to post a comment please register.
We also encourage you to explore all things Zimbra with our team and members of the community.
|  | 
09-09-2010, 08:50 AM
| | Intermediate Member | |
Posts: 18
| | message store :"stored only once" is that true ? Helo,
in the documentation we can read : Code: Message store.
The message store is where all email messages and file attachments reside. Messages are stored in MIME format. A message that is sent to multiple recipients who have accounts on one mailbox server are stored only once in the file system. but i can't confirm is that true.
by creating 2 accounts sans send then a mail we can see 2 files in the directory structure
we take the help from : Account mailbox database structure - Zimbra :: Wiki
thank's for reading me  | 
09-09-2010, 09:33 AM
| | | It's a hard link, compare the inodes not the blob file name:
ls -il /opt/zimbra/store/0/5/msg/1 9835539 -rw-r----- 2 zimbra zimbra 3004 Sep 9 09:19 5311-31590.msg
ls -il /opt/zimbra/store/0/6/msg/0 9835539 -rw-r----- 2 zimbra zimbra 3004 Sep 9 09:19 322-25116.msg | 
09-09-2010, 09:48 AM
| | | With hard links, one file can have different names in the same directory or across multiple directories as long as all of the directories reside on the same volume. In Zimbra's case it's more often used between directories.
Normally if the file is opened by one of its names, and changes are made to its content, then these changes will also be visible when the file is opened by an alternative name. Here that's not always really all that useful to us; so in Zimbra if one user makes a change to a file, it's accessed via the mysql database & volume info which allows us to access them by different file path/names - and if there's a change we also update the mod_content part of the hash (or thus storing it as a 'new' blob).
In all this gives us the ability to change data for one user but leave it untouched for x many others that are on the same server volume; thus single instance storage of identical items.
~
This hard link node trick doesn't work across volumes (and obviously not across servers.)
Soft link aliases are different and essentially behave as separate inodes.
Hard links aliases always refer to the source node, even if moved or removed; soft links are not updated and can be used across filesystem/volume boundaries.
Unlike soft links, hard links cannot (typically) link whole directories, just files. | 
09-09-2010, 09:55 AM
| | | Quote:
Originally Posted by mmorse This hard link node trick doesn't work across volumes (and obviously not across servers.)
Soft link aliases are different and essentially behave as separate inodes.
Hard links aliases always refer to the source node, even if moved or removed; soft links are not updated and can be used across filesystem/volume boundaries.
Unlike soft links, hard links cannot (typically) link whole directories, just files. | On that note, does that mean that the store once feature is worthless when HSM is involved (except during the period that the message is stored on the primary store of course)? | 
09-09-2010, 12:13 PM
| | Intermediate Member | |
Posts: 18
| | Really clear thank's
I'v missed the hard link trick !
Is there any public API to query this system storage ? | 
09-16-2010, 12:44 PM
| | Special Member | |
Posts: 160
| | Quote:
Originally Posted by mmorse With hard links, one file can have different names in the same directory or across multiple directories as long as all of the directories reside on the same volume. In Zimbra's case it's more often used between directories.
Normally if the file is opened by one of its names, and changes are made to its content, then these changes will also be visible when the file is opened by an alternative name. Here that's not always really all that useful to us; so in Zimbra if one user makes a change to a file, it's accessed via the mysql database & volume info which allows us to access them by different file path/names - and if there's a change we also update the mod_content part of the hash (or thus storing it as a 'new' blob).
In all this gives us the ability to change data for one user but leave it untouched for x many others that are on the same server volume; thus single instance storage of identical items.
~
This hard link node trick doesn't work across volumes (and obviously not across servers.)
Soft link aliases are different and essentially behave as separate inodes.
Hard links aliases always refer to the source node, even if moved or removed; soft links are not updated and can be used across filesystem/volume boundaries.
Unlike soft links, hard links cannot (typically) link whole directories, just files. | Does this work for archive emails as well? if I send an email to 100 users, on the mail store it is stored once with 99 hard links and sent over to the archive server (seperate box) and is also stored once and 99 hard links to it?
Thanks! | | Thread Tools | Search this Thread | | | | | Display Modes | Linear Mode | | Why Join? Registering let's you ask questions, makes it easier to search, displays any files attached to posts, and notifies you about replies.  |