[Dovecot] Avoiding Hardlinks (was: Something other than dotlock for uidlist locking?)

Les Mikesell lesmikesell at gmail.com
Thu Aug 10 01:28:10 EEST 2006


On Wed, 2006-08-09 at 14:28 -0700, James Berry wrote:

> Hardinked files on HFS+ live in a single special hidden directory.  
> Any file that becomes multiply linked is moved into that directory.  
> And the only way for it to leave that directory is for (a) the link  
> count to go to zero and (b) for the volume to be remounted. What this  
> means is that even just using link/unlink to move a file will cause  
> the file to accumulate in that hidden directory (with linkcount=1).  

Wow... Rename() as a single step was added fairly late in the unix
game.  It's hard to imagine many programs working for long on a system
that doesn't release the space after a link/unlink operation.

-- 
  Les Mikesell
   lesmikesell at gmail.com
 


> So in the MailDir case, _all_ mail files will ultimately end up in  
> that hidden directory. Making the matter worse, temporary files, such  
> as .lock files, will accumulate at linkcount=0 in the hidden  
> directory until the volume is remounted (usually at reboot). So as  
> you can image, the performance of hardlinks suffers due to the size  
> of this directory as soon as you get very many files, and grows worse  
> the longer the machine is up.
> 
> So, hardlinks were grafted on to HFS+ anticipating that unix-like  
> systems needed to hardlink _some_ files. The design did not  
> anticipate the sort of usage of hardlinks by dovecot. And it fails  
> miserably.
> 
> It certainly looks possible to me that we can make the needed changes  
> to get very reasonable performance without hardlinks, and without  
> having to use UFS, which has its own problems with many files such as  
> we get with MailDir.
> 
> James
> 
> 



More information about the dovecot mailing list