Hello Jean,
Sorry for may late reaction.
Are you still interested in pmfsrr mode? In my last mail, I described
about the cache. But it might be wrong. Currently I think this behaviour
correctly follows what it should be, but the description of 'pmfsrr'
mode in aufs maunal is poor.
By design, 'pmfsrr' means
- try top-down-parent mode first
- test the decided branch has the larger free space than the specified
'low' watermark.
- if the free space is smaller, then try mfs-rr mode.
And 'mfsrr' mode means
- find the branch whose has the largest free space
- test the decided branch has the larger free space than the specified
'low' watermark.
- if the free space is smaller, then try round-robin mode.
In 'round-robin' mode, all the free-space information are ignored.
But the manual describes differently a little.
----------------------------------------------------------------------
.B create=mfsrr:low[:second]
Selects a writable branch in most\-free\-space mode first, and then
round\-robin mode. If the selected branch has less free space than the
specified value `low' in bytes, then aufs re-tries in round\-robin mode.
:::
.B create=pmfsrr:low[:second]
Firstly selects a writable branch as the `pmfs mode.'
If there are less than `low' bytes available on all branches where the
parent dir exists, aufs selects the one which has the most free space
regardless the parent dir.
----------------------------------------------------------------------
Note that mfsrr says "round-robin" explicitly but pmfsrr doesn't.
The description of pmfsrr should be
If there are less than `low' bytes available on all branches
where the parent dir exists, then mfsrr mode is applied
regardless the parent dir.
Because you specified a very large value as the 'low' watermark, I guess
your 2GB file was fallen to the simple 'rr' mode.
So the one solution will be to specify the value lower than the
free-space which your desired branch has.
Is it a good solution for you?
sf...@users.sourceforge.net:
>
> "Jean-Ray Arseneau":
> > Here=E2=80=99s the updated log after applying the latest debug b.patch:
>
> Thank you very much.
> I think I could see the scenario.
> As you might know, the mfs policy caches the free-space value per
> branch, and pmfsrr policy internally runs the mfs rourtine twice. The
> first one is considering the parent dir, and the other is without
> considering the parent. In this second call, the mfs routine doesn't
> work expectedly since the result is cached and the routine dicide the
> target bracnh based upon the last result. Obviously it is an aufs bug.
> I will adress it in next week. If you can't wait, try 'pmfdrr:<low>:0'
> which will force the mfs routine not to use the cached value.
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
