[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