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.
-- Clifton
--
Clifton Royston -- [EMAIL PROTECTED]
Tiki Technologies Lead Programmer/Software Architect
"I'm gonna tell my son to grow up pretty as the grass is green
And whip-smart as the English Channel's wide..."
-- 'Whip-Smart', Liz Phair
