[Dovecot] Attachements with SIS : shauld all the same files share the same inode ?

[Yann Dupont]

Hi timo, thanks for your answer

Le 05/11/2011 17:23, Timo Sirainen a écrit :

> On Mon, 2011-10-17 at 09:19 +0200, Yann Dupont wrote:
>> 104 instance of -rw------- 104 vmail vmail 346584 16 oct.  17:47
>> 6e2df299fa96daec9b4735d07c494046429be4d6-ffd0d1xxxx
>>
>> The files are hardlinked, so it seems ok, but I also see 9 others files
>> in the same directory :
>>
>>
>> -rw-------   1 vmail vmail 346584 16 oct.  17:47
>> 6e2df299fa96daec9b4735d07c494046429be4d6-0519df2a94fc9a4e1f4100008a6b99b6
>> -rw-------   1 vmail vmail 346584 16 oct.  17:47
>> 6e2df299fa96daec9b4735d07c494046429be4d6-1790b92994fc9a4e1a4100008a6b99b6
>>
>> as you can see, same prefix, If I compare them with diff, they are all
>> the same files.
>
> I guess you have "mail_attachment_fs = sis posix" (default)? Sounds like

yes that's the case.

> there could be a bug where SIS does comparison of files but for some
> reason thinks they are different.
>
Well I can't try anymore on this, because this particular attachment is 
not there. In fact this server keeps only 2 weeks of mails for 5000+ 
accounts (a form of backup for the main servers).

I'll take a new one :
->

rw------- 103 vmail vmail 571037  7 nov.  13:40 
f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c0c2230ecdd1b74ec91600008a6b99b6
-rw------- 103 vmail vmail 571037  7 nov.  13:40 
f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c1c1290ecdd1b74ec51600008a6b99b6
-rw-------   1 vmail vmail 571037  7 nov.  13:40 
f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c67f0e29bad1b74e7e1500008a6b99b6

So 
f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c67f0e29bad1b74e7e1500008a6b99b6 has 
only one link,

but

diff 
f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c1c1290ecdd1b74ec51600008a6b99b6 f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c67f0e29bad1b74e7e1500008a6b99b6

tell nothing : they are same files.



> You could try if you can merge them with:
>
> mkdir /tmp/queue
> touch /tmp/queue/6e2df299fa96daec9b4735d07c494046429be4d6-foo
> doveadm sis deduplicate /var/attachments /tmp/queue
>
>

hum I didn't get what you want to do ? Does putting a 0 byte file there 
force a complete rescan ?

Tried it :

the 0 byte length 
/tmp/queue/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-foo disappear from 
the /tmp/queue, but 
f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c67f0e29bad1b74e7e1500008a6b99b6 still 
has one link.

A strace reveal this
stat("/vmail/attachments-deduplic", {st_mode=S_IFDIR|0700, st_size=8192, 
...}) = 0
open("/tmp/queue", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8
getdents(8, /* 3 entries */, 32768)     = 112
stat("/tmp/queue/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-foo", 
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
link("/vmail/attachments-deduplic/f7/c9/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-foo", 
"/vmail/attachments-deduplic/f7/c9/hashes/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667") 
= -1 ENOENT (No such file or directory)
mkdir("/vmail/attachments-deduplic/f7/c9/hashes", 0700) = -1 EEXIST 
(File exists)
unlink("/tmp/queue/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-foo") = 0
getdents(8, /* 0 entries */, 32768)     = 0
close(8)                                = 0



Tried with a copy of the file but this doesn't work either :

stat("/vmail/attachments-deduplic", {st_mode=S_IFDIR|0700, st_size=8192, 
...}) = 0
open("/tmp/queue", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 8
getdents(8, /* 3 entries */, 32768)     = 144
stat("/tmp/queue/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c67f0e29bad1b74e7e1500008a6b99b6", 
{st_mode=S_IFREG|0600, st_size=571037, ...}) = 0
write(2, "doveadm(root): Fatal: /tmp/queue"..., 170doveadm(root): Fatal: 
/tmp/queue/f7c9746ed59fd838cbbfca08cde3c33b6b7ab667-c67f0e29bad1b74e7e1500008a6b99b6 
is not a valid sis-queue file, is the queue directory correct?

How can I help further ?
Thanks,


-- 
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont at univ-nantes.fr