Clifton Royston wrote:
On Wed, May 25, 2005 at 02:47:39PM -0700, Ken A wrote:
Clifton Royston wrote:
On Wed, May 25, 2005 at 10:51:58AM -0700, Ken A wrote:
I'm running the latest qpopper on FC3 with user quotas turned on.
With fast-update on, I see "Invalid cross-device link (18)
[pop_updt.c:770]" in the logs. I know this is normal for fast-update
when the spool and temp drop are on different partitions because of the
way rename works.
But, if I put the temp drop on the same filesystem as the mail spool,
users can't check mail when they hit their hard quota. :-(
I'd like to have the temp drop on a different partition so quotas work,
but still use fast-update, since I'd like to keep disk i/o down as much
as possible. I'd appreciate any ideas.
This is inherently impossible due to issues with the Unix quota model
and filesystems. "fast-update" is a simple relink, i.e. rename, to
replace the spool when the ideal case is hit; that is how it can do
essentially no I/O at this step. Obviously this can only happen when
the two files exist on the same filesystem (indeed, in any OS I know
of, not just UNIX.)
However, it's not possible in the UNIX model to have a user quota
that applies only to a portion of a filesystem, or to "all files except
...". That sharply limits the usefulness of hard quotas if you have
the spool and the temp drop on the same filesystem, as you say.
...
I think found a way to work around this, at least with linux kernel 2.4
and up. The fix is to put the temp drop on a different partition so the
quota system doesn't see it, and then use the vfs feature "mount --bind"
to remount the temp drop filesystem as part of the /var/spool
filesystem. ie: mount --bind /var/tempdrop /var/spool/tempdrop
This allows qpopper to rename files using fast-update, and since the
quota system is looking at the underlying filesystem, it ignores files
in the temp drop directory.
Wow. I guess I never thought of trying something like that; I've got
to think about how that would work. Other OSes may have something
similar available via unionfs mounts or the like, so it might be
feasible to do in other OSes.
I'm not sure if this is intended behavior for quotas or not, so it may
change if the quota system changes, but it certainly makes the using the
quota system more 'flexible'. Please let me know if you see any problems
with this approach.
I just talked to a more Linux-oriented friend who thinks this might
simply result in the same file copy happening, but hidden from you
because it's been pushed down into the kernel level where vfs resides.
He's not sure, though. Before concluding that this really had the
effect you want, I would try turning on detailed timing info; you might
find that the "relink" is now taking approximately as much time as the
file copy used to, because it's now actually doing a file copy.
--
I'll be interested to hear the results.
Qpopper's --enable-timing only resolves to seconds afaik, so I did some
testing copying a large file with perl's Time::HiRes, and system("mv").
I'm assuming mv uses relink() just like qpopper. (not much of a C
programmer here!)
Apparently, the mount --bind option doesn't really give any advantage
over leaving the temp-drop on a different partition. :-(
Time to copy on same partition: 0.147061
Time to move on same partition: 0.001959
Time to move to with bound partition: 0.150901
Time to move across partitions: 0.151158
Thanks,
Ken Anderson
Pacific.net
-- Clifton
