On 2015-05-27 18:46, Daniel Phillips wrote:
On 05/27/2015 02:39 PM, Pavel Machek wrote:
On Wed 2015-05-27 11:28:50, Daniel Phillips wrote:
On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote:
On Tue, May 26, 2015 at 6:03 PM, Pavel Machek wrote:
We identified the following qualit
On 05/27/2015 02:39 PM, Pavel Machek wrote:
> On Wed 2015-05-27 11:28:50, Daniel Phillips wrote:
>> On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote:
>>> On Tue, May 26, 2015 at 6:03 PM, Pavel Machek wrote:
>>>
> We identified the following quality metrics for this algorithm:
On Wed 2015-05-27 11:28:50, Daniel Phillips wrote:
> On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote:
> >On Tue, May 26, 2015 at 6:03 PM, Pavel Machek wrote:
> >
> >>
> >>>We identified the following quality metrics for this algorithm:
> >>>
> >>> 1) Never fails to detect out of space
On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote:
On Tue, May 26, 2015 at 6:03 PM, Pavel Machek wrote:
We identified the following quality metrics for this algorithm:
1) Never fails to detect out of space in the front end.
2) Always fills a volume to 100% before reporting out o
On 2015-05-27 11:21, Mosis Tembo wrote:
On 05/27/2015 04:04 PM, Austin S Hemmelgarn wrote:
On 2015-05-27 03:37, Mosis Tembo wrote:
On 05/26/2015 12:03 PM, Pavel Machek wrote:
We identified the following quality metrics for this algorithm:
1) Never fails to detect out of space in the front
On 05/27/2015 04:04 PM, Austin S Hemmelgarn wrote:
On 2015-05-27 03:37, Mosis Tembo wrote:
On 05/26/2015 12:03 PM, Pavel Machek wrote:
We identified the following quality metrics for this algorithm:
1) Never fails to detect out of space in the front end.
2) Always fills a volume to 100%
On 2015-05-27 03:37, Mosis Tembo wrote:
On 05/26/2015 12:03 PM, Pavel Machek wrote:
We identified the following quality metrics for this algorithm:
1) Never fails to detect out of space in the front end.
2) Always fills a volume to 100% before reporting out of space.
3) Allows rm, rmdir
On 05/26/2015 12:03 PM, Pavel Machek wrote:
We identified the following quality metrics for this algorithm:
1) Never fails to detect out of space in the front end.
2) Always fills a volume to 100% before reporting out of space.
3) Allows rm, rmdir and truncate even when a volume is full.
> We identified the following quality metrics for this algorithm:
>
> 1) Never fails to detect out of space in the front end.
> 2) Always fills a volume to 100% before reporting out of space.
> 3) Allows rm, rmdir and truncate even when a volume is full.
Hmm. Can you also overwrite existing d
Addendum to that post...
On 05/12/2015 10:46 AM, I wrote:
> ...For example, we currently
> overestimate the cost of a rewrite because we would need to go poking
> around in btrees to do that more accurately. Fixing that will be quite
> a bit of work...
Ah no, I was wrong about that, it will not b
(reposted with correct subject line)
Tux3 now has a preliminary out of space handling algorithm. This might
sound like a small thing, but in fact handling out of space reliably
and efficiently is really hard, especially for Tux3. We developed an
original solution with unusually low overhead in the
11 matches
Mail list logo
